[Gen9 Android Development] trevd:
During my time hacking on android I've discovered some nice easter eggs deep in the android platform. One such easter egg is the mounting of ext4 images directly in the init.rc script. This is a feature I have never seen used by any oems and only by one custom rom [ EDIT: and by letama in his Sony Xperia Boot Manager ;) ]! looking at the git logs this functionality has been present since September 2010 [ commit 49b8124a1759cb8b27e0c21a1a5a54b8a81bdb19 ]. What this effectively gives us is the ability to overlay a pseudo partition layout over the top over the existing layout, thus avoiding any "Danger" of accidental bricking the device by reformatting the SDCard. This is very similar to the way archos mount the stock file system and a variation/extension on the existing methods we use for the SDE Roms.

Although the explanation assumes the use of the SD models it should be fairly straightforward to apply the the HDD models.

THE METHOD:

PART 1 - Prepare a recovery ext4 image file

1. Build CWM6 from the CM10 source.

2. Modify The Recovery's init.rc file to look something similar to this

on early-init
start ueventd

on init
export PATH /sbin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard

symlink /system/etc /etc

mkdir /boot
mkdir /sdcard
mkdir /system
mkdir /data
mkdir /cache
mount /tmp /tmp tmpfs
mkdir /partitions 0771 system system
mount ext4 /dev/block/mmcblk0p4 /partitions

# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount ext4 loop@/partitions/CAC /cache nosuid nodev
mount ext4 loop@/partitions/DATA /data nosuid nodev
mount ext4 loop@/partitions/SYS /system
mount ext4 loop@/partitions/SDCARD /sdcard nosuid nodev
mount ext4 loop@/partitions/BOOT /boot

on boot

ifup lo
hostname localhost
domainname localdomain

class_start default

service ueventd /sbin/ueventd
critical

service recovery /sbin/recovery

service adbd /sbin/adbd recovery
disabled

# Always start adbd on userdebug and eng builds
# In recovery, always run adbd as root.
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
#write /sys/class/android_usb/android0/enable 1
write /sys/class/android_usb/android0/iManufacturer $ro.product.manufacturer
write /sys/class/android_usb/android0/iProduct $ro.product.model
write /sys/class/android_usb/android0/iSerial A101S_REC
#start adbd
setprop service.adb.root 1

# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1

3. Modify the etc/recovery.fstab to look like this

# mount point fstype device

/cache ext4 /dev/block/loop1
/data ext4 /dev/block/loop2
/system ext4 /dev/block/loop3
/sdcard ext4 /dev/block/loop4

4. Creating an empty ext4 image file name REC and mount it on your pc. [ 5MB should do it ]

5. Copy the contents of the built recovery/root directory to the root of your mounted image.

6. chmod init.rc , default.prop and ueventd.rc to 644 ( rw-r-r- )

7. umount the ext4 image and push it to the root of you data partition

That's stage 1 complete. Part 2 Will Follow Shortly.....

Part 2 - Make a dual boot initramfs.cpio.lzo

1. Change the name of the /data directory to /bootdata by modifying the etc/mountpoints file in the initramfs.cpio.lzo. This stops CWM getting confused when trying to un/mount the data partition

mount_name	mount_dev	mount_point	mount_fs	mount_opts	volume_name	error_code	custom_opt

rawfs	/dev/mmcblk0p1	/mnt/rawfs	rawfs	none	150

system	/dev/mmcblk0p2	/mnt/system	ext4	rw,noatime,noexec	system	152
bootdata	/dev/mmcblk0p4	/bootdata	ext4	rw,noatime,noexec	bootdata	154	crypt_compat

storage	/dev/mmcblk1p1	/mnt/storage	ext4	rw,noatime	#storage_name#	155

storage_A80S	/bootdata/media	/mnt/storage	bind	bootdata	none	155
storage_A101S	/bootdata/media	/mnt/storage	bind	bootdata	none	155
storage_A101XS	/bootdata/media	/mnt/storage	bind	bootdata	none	155
storage_LUDO	/bootdata/media	/mnt/storage	bind	bootdata	none	155

storage_A80H	/dev/hdd1	/mnt/storage	ext4	rw,noatime	#storage_name#	155
storage_A101H	/dev/hdd1	/mnt/storage	ext4	rw,noatime	#storage_name#	155

usbhost_ehci	/dev/storage_ehci1	/mnt/usbhost_ehci	vfat	rw,noatime,utf8,shortname=mixed	none	156
usbhost_otg	/dev/storage_otg1	/mnt/usbhost_otg	vfat	rw,noatime,utf8,shortname=mixed	none	156

rfsext4	/dev/loop0	/new-root	ext4	rw,noatime	none	157
rfsext3	/dev/loop0	/new-root	ext3	rw,noatime	none	157
rootfs	/dev/loop0	/new-root	squashfs	ro,cts_compat	none	157

ramdisk	/tmp/ramdisk	/ramdisk	vfat	loop,rw,utf8,shortname=mixed	#ramdisk_name#	158	ramdisk,ramdisk_size=256

2. Using sirduke989 dmenu initramfs you can modify the init script in the initramfs to mount /bootdata instead of /data and also add /bootdata/REC and /bootdata/BOOT to the list

of known locations , I see this a temporary measure as there are a number of other ways to enable dual ( Triple?!? ) booting

3. Flash the modified initramfs and your choice of kernel using either the recovery menu or kd_flasher, I used the 3.0.21 kernel extracted from the 4.0.24 aos file.

You should now be able to boot into CWM Recovery!

Clearly I'm a developer not a photographer!! :)

Part 3 - Create rest of the "partition" images.

You should have a /partitions directory in you device root, This is what is normally mounted as your /data ( /dev/block/mmcblk0p4) and contains normal android user data e.g installed app settings databases etc. This is where I've created the reset of my Partitions which are just more ext4 images files. I did this using "dd if=/dev/zero ...." and "mke2fs -text4 ...." on the device through adb whilst booted into CWM. This saved time in pushing large empty ext4 files from my pc. :)

I called my image CAC ( cache ) DATA ( data ) SYS ( system ) SDCARD ( sdcard ) BOOT ( boot ) you can obviously call them what you like and place them anywhere as long as you match up the image names with those in init.rc and make sure the loop numbers are correct in the etc/recovery.fstab everything should be fine.

You can play around with the files sizes, I have an 8gb my current file sizes at the moment are

BOOT = 25MB

CAC = 500MB

DATA = 3GB

SYS = 500MB

SDCARD = 2GB

The sdcard mount point is probably worth pointing at an external sd if you have one available. I have a 32GB Class 10 that I'll probably set up.

After you've setup your psuedo partitions you should then be able to reboot into recovery, if you've done things correctly you mount output should contain the following

/dev/block/mmcblk0p4 on /partitions type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop1 on /cache type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop2 on /data type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop3 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop4 on /sdcard type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop5 on /boot type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)

Everything seems to function correctly, I have successful done a backup and restore of my system partition. I have also applied CWM-SuperSU.zip through install zip from sdcard. Mounting and Remounting works although I'm not sure if Mount USB Storage works yet, I didn't on linux and I've not tested on windows and finally wiping and formating was also successful.

Part 4 - Notes on setting up rom images.

Now you may of already realized normal archos images don't come as separate the /boot and /system images so work is require to split them up.

Also if you want to split the /system from the reset of a archos image your boot partition will need to be about 50MB as archos have they /bin /lib /usr directories which contains binary files that use /lib/libuClibc-*.so as it's libc which brings there root filesystem in at around 38MB.

There is a very strong case for ditching these binaries especially when using AOSP/CM based roms. My intial tests show this is possible.

Just like the recovery init.rc Similar changes have to be made to the roms init.rc

Moving Forward:

of course, there's a lot to do but I wanted to at least get this initial information out there for people to consider. I'm currently booting a Linaro 4.1.1 rom using the split partitions. I have also been working on better booting methods which is why I haven't given any details re the initramfs init script but It's fairly straight forward to adjust and adapt. I'll write up more details soon!