ubuntu-phone team mailing list archive

[Dmitrijs Ledkovs <xnox@xxxxxxxxxx>]

On 14 November 2013 17:55, Ricardo Salveti de Araujo
<ricardo.salveti@xxxxxxxxxxxxx> wrote:
> On Wed, Nov 13, 2013 at 7:16 PM, Dmitrijs Ledkovs <xnox@xxxxxxxxxx> wrote:
>> Dear all,
>>
>> 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).
>>
>> 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)
>
> I just don't yet understand why we want to support this path, as we
> already support cdimage based images ("flipped" model), and
> system-image (ro and rw).
>

I don't necessary propose to have this implementation as
endorsed/supported. It's rather experimentation / exploration at this
point.

The way system image is organised at the moment (with loop mounts) is
not because that's how our ideal device would ship, but rather due to
constraints of the existing partitioning layouts of the Nexus/android
devices.

Ideally we'd want to mount rootfs in the initramfs and hand-over to
mountall to mount the rest in-parallel. And similarly loop-mounted
partitions at the moment, cause shutdown - unmount ordering
complexities.

> If lack of disk space is the only issue, you could just boot using the
> "flipped" model instead (but there's also a partition size limit as
> well, as it's mtd).
>
> If you want to just use system-image model, without changing much, you
> could simply increase the sdcard image size (as it's a "real" mmc
> device).
>

For the emulator disk-size is not an issue. Unused partitions on the
real devices (because they are too small to achieve what we want) or
wasted space (because a partition is too large) is a problem. Disk
space will be at premium, and we should come up with optimal
partitioning schemes going forward.

We do need defined locations for:
* kernel + initramfs (possibly abootimg format?)
* RO system image
* RW customized data
* image update storage location
* recovery locations
* ....

At the moment RO system-image is stored on an always RW-mounted
partition. Which doesn't feel right.

> Now if you say you want to support the repartition model we discussed
> before implementing the system-image loop-based format, I'd first like
> to discuss how our partitioning scheme would look like :-) (e.g. do we
> want more than one partition?)
>

At the moment I'm trying to enable something were we can play around
unconstrained with partitions. Roughly I'm going by at the moment that
we would want to be able to mount & use partitions direct, have
ability to use multiple partitions, and have a GPT partition table.

Gathering all partitioning requirements, discussing and settling for a
strategy is something that still needs to be done. But it shouldn't
delay a prototype where repartition models can be tried out.

(one partition - formatted as LVM Volume Group?! =) that gets
mentioned from time to time)

>> 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
>
> Should be, but why would we want that?
>

Faster boot time
- no need to loop-mount android-system, and unpack initrd inside that,
at initramfs time.
- less time in initramfs, means we can start the container earlier as
soon as rootfs is available.

Tiny memory usage win - since lxc container is started from disk
instead of tmpfs. (~0.5MB)

Also in RW mode it will make it easier to change the android container.

>> Also at the moment emulator is still using MTD partitions, instead of
>> GPT formatted MMC device. That's also a TODO.
>
> Ideally we would just use the MMC device instead, which is kind of
> what we're doing atm anyway (we're not using the system and userdata
> partitions atm).
>

Right. But I'd rather have normal ubuntu booted, instead of panic
shell in the initramfs to repartition / test / enable the MMC device.
Kind of tricky to debug/devel it whilst booting off it at the same
time.

In summary, yes this is work in progress, nothing is final/endorsed/supported.

Regards,

Dmitrijs.