ubuntu-phone team mailing list archive

[Ricardo Salveti de Araujo <ricardo.salveti@xxxxxxxxxxxxx>]

On Wed, Nov 13, 2013 at 9:05 PM, Dmitrijs Ledkovs <xnox@xxxxxxxxxx> wrote:
> On 13 November 2013 22:21, Steve Langasek <steve.langasek@xxxxxxxxxx> wrote:
>> Hi Dmitrijs,
>>
>> Thanks for working on this!
>>
>> On Wed, Nov 13, 2013 at 09:16:17PM +0000, Dmitrijs Ledkovs wrote:
>>> I've raised a merge proposal below, to allow initramfs to mount system
>>> partition direct as an ubuntu rootfs.
>>> At the moment this is a fallback, as apart from the emulator, it's not
>>> possible to have a large enough system partition to hold ubuntu
>>> rootfs.
>>
>>> A matching patch for build/ android project is attached as a file.
>>
>>> The patch for the emulator package changes the behaviour slightly:
>>> * sdcard.img is dropped
>>> * ubuntu-system.img & ubuntu-userdata.img are generated
>>> * if no options specified: ubuntu-system.img is embedded inside
>>> ubuntu-userdata.img & normal (loop) based mount is performed
>>
>>> * if "-no-loop" is specified to the build script, ubuntu-system.img is
>>> not embedded.
>>
>>> ubuntu-system.img is provisioned as the system.img (/dev/mtdblock0)
>>> and ubuntu-userdata.img is provisioned as userdata.img
>>> (/dev/mtdblock1).
>>
>> I don't quite understand this.  My understanding is that we need three
>> images¹ for the emulator:
>>
>>  - the initramfs
>>  - the system partition
>>  - the userdata partition
>>
>
> Well the emulator at the moment is booting into "RW system image" mount style.
> (the yaff stuff is gone, it's all ext4 now). It's not booting
> "flipped" so it's slight different at the moment.
>
>> ¹ (well, possibly more, but that these are the three required for boot)
>>
>
> (well initramfs + vmlinuz is provided separate direct to qemu, so i
> did skip those)
>
>
>> If we're loopback, the userdata partition (ubuntu-userdata.img) has the
>> Ubuntu root filesystem on it as a loopback file, /system.img; and the system
>> partition (yaff-system.img) contains the root filesystem for the Android
>> container - which is unpacked to a tmpfs before booted.
>>
>
> At the moment on the emulator:
> sdcard.img - has fs label "USERDATA" it has /system.img which is loop
> mounted Ubuntu root filesystem.
>
> Inside the root filesystem, there is /var/lib/lxc/android/system.img.
> (http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/initramfs-tools-ubuntu-touch/trusty/view/head:/scripts/touch#L104)
>
> This is loop mounted (eventually) as /android/system.
> (http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/initramfs-tools-ubuntu-touch/trusty/view/head:/scripts/touch#L230)
>
> Inside the /var/lib/lxc/android/system.img there is /boot/android-ramdisk.img
> (http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/initramfs-tools-ubuntu-touch/trusty/view/head:/scripts/touch#L194)
>
> Which has it's fstab parsed at boot.
>
> Later, when lxc container starts. The
> /android/system/boot/android-ramdisk.img is unpacked into tmpfs
> $LXC_ROOTFS_PATH
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/lxc-android-config/trusty/view/head:/var/lib/lxc/android/pre-start.sh#L3
>
> and the same /android/system bind mounted into $LXC_ROOTFS_PATH as well
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/lxc-android-config/trusty/view/head:/var/lib/lxc/android/pre-start.sh#L36
>
> So at the moment, ignoring kernel/initramfs, all system image devices
> only have one partition used (userdata) with all 3 components:
> ubuntu-rootfs, android-system.img, android-ramdisk.img stacked in each
> other into a single system.img. + RW paths stored next to system.img
>
>
>> If we're not loopback, we still have the userdata partition
>> (ubuntu-userdata.img), and system.img then becomes the Ubuntu root
>> filesystem.
>>
>
> This these patches the outer most loop is removed:
> - ubuntu rootfs is mounted (RO or RW) from one partition
> - another partition is used for RW paths
>
> The lxc container setup is still the same: loopmount
> /var/lib/lxc/android/system.img, unpack android-ramdisk.img from
> inside it, boot it.
>
> The fstab inside the android container is disabled, since all mount
> points from its fstab are bind-mounted from the mounts done by the
> initramfs.
>
>> What happens to the Android filesystem that was on system.img before?  Was
>> this system.img actually completely redundant (because the root fs we are
>> using lives somewhere else)?
>
> Yes. The mountpoints which are not redundant (are outside
> image/partition which holds ubuntu-rootfs) are:
> - /cache
> - /vendor
>
> both of which are empty on the emulator.

Vendor is not used, and for cache I changed that so we're mounting it
as well (might not be needed, but wanted to replicated what we had in
android first).

>> (I guess it's no wonder that we're keen to get rid of the loop mounting,
>> there are way too many images with the same name running around ;)
>>
>> Anyway, it sounds like you're making good progress towards having a "proper"
>> system partition - kudos!
>
> I believe I have found the tool that generates "android"-like GPT
> partition tables (with corrupted secondary header).
>
> I will be taking the dump of the nexus7 partition layout and will
> attempt to recreate it verbantim, for the purpose of repartitioning
> nexus7.
> (repartitioning is a strong word - lift existing UUIDs and partitions,
> override new partition table, not brick the device)
>
> ( https://android.googlesource.com/platform/system/core.git/+/master/gpttool/gpttool.c
> )
> ( docs in commit message
> https://android.googlesource.com/platform/system/core/+/a360a77294600cd679d4ea69b0b24e217bd02a9e
> )
> ( read option is broken, fixed running against disk-images already )

Just be careful with Nexus 7 as you can easily brick your device :-)

Besides that, also know that once you change the device partition
scheme, you can't use fastboot to flash images anymore (as it grabs
the partition size from the bootloader).

Again, let's discuss first how an ideal partition scheme would be for
us first :-)

Cheers,
-- 
Ricardo Salveti de Araujo