ubuntu-phone team mailing list archive

[Stéphane Graber <stgraber@xxxxxxxxxxxx>]

On Fri, Nov 15, 2013 at 12:04:45AM +0000, Dmitrijs Ledkovs wrote:
> 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.

That's a bad idea.

I agree that it'd be a good thing to avoid the android system.img blob
as that'd make delta images a whole lot more useful for the device
tarball, however, the unpacking of the initrd in a tmpfs remains
important.

Basically Android expects it's / to be read-write and to be a ramfs, the
closest thing to that we can provide is the current tmpfs onto which we
unpack the initrd and then bind-mount all the partitions.


So my recommendation here would be to stick to the initrd + tmpfs
method, possibly moving from a compressed initrd to an uncompressed
tarball if that gives us significant speed benefits (I doubt it, since
the current extraction time is pretty quick).

But we definitely should be looking into shipping the Android system
partition as a tree on the filesystem and have this bind-mounted instead
of doing the current ext4 image + loop. I don't think we'll see much
speed benefit by doing so, but we will see a drastic reduction in device
tarballs delta size (they're currently around 30MB no matter what
changed, with that change done, they should be around 10MB + whatever
actually changed).

> 
> >> 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.
> 
> -- 
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp

-- 
Stéphane

Attachment: signature.asc
Description: Digital signature