Features/SyslinuxOption

From FedoraProject

< Features
Revision as of 02:19, 28 June 2013 by Ausil (Talk | contribs)

Jump to: navigation, search

Contents

Syslinux Option

Summary

This feature will make Syslinux an optional bootloader for Fedora, in kickstart and via a hidden Anaconda option. When used this way, it will replace grub2.

Owner

Current status

  • Targeted release: Fedora 19
  • Last updated: 2013-05-09
  • Percentage of completion: 100%

Current syslinux-extlinux and grubby packages work perfectly right now. Patches are in anaconda and we will be able to test with F19 beta. Additionally, appliance-tools has been patched to allow image creation with extlinux as a bootloader.


Also, F19 alpha installer can be used to install F18 with

   updates=http://mattdm.fedorapeople.org/updates-f19-extlinux.img extlinux

Detailed Description

The Syslinux bootloader has been part of Fedora for over a decade. It's been well-tested as the loader for the installer, but we've always used something else on the installed OS. Newer versions of Syslinux (in the form of a version called Extlinux) can boot from ext2/3/4 or from btrfs.

Benefit to Fedora

Syslinux is tiny and has minimal dependencies. It has a simple, straightforward config format. Both of these are in stark contrast to Grub2, the current primary bootloader. It's also actively maintained, in contrast to the previous "legacy Grub".

Syslinux will be a better choice for cloud images and other Fedora-based virt appliances, and may be preferable in some server, desktop, and laptop environments as well.

Scope

Because it is proposed as an option, this is a relatively small change. When activated, it is part of a critical path action (booting the system!) but will not interfere when not activated. It does require a few changes in other areas, most notably some support in the installer.

The packages already exist in Fedora. They may need a bit more work to act as a primary bootloader. Right now, th extlinux package pulls in a base syslinux package, which pulls in mtools. This might not be necessary.

Grubby already contains preliminary extlinux support, so that new kernels are automatically configured and activated when installed. Need to test and see what might be missing from that.

We also need (primarily) kickstart and (secondarily) hidden options in Anaconda which will enable syslinux support instead of grub2. (As a fallback, an option could be given to configure no installer at all, and syslinux configured in a %post script, but that's less ideal.) Matthew Miller will work on this with guidance from the Anaconda team.

We will probably also want to develop / update some relatively pretty and helpful boot screens (although these won't be seen in the cloud use case). (The design team has previously done work on syslinux beautification as part of the installer.)

There are some situations where Grub2 works but Syslinux can't, like booting directly to an all-LVM system. It may be that in the future we'll want to consider making Syslinux the default and Grub2 an option, but that's not proposed at this time.

It should be possible to support Syslinux in secure boot configurations (using the shim bootloader), but that doesn't need to be done for this feature, which will focus on virtualization as a primary target (while enabling bare-metal usage where convenient.)

How To Test

0. What special hardware / data / etc. is needed (if any)?

A virtualization system is ideal.

1. How do I prepare my system to test this feature? What packages need to be installed, config files edited, etc.?

Enable syslinux in kickstart with whatever option is decided upon, or via the similar Anaconda hidden option.

2. What specific actions do I perform to check that the feature is working like it's supposed to?

Boot the system!

3. What are the expected results of those actions?

The system boots.

It's also important to test that when an updated kernel package is installed (or a kernel package removed) the configuration is automatically updated appropriately.

User Experience

  • Bootloader configuration is simple
  • Appliance-type images have less overhead (probably, same image can be used for EC2 and other cloud providers)
  • Adding boot options at runtime no longer requires jumping through hoops as in grub2

Dependencies

None, except as noted in the scope above.

Contingency Plan

No problem: continue as before.

Documentation

Release Notes

Fedora 19 includes an option for using the Extlinux bootloader, part of the Syslinux family of bootloaders. This bootloader is not as advanced as the default Grub2 bootloader and will not work in all circumstances. It is, however, small, robust, and simple to configure. The target use-case for F19 is lightweight cloud images, but you may find Extlinux useful in other situations as well.

Currently, Extlinux does not support LVM, and while it does support btrfs, that support is limited, so for Fedora 19, an ext2, ext3, or ext4 boot filesystem is required (either / or a small standalone /boot partition). Additionally, currently only X86 and ARM architectures are supported.

To enable Extlinux, either use the "extlinux" keyword on the Anaconda command line, or use the "--extlinux" flag for the bootloader command in kickstart. This feature is not made visible in the installer's graphical or text-mode user interfaces.

Again, this support is current targeted at a narrow use case, and Extlinux will not work for all situations in Fedora 19.

Comments and Discussion