So what is superboot and what does it do?
As a sidestory: the Linux boot process
For those who are not familiar with the Linux boot process, I will give a basic outline of the first stage. You will need this to understand the Superboot - you can skip it, when you already know all of this.
The Linux kernel will be invoked by some kind of bootloader. On your PC, this will be GRUB or LILO, on Android, this is a device specific bootloader. On our Lquid, this bootloader is also responsible for providing the fastboot mode. Once the bootloader is rendered inoperable, any Linux computer will not be able to boot any more - in case of our Liquid, this is the way to brick it.
The Linux kernel is a compressed binary image, containing some code to load and decompress itself into memory at its beginning. So when the kernel is invoked, it will decompress itself into memory (you can read "Uncompressing Linux..." on a connected terminal) and then execute this decompressed blob (" done, booting the kernel.").
The kernel will now initialize the hardware, set up process and memory management, set the CPUs into a defined state, load some internal drivers, and so on. Up to now, all there is is the kernel and the hardware. There are no files, no directories, no apks, nothing. Up to now, everything that was done, happened in so called "kernel space".
The opposite of "kernel space" is "user space", and when the kernel is done with setting up itself, it will transfer control to user space by mounting the root filesystem and invoking the mother of all processes - init.
Most Linux kernels come with a ramdisk image (although not necessarily). This ramdisk contains a basic root-filesystem with some basic system files, some libraries (e.g. libc) and - most importantly - init. So by now, the kernel will extract the ramdisk image into memory, mount it as the root filesystem and then transfer control to init (it looks for the init binary in /sbin/init and /init).
Init now will run some scripts which in turn will create some mountpoints, start services, copy some files to certain locations and so on. Eventually, it will invoke some kind of login process or even the graphical environment.
So this was a basic outline of the Linux boot process. Now on to Pauls superboot.
The boot.img of Android devices contains (among others) the compressed kernel image and the compressed ramdisk image. Inside of the ramdisk image, there is /init, some basic libraries in /lib and /init.rc as the script that gets called by init first.
Paul now put an extra directory into that ramdisk image - /superboot - containing the su binary, the SuperUser.apk and a little script, superboot.sh. He modified the /init.rc script to execute /superboot/superboot.sh before starting any other service.
The script superboot.sh now does the following: it will place the su binary in /bin and make it executable. It will also place the SuperUser.apk to /system/app and give it all required permissions. This happens during every boot of the device.
And that's it. This is all you have to do in order to get root access to the Acer Liquid.
He then repacked his modified ramdisk image along with the kernel to a boot.img file and released that to the public. At this point: Thanks Paul for your work and sharing it with us!
Now to the biggest problem with the Superboot.
As I said, Paul's Superboot boot.img contains the ramdisk image, which does everything needed to root the device. And it contains the kernel image. The drawback is that whenever you flash Paul's Superboot to your Liquid, you will be stuck with the old kernel that Paul used to create his Superboot.
Imagine the following scenario: you are flashing your Liquid to the newest Acer stock firmware (1.008.1-EMEA-GEN1 for example) because you heard that some issues with the touchscreen sensitivity have been fixed by it. This may be due to some driver fixes inside of the Linux kernel. After applying the latest firmware from Acer you flash Paul's Superboot and... yes, you are back to the old kernel that Paul used to create the Superboot image. No driver updates, no security fixes inside of the kernel - the same old Linux kernel that you had before.
I do not know which kernel Paul used to create the Superboot. I assume it must be a kernel from one of the 1.002.x firmware released by Acer.
I had a look into the ramdisk images of the Superboot and the latest Acer stock firmwares (2.005 and 1.008). They are identical, except for the superboot stuff, so no changes here.
For the kernel, this is a different story. I cannot tell if there were any changes, but the md5sums of all kernels are different (actually, this is no big suprise as some information about the build environment, including date and time of the build, get compiled in - no two kernel images, although functionally identical, have the same md5sum). So you never know if there were some improvements to the kernel that get overwritten by the Superboot kernel.
So what does that mean?
For every firmware upgrade released by Acer, someone would need to repackage the Superboot image with the new kernel.
I would like to help but for now, all I can do is dive into the kernel, read and modify and fiddle around with the emulator - my Liquid is ordered but scheduled to be delivered next month.
Any thoughts on this and feedback are welcome. I think the Liquid is a great Android device and I would like to help to make it even better.
edit: Fixed some embarrasing typos...
Edited by Roter_Flieger, 04 February 2010 - 10:12 AM.