-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was a bit confused when I saw this uds event. It is unclear to me why we would want to add upstart to the initramfs. I think it is important to remember that the the whole purpose of the initramfs is to help the kernel find the root fs, so things that aren't needed to access the root fs really shouldn't be there, lest it add bloat and slow down booting. After listening to the audio of the session, it seems like there are a few issues people are trying to address with upstart in the initramfs:
1) Want to fix bugs with mdadm/luks I don't see what this has to do with upstart at all. If your root is encrypted, then you must prompt for the password before you can continue, so there is no reason to do this event driven rather than procedural. Luks volumes not mounted at boot should be handled by udisks or something that can interact with the desktop. mdadm, dmraid, and lvm have already been converted to event driven and handled via udev and are done the same in both the initramfs and in the real system. The criticism I have of the current system there is that they are automatically added to the initramfs when installed. The multipath-tools package has a separate -boot flavor that handles copying the binaries and udev rules to the initramfs only if you require it to boot. I think mdadm, dmraid, cryptsetup, and lvm should follow that same model to avoid adding things to the initramfs that aren't needed there. 2) Want to get boot splash going asap Wouldn't it be better to just get through the initrd faster, or skip it entirely ( as discussed at uds-p )? If you're spending less than 2-3 seconds in the initrd anyhow, it seems counterproductive to make it larger/slower to display the splash screen now instead of after switching to the real root. If there is still an appreciable time between the point where plymouth loads and where you can actually login where it might make sense to continue showing the splash screen instead of having X control the display, maybe we could let X initialize in the background and switch from the plymouth tty to the X tty only once it is ready for you to login. 3) Want to do friendly recovery when the root fs can't be mounted I'm not sure putting recovery in the initrd is worth the bother given the rather small number and rarity of failures that can prevent finding the root fs, but if you do want to do this, it certainly would need to be in an alternate initrd rather than bloating the primary initrd with significant weight that is not needed the vast majority of the time. Rather than putting it in an initrd, it may make more sense just to have a separate recovery partition to boot instead of the usual root fs. 4) Want to move mountall to initramfs to support separate /usr This requires a copy of /etc/fstab in initramfs, and a flag to mountall to only mount / and /usr read-only, then exit. I don't get why anyone would want /usr on a different filesystem in the first place and therefore, why we should spend effort on supporting this. What does having upstart and mountall in the initramfs add to this, as opposed to just adding a second call to mount to the existing init scripts? In the old days, the differentiation was that you could at least boot to single user mode and try to do some recovery without /usr. What is it that we want to be able to do in rescue mode that requires things from /usr? If there is a good case for having them in a rescue mode, then maybe they shouldn't be in /usr in the first place? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPrI18AAoJEJrBOlT6nu754BsIAMMZbgHgcJg94Xf9iLW7eVWs YcJLkKpPeo8SUXuiF+IYYCVKhQPJPQled+gWD+Pw2ScmKesX8Q4GLO1zEUQqTsBa QyqMXRAIuZYVfBicLbePZ6552+FM9v+S+386Be6C66hriv7/eFCd5fr1EqGmmMr2 354ulsEiLzwVQa/nuWicahOSh9GkHG8Z+sCbgIp1drhKR4rlxSYapdv+MUnDne6x MHHKrSBjOgdmGbOOrDdTXkYgQSYxoYlEuDwToiyTxL7td+LNLVcm2e4KmKCcyU+7 i3Xv6oVEm7NO+YiVJUscI2tttxSQIuDZLNWVKGIxiWLZ4WM2KFlgBGY+kx4nFqM= =By+t -----END PGP SIGNATURE----- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
