Pages

2014-04-11

Debian Sid 64bit and adb push

Took me only couple of days after rooting and already I was craving for a mod. Decided to start restrainedly though, and downloaded Cyanogenmod (rather lean, no bloat, good tutorials, and a lot of phones supported).
... And bricked my S3 when trying to flash Cyanogen from ext-sdcard. Means, I suddenly had a phone without system (which I wiped as per instructions) AND not-functioning update zips and also, a restore nandroid with 'error - failed'.

/ Participants: Debian Sid, Galaxy S3 I9300, rooted with: Clockworkmod Recovery, Clockworks' superuser/
## What gives?
The symptoms and happenings:
I had (when I rooted) copied superuser and some jpg-s to sdcard with ordinary file manager. And I had no perceivable problems... So I did the same again - copied cm-10.2.0-i9300.zip and gapps-jb-20130813-signed.zip to sdcard via file manager.

1. Copying went super-fast, like - poof! ... err, what ... let's see:
-- From CWM-recovery - 'install from zip' - and error, and failed.
I tried (after copying whole sdcard to PC) formatting the sdcard in various ways and copying then stuff back to sdcard:
1,5 Gigs in 5 seconds! Bloody hell, quantum computing! Checked md5-s - and incredibly, they were correct...?... But the usage showed approx 300 Megs of written data in sdacrd... shit this quantum.

Let's go for correct/adviced adb route, then:
2. I installed android-tools-adb from Debian REPO. After playing around with sudo and no-sudo, and after adding file /etc/udev/rules.d/51-android.rules with content:
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666"
-- idVendor number comes when you 'lsusb' and pick your probable sdcard device from output - and it's the first half of ID-number.
I got 'pushing' working ... errr, NO - it took time alright, and gave happy stats - BUT, there appeared NOTHING onto sdcard. Shit and hell...

3. So I thought that maybe Debians' adb is a bit oldish for a newish Android 4.3.1
Downloaded adt-pack - 64bit ! - from dev page, unpacked and tried to run nice new exec 'adb'. What I got was 'No such file or directory'. No error messages. Googled and googled and...:

4. Installed missing 32bit libraries. Yes, 32bit! (Shit and hell and MS!)
sudo apt-get install libc6-i386
sudo apt-get install libncurses5:i386
sudo apt-get install libstdc++6:i386


sudo adb start-server  # and for stop 'sudo adb kill-server'
(sudo) adb devices  # because I am already paranoid with all adb, and add sudo to adb-farting too...
sudo adb remount  # IF you have suspicion that sdcard is NOT -rw mounted.
sudo adb shell  # navigate to your sdcard, keep an eye on it with 'ls -la', to be sure.

Then - holy moment - I did it like that (command as long and precise as possible. Paranoid, I said)
sudo adb push filename.zip /storage/sdcard1/filename.zip
I got 'failed' and 'no permission'... fortunately I had shelled before - 'ls' showed - yes, there is a file! I decided to proceed and see what happens - I copied all files and:

## Phone-side,
(Check that /system and /sdcard are still mounted),
'install from zip'
AND, incredibly, it installed both - Cyanogenmod and GApps.
Unplug cable, unmount /system and /sdcard, reboot.
2 min wait looking at spinning Cyanogen-critter (high stroke-risk!)
and welcome to Cyanogen...
:)
The conclusion: 64bit (adb) + 64bit (debian) should equal 64bit (whatever), and IF there is some third player to take to account, then bloody, this 32bit dependency should be THE required dependency. *&^^&%$%$#%#$.

2014-04-06

Rooting guide for Samsung Galaxy S3

... and now, something complitely different...
The point of the following - I did spend much time to find the correct way to root my Galaxy S3 (GT-I9300). So I think that one more guide is proper.

Some useful educational links:
S3 in xdahow to root S3, how to root with Clockwork, Clockwork-recovery guide.
A bit more blah: It's my first smartphone, and no - I did not feel like more 'socializing' but I was thinking about 'little thingy with database and text editing capabilities I can carry with me'. I started thinking about tablet but dropped the idea as impractical - reaching conclusion that only thing  'always carryable' is a phone. After some reasearch into rooting I bought S3 - as certainly rootable and also currently very cheap.
And - some very basic info about rooting:
- Why? For removing bloatware and to use some apps which are unavailable/un-installable for unrooted devices.
- You loose your warranty.
- You might brick your phone.

What I did:
Installed heimdall in Sid, flashed my phone with Clockwork-recovery and installed Clockworks' superuser.

!- With a new phone, it's probably good to wait for first big system-upgrade of your phone - as after rooting you don't get them anymore.

# Meanwhile, download:
- heimdall files (has readymade debs),
- Clockwork recovery,
- superuser.zip (of Clockwork... and, I lost the link),
- and some wallpapers - which you can test-copy from your PC to phones' SD-card when first time in recovery-mode.

# Install heimdall (two debs, cli and gui frontend) to your debian (sid). I did that with simple dpkg -i. Also, heimdall is in Debians' repo too - but, naturally, those are older versions.
And do get readme from here.

# Open up heimdall: sudo heimdall-frontend. 'Sudo' is a must!

!- Do not proceed until your phone is 100% charged. That's a standard warning. Now, it's not very probable that your phone runs out of juice during those couple of seconds when replacing /RECOVERY - BUT, if it does, you get at least soft-brick. So, charge this bloody battery.

# Insert usb cables' PC end.
- boot the phone to download-mode : Power+Voldown+Home : accept disclaimer.
- connect usb cables' phone-end.

# In heimdall:
- check 'no reboot' because afterwards you want to go to recovery-mode, not to standard reboot. DO NOT check repartition - as this formats your whole phone.
- in 'utilities' tab - 'detect' to be sure your device is detected.
- save the PIT from your phone. In the Download PIT section of the 'Utilities' tab, click the Save As button, navigate to ~/your-correct-folder-for-that-file and enter a file name such as GT-I9300.pit.
Save.
Also, maybe it's wise to check 'verbose' in 'Advanced'-menu.
- Go to 'flash' tab, browse for .pit you saved. When .pit is found, 'add' button gets activated. Press 'Add' and pick your folder to flash and file to flash with.
Correct folder is /RECOVERY and file is recovery-clockwork-6.0.4.6-i9300.img - at this moment anyway.
Click START button (I did that twice - as the first attempt didn't do a thing). The second one was a success.

# When/if you get success-message, unplug usb and go to recovery-mode: VolUp+Home+Power
Have this super-guide open in your PC.
- Do system backup to SD-card.
- install superuser.zip (which you already copied from your PC to SD-card together with those wallpapers.
- And do whatever you want... errrr... - Don't wipe your system, but you can wipe cache - which is good thing to do, occasionally.

# Reboot normally. Install terminal emulator and do 'su' there to verify successful rooting. Then install no-bloat and clean out all shit. After that clean out 'no-bloat' too...
And then you can re-bloat your phone with all those very-important-special-apps-you-always-wanted.
I suppose that most of Samsungs' devices (phones, tablets) can be rooted with the same general procedure - if there are proper images to be found.

2014-04-01

AlpineLinux install etc

Visiting fringes (chapter 1) or,
to put it diplomatically - trying out distros outside of top twenty.
The point - looking for a new pet when Debian goes systemd, or - God forbid - the same happens to my home - beloved Slackware. Also, seeking some cheap thrill.

Somewhere I noticed that AlpineLinux is a distro with busybox and open-rc. It also has its' own package manager - apk, which has dependency-check. And the distro was mentioned as lean alternative desktop (despite it being officially oriented "for x86 Routers, Firewalls, VPNs, VoIP and servers"). Desktops are: XFCE, Gnome, Openbox, Fluxbox - at least. Slim and lxdm are display managers.
What follows here is: a) A short description of various installs up to desktop; b) At the end there is also short list of apps that are not available in this distro - for pre-consideration, because install certainly takes some time.

# Install (to sda7, without grub)
I dd-d ISO to usb-stick and booted without any problems.
It lands to console, where you login as root (enter). Then:
mount -t ext4 /dev/sda7 /mnt
setup-timezone
setup-alpine -q
setup-sshd
setup-ntp
setup-disk -m sys /mnt

And it should be installed (it was mind-bogglingly fast procedure).
umount && reboot

Then I went and fixed my master-grub in wheezy, added into
/boot/grub/grub.cfg:
menuentry "Alpine Linux, sda7" {
 set root=(hd0,7)
 linux /boot/vmlinuz-grsec root=UUID=ba5767878-4a8c-40ed-b710-c4e2b42d6b7a modules=sd-mod,usb-storage,ext4 quiet
 initrd /boot/initramfs-grsec
}

Rebooted to Alpine.

# Post-install. There is a lot to do - nothing got installed but pure system.
Comment first line  - /media/usb/apks - in your /etc/apk/repositories
or apk will whine warnings all the time.
setup-apkcache  # enable local cache, store packs locally. I am not sure it's needed witk hdd-install, but I did it anyway.
apk update  # update package-list.
apk upgrade  # upgrade what's installed.

And here we go with adding shit and all:
apk add nano  # trying to avoid vim :)
apk add bash bash-doc  # default shell is ash. In /etc/passwd , changed shell to /bin/bash
adduser myusername
nano /etc/group and I added my fresh user to groups: lp, audio, video, cdrom, plugdev, netdev, power, wheel (and whatever).
nano /etc/sudoers and uncommented 'allow wheel members whatever sudo thingy' at near files' end.

Back to adding things:
apk add perl automake cmake build-base qt sudo
setup-xorg-base  # this one is script
apk add xorg-server
Evdev, mouse and keyboard came automatically. But not video:
apk search xf86-video   # to find what drivers there are. For me it was
apk add xf86-video-nouveau
NB! It seems that it's impossible to install Nvidia binary, so, nouveau it has to be.
I did not 'Xorg -configure' - it started without that.

apk add udev  # Manual says that you should do the following below. I forgot, and then I discovered that it was already automagically done ... but whatever:
/etc/init.d/udev start && /etc/init.d/udev-postmount start
rc-update add udev sysinit
rc-update add udev-postmount default


apk add xfce4-terminal xarchiver
First one brought a pile of good things (cairo, pango, hicolor...)
apk add openbox
touch ~/.xinitrc && echo "exec openbox-session" >> ~/.xinitrc


# startx
Now, I suppose that whomever installs Alpine, already has a bunch of confs hoarded - and now it's time to copy-and-fix them for Alpine. From .config/openbox/* to .bashrc and gtk.
After that I installed fonts (search 'font' in alpinelinux.org 'Packages' for suitable ones), gtk+2.0, gtkmm, gtkmm-dev (and with gtk's there will be enormous pile of nice addons), gtk-engines, coreutils, py-gtk, firefox, pcmanfm, geany, feh, conky, alsa.
Alsa wants also something like that:
alsactl init
rc-update add alsa
rc-service alsa start


# What is not there, of my favourite basics:
obconf, lxappearance, spacefm, medit, nitrogen, tint2, compton, smplayer, volumeicon, wmctrl, xdotool...
Wmctrl I made from from source, it needs libxmu-dev.
It's not possible to make spacefm and udevil (in reasonable way) - and that is quite a showstopper for me.
Volumeicon - it compiled, through some wrestling, but didn't work anyway.
That is the point I reached currently.
To mention more not-there-apps-and-shit: LXDE, Mate, lxpanel, leafpad, gedit, libreoffice, meld, gcolor2, qeeqie, chromium ... etc.

# Conclusion
Desktop on AlpineLinux is definitely possible. IF available stuff is of your taste. I am missing some 80% of what I prefere... Compiling in Alpine is ...errr ... hit and miss.
So, despite that I kinda like Alpine - and it's fast alright - it looks, I am on the road again.

2014-03-15

Removing kits, in Sid

I am not exactly sure why I write this... but there might be two main reasons - I wasted enormous amount of time (80% of this googling crap) and need to get at least some kind of visible outcome. And secondly - it might be of help to someone as of 'how not to get results'.

The idea was to see if I can get rid of *kits in my Debian Sid. And possibly of PAM too. This last one I left aside pretty fast - too many unavoidable deps.
What consolekit and policykit do and why they are also shitty and unneeded part in single-user desktop, that can everyone google themselves.

In my Debian Sid I got such deps for kits: they and their libraries, and Lightdm. That was all, and life seemed rosy.

1. I removed lightdm and replaced it with slim (has optional consolekit dependency) from Debian repo.
As a by-thought - Slims' login-screen looks, frankly, like shit... But slim is real light-weight and easy to configure: /etc/slim.conf and themes reside in /usr/share/slim/themes. Graphical part of themes are quite extensive - and not so trivial to change. If pointed to correct folder, slim lists all your sessions automatically.
But never mind that - of course the debian slim had been compiled with consolekit support.

2. Recompiling slim with -DUSE_CONSOLEKIT=no. My installation needed additionally libpam0g-dev for that.
After playing around with original source - I even got it 'made' (after endless tries and some conf and parameter changes) - I decided for making proper debian package.
So I played several evenings with pbuilder and cowbuilder (there are tons of material to read, some heavy packages to install and not very simple conf to conf). I managed to create quite an impressive mess - and finally went for simpler way and used dpkg-buildpackage.
In very concise way, whole thing was like that:
apt-get source slim   # downloads source packages to current folder and unpacks tars in correct way.
-DUSE_CONSOLEKIT=no  - change it in /slim-unpacked-source/debian/rules
change conf in /debian/patches/slim-conf.patch to reflect your situation (less to do afterwards)
dpkg-buildpackage -rfakeroot -uc -b  # in source folder
and there should be new slim.x.x.deb in sources root.

3. Removing vanilla slim and *kits.
Went to console, killed slim and X, then removed slim, policykit, consolekit and deps. Installed:
dpkg -i slim...new-one.deb
Rebooted.
X did not start and dbus did not start (despite I had the second one in .xinitrc).
Manual dbus-launch worked but then X claimed to have a segmentation fault. Bugger!
I reinstalled consolekit - and X started without any problems... Double bugger!
To cut it short, after trying several things - to (unsuccessfully) root out consolekits' leftovers, I threw a towel.
Shame-facedly, I reinstalled both kits. That's that - a defeat.

At the same time - there are cases of successful removals. So, it can be done. I suspect that without display manager (but I wanted to keep it), linux-with-no-kits is possible.