ubuntu-phone team mailing list archive

[Dmitrijs Ledkovs <xnox@xxxxxxxxxx>]

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.

>> Once booted without loop both / and /userdata are normal partitions
>> (this is in RW mode)
>> /dev/mtdblock1 on /userdata type ext4 (rw,relatime,data=ordered)
>> /dev/mtdblock0 on / type ext4 (rw,relatime,data=ordered)
>
>> Note that android container is still launched from a loop-mounted
>> .img. I will check if it would be possible to supported unpacked
>> android container under /var/lib/lxc/android/rootfs
>> Also at the moment emulator is still using MTD partitions, instead of
>> GPT formatted MMC device. That's also a TODO.
>
> Where does that loop-mounted .img live?  Is this
> /var/lib/lxc/android/system.img within system.img (the Ubuntu rootfs)?
>

correct.

> (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 )

Regards,

Dmitrijs.