Created: 2005-04-24 by MattZimmerman
Early UserSpace is defined as the time from when the kernel hands control over to userspace applications until the time that the full system init is called.
The kernel traditionally has included a lot of functionality that can be easily done in userspace. These include:
- NFS Root
- Partition detection
- Raid (md) detection
- root filesystem mounting
- Device detection.
Many of these items are called using the prepare_namepace() call in the kernel. When using an initramfs solution, the prepare_namespace() call is skipped, and a normal user binary is called to complete the setup which is responsible for chaining to the full system init.
Upstream is moving towards this solution. Some features, such as devfs are scheduled for removal in a very short period of time. Writing kernel code is difficult, since each feature causes bloat that is included in every generic Ubuntu kernel and also bugs in each new function can cause a kernel compromise. Debugging these functions is hard because the code is seldom used, and kgdb is suboptimal.
The current initrd-based solution is problematic because it relies on black magic to migrate kernel threads from the initial root to the new root (pivot_root syscall). The initramfs solves this in a more elegant fashion.
Right now there are three boot cases:
- Live CD
- the installer
- regular system boot.
The first two are unified: the Live CD and the Installer. Actual system bootup is hardcoded, which occasionally results in a system that is installed but cannot boot.
Hotplug-ng is the hotplug of choice because it is written by the author of udev and klibc for the purposes of early userspace.
Scope and Use Cases
- Jim wants NFSRoot (and LTSP) for his thin client terminals and would prefer if the initramfs was the same across all the machines.
- Matt wants to boot his machine.
- Jeff wants to be able to boot with a root file system on a firewire or USB thumbdrive when his hard drive has crashed in order to rescue his data.
- Fabio wants to test changes to the early boot sequence because he is a developer of said system.
- Mark frequently changes hardware in his machine. He wants the system to Just Work, even when he has made major changes to the system such as moving a hard drive from one system to another.
Technical use cases:
- root on plain partition (on whatever physical medium) [done]
- root on lvm volume
- root on software raidN
- root on evms
- root on lvm/raid combination
- root on nfs [done]
- root on iscsi
- root on hardware raid
Update klibc and udev to recent version from current packages (http://people.ubuntu.com/~jbailey/) and upload to Breezy.
- Create archives of kernel modules for inclusion in initramfs
Tweak kernel packaging to help mkinitramfs. kernel-package needs to grow a feature where you can specify which mkinitrd/mkramfs program to call.
- Add ability to concatenate CPIO files to grub version 1. This will make it possible to use multiple CPIO archives on i386/amd64. Note that mkinitramfs will still be able to generate "legacy" (monolithic) initramfses and this would probably be the default until bootloaders generally support this case.
Package hotplug-ng and add to initramfs
Expand initramfs-tools with various hooks for evms and lvm
- User space partition detection and partition label/UUID handling.
Data Preservation and Migration
This process unifies the boot process with that of the installer. Unfortunately, systems that were customized after mkinitrd was originally installed may find their system no longer bootable due to changes in the boot order.
Modules to include in the initrd broken down by package
* pcmcia_core (for root filesystem on e.g. external USB2 hard drive connected via PCMCIA USB2 adapter)
* yenta_socket (for root filesystem on e.g. external USB2 hard drive connected via PCMCIA USB2 adapter)
User Interface Requirements
Should be able to drop into rescue shell on error, or by choice. Must be usplash-friendly.
On catastrophic failure, enough debug information should be provided to allow an adequate bug report to be filed.
- grub version 1 is no longer actively developed upstream, so updates will be Ubuntu specific (although Debian will likely accept them). There is a version 2 which is a total rewrite and which may be viable in the Breezy+1 timeframe.
- Coordination with the Debian Kernel Team.
- Partition Detection is deferred until post-Breezy to ensure that the system is stable and generally functional. Because it's not core functionality, it may be a good candidate for a bounty.