Difference between revisions of "FLOP:Boot-Update Redesign"
(Created page with " This page describes a proposed rewrite of boot-update. The goals in rewriting boot-update are as follows: # Refactor code # Add UEFI support # Simplify Kernel Layout == Re...")
Revision as of 20:57, February 23, 2014
This page describes a proposed rewrite of boot-update.
The goals in rewriting boot-update are as follows:
- Refactor code
- Add UEFI support
- Simplify Kernel Layout
Boot-update could use some code simplification. This will be accomplished by using a simpler design using templates for text generation, and also simplifying the kernel layout (described below.)
Boot-update currently doesn't support UEFI booting directly, and must be manually configured via the UEFI Install Guide. Part of this proposal involves adding UEFI support to boot-update.
Simplify Kernel Layout
Currently, all kernels and initramfs images are installed into /boot directly and typically have the names kernel-SUFFIX or bzImage-SUFFIX and initramfs-SUFFIX. Boot-update needs to find the kernel and initramfs images and associate them with each other, and then parse the filename for version information.
This is not an optimal way to organize kernels. A much cleaner approach would be to have a /boot/kernels/VERSION/ directory that contains files initramfs.gz, bzImage, System.map, etc. without any suffix. boot-update would then scan /boot/kernels and make all directory names available as kernels that could be booted. This simplifies kernel management as everything related to a particular kernel is organized in its own sub-directory.
In addition, special text files could exist in the /boot/kernels/VERSION/ directory, such as label, which could contain a regular text name for the kernel that appears in the menu. A /boot/kernels/VERSION/grub.cfg could allow users to manually specify a grub.cfg section that is used to boot this kernel, which boot-update would use if found. touching /boot/kernels/VERSION/default would allow a user to set the default kernel for booting. These types of changes would reduce the complexity contained in the /etc/boot.conf file, as more configuration data would be stored on the filesystem itself.