From Fedora Project Wiki

< Features

Revision as of 10:55, 8 January 2013 by Fabiand (talk | contribs) (Adjust talk name)

Syslinux Option


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.


Current status

  • Targeted release: Fedora 19
  • Last updated: January 7 2013
  • Percentage of completion: 0%

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.


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.)

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


None, except as noted in the scope above.

Contingency Plan

No problem: continue as before.


Release Notes

To be written when the kickstart and anaconda options are known.

Comments and Discussion