On 14 November 2013 17:55, Ricardo Salveti de Araujo <[email protected]> wrote: > On Wed, Nov 13, 2013 at 7:16 PM, Dmitrijs Ledkovs <[email protected]> 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. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
