From Mageia wiki
Jump to: navigation, search

Summary

Make it possible to boot without a ramdisk. In many simple cases we can speed up booting by not using a ramdisk. If the installation is somewhat complex, then we should still use a ramdisk. Our tools should automatically detect and configure an initrd-free system when possible.

Owner

  • Name: Colin Guthrie
  • Email: colin@mageia.org

Resources

Various filesystem layouts need to be made available to ensure that different configurations are all handled correctly.

Handled by colin with tmb help

Current status

  • Targeted release: Mageia 3
  • Last updated: 2012/06/05
  • Percentage of completion: 50%

Detailed Description

If a user has a simple setup, (i.e. no encryption, raid, lvm or exotic filesystems on /, no separate /usr) then it should be possible to mount the root partition without any complications and go straight into the system and avoid any initrd. This will speed up the boot.

Why it would be good for Mageia to include it

It will speed up and simplify the boot process for those users who have simple layouts.

Test case

Simply create an install that has no complicated disk layout (e.g. ext4 or btrfs directly on /, no separate /usr).

Software / Packages Dependencies

  • kernel: Kernel will need to be compiled with the supported filesystems built-in rather than as loadable modules.
  • diskdrake: Needs to support UEFI/GPT partition format to allow the use of root=PARTUUID=.. syntax for specifying rootfs. This is desirable as we cannot use the root=UUID= syntax which relies on a userspace process (blkid, udev) to find the right physical partition to use. The PARTUUID is below the filesystem level and the kernel will (can?) be able to interpret this directly. We could support root=/dev/sdaN, but we should aim for the same level of flexibility that root=UUID= provides regarding changing the way the disks are positioned/plugged in the machine.
  • bootloader-utils/dracut: These scripts should be able to detect when an initrd is not needed and ensure the bootloader is appropriately configured automatically when kernels are installed/updated etc.

What could disrupt development of this new feature

If there are problems including modules directly in the kernel rather than as modules, we cannot implement this feature.

(alien) I'm thinking of possible issues:

  • ide/sata/... drivers
  • virtualisation guests
  • XEN dom0
  • Network booting
  • UEFI Secure Boot
  • rebuilding kernel on demand (like dkms) doesn't really sound a possibility either
  • growing kernel might make it slower for PXE boots and take more space on livecds

Planning

Kernel builds should be made available with filesystem modules built in. Initial ramdisk free boots can then be tried on simple setups manually to investigate if there are any other problems with this approach.

Contingency

This is a new feature, so the contingency would be to not support such a setup and to always generate initrds as we do currently. Care should be taken when working with the tools to ensure that the detection of when an initrd is not needed is optional (this is mostly likely localised to dracut).

Release Notes

  • Achievement Unlocked: Booting on UEFI with gummiboot+root=PARTUUID syntax allows booting without initrd :)

Documentation