Launchpad Entry: ubuntu-arm-p-optional-initrd
Contributors: Oliver Grawert, Michael Casadevall
Packages affected: initramfs-tools, linux
This spec covers the necessary steps and modifications needed to Ubuntu to remove the mandatory boot ram-disk that we require.
Ubuntu can now be booted in most configurations without an initramfs, increasing the amount of available RAM during boot, and further decreasing boot times.
Primary motivation is to reduce boot time, especially on ARM where the first stage bootloader must load it with the kernel which is often painfully slow. Also allows us to possibly supporting a device where the built-in bootloader may not support a kernel with a ramdisk.
- Alpha is a Ubuntu developer who wants to run Ubuntu on an ARM device with a proprietary bootloader which can't support a ramdisk. With the removal of a mandatory ramdisk, Alpha can now run ubuntu on his device and not expect too much breakage on the early boot chian
- Beta is a OEM who is shipped Ubuntu on an embedded device and trying to reduce boottime and memory usage and can ship a custom kernel. Beta can modify his kernel so no modules are necessary to boot, and remove the ramdisk to decrease his boot time significantly.
- boot time increase is worth the difficulty of removing the mandatory ramdisk
- The ramdisk should still be built in all cases and be available in /boot, but not used if it is not necessary
- Safe mode boot (single user) should use the ramdisk in all cases to prevent locking a user out of their system if a necessary module gets left out by accident
- Network booting will require that both NFS and some network drivers move into being compiled into the kernel instead as modules
- Every boot loader update scripts should go look for -top scripts to determine whether or not the initrd will be needed at boot time
- It might be worth teaching os-prober about initrd-less systems so a machine running two versions of Ubuntu can do initrd-less boot on both
initramfs-tools will need to be upgraded early in the lucid-oneiric->percise upgrade to handle properly building and installing the ramdisk. Careful testing will have to be done to make sure that we don't accidently leave the system in an avoidable unbootable state during a dist-upgrade in case something goes wrong (i.e, power failure).
Existing scripts with a ramdisk trigger/script will have to be audited to see how they use the ramdisk, and if they have to install in all cases.
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.
This need not be added or completed until the specification is nearing beta.
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
Welcome to Ubuntu Developer Summit! #uds-p #track #topic put your session notes here - Main reason for getting rid of the initrd is to reduce boot time, especially on ARM - Current problem with implementing that is lack of UUID support in the kernel - Ubuntu currently supports moving the harddisk to another machine, we should make sure this still works - Initrd should always get built, just not always used - To support initrd-less PXE booting, we may want to get some network modules built into the kernel - update-initramfs would look for hooks shipped by foreign packages and if there's any, then make sure the initrd is used at boot time * at bootloader configuration time, it would decide if one is needed. if not, then do not write default entry with one. (need is not only based on presence of LVM, but on the use of it for root). * "safe mode" would alway use initramfs * Every boot loader update scripts should go look for -top scripts to determine whether or not the initrd will be needed at boot time - Known hooks that will trigger the need for an initrd: casper, lvm, cryptsetup, dmraid, nbd, ltsp, cloud-initramfs-tools - It might be worth teaching os-prober about initrd-less systems so a machine running two versions of Ubuntu can do initrd-less boot on both - Detect cases where we use a different boot= (casper or ltsp_nbd) [question] how about other root devices which may be functional w/ initrd? e.g. MMC/SD, nfsroot, and (dual) boot sequence support, etc. - Will work if supported by the kernel (currently not the case for nfs as nfs isn't builtin) Work Items: [rtg] Work on the kernel patch to support UUID for the root device review if all initramfs scripts are in the right place before we start to do any work (check if top scripts are actually in top etc) crypt-setup needs fixed dm-raid may/might need update (to not instal local-top) logic for inspecting initramfs to decide if necessary to be ini initramfs-tools ('need-initramfs') patch bootloaders (grub, flash-kernel) to use 'need-initramfs'
PhillipSusi: How is the UUID kernel patch going? It doesn't appear to be in the generic kernel yet. As a test today, I built a custom kernel with the AHCI driver built in and got my desktop booting from my SSD without an initrd, measured 8 seconds grub to desktop. With the initrd the boot time is about 12 seconds, so that is an appreciable improvement. Without the kernel UUID patch though, that boot device argument will be fragile.