On Mon, Oct 10, 2016 at 2:17 AM, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > Hi, > >> > Adam, the only other distro that has serious alternate architecture support, >> > AFAIK, is Debian. How do they handle grub2 + non-x86? Likewise, the >> > alternate architectures that we support, how do we handle their bootloaders? >> > Are they grub-based? Ext/Syslinux based? Grub-legacy? >> >> Nothing in Fedora uses GRUB legacy. >> >> ARM is using Das U-Boot. I'm not sure if grubby is involved here or not. >> >> Fedora uses isolinux, extlinux, grub2, yaboot (power7 and older), and >> zipl (s390). If the last two are gone or going away then it's syslinux >> (and variants), grub2, and uboot. > > Hmm, uboot can use extlinux-style config files, and I recently noticed > grub2 has a command to parse syslinux config files too. Have not tried > to use that though. GRUB's syslinuxcfg command is called from an existing grub.cfg, so using extlinux.conf files do not obviate the need for grub.cfg. syslinuxcfg pretty much just parses for boot menu entries in the extlinux.conf file and merges them with its own boot menu entries. At the moment, I expect this to be broken because, again, Fedora's GRUB depends on commands linuxefi/linux16 and initrdefi/initrd16, which no one else uses as far as I know. Not upstream or other distros. I do not know why this detail goes in the configuration file rather than being substituted in code based on what firmware the system has - it seems the other distros do it that way. But this seems surmountable. However... > So possibly we can settle on syslinux syntax for bootloader config > long-term ... > >> > I agree with Kevin that grub2 is.... nonintuitive. > > ... and have a fixed grub2.cfg which basically has the command to parse > the syslinux config file? > OK so there are a few things: 1. The information needed to present boot options, the "menu entries", are a separate thing from the bootloader specific configuration file and file format. And yet all the bootloaders out there conflate these two things, and make the problem of cross compatibility more difficult. 2. The most important and useful part of bootloader spec is splitting them out. A standardized boot menu entry file, and file format, as drop-in snippets, which is "loosely based" on the GRUB 1 grub.conf format. It's just menu entries, and quite simple. 3. The result is bootloader specific configuration files becomes static, non-changing and don't need to contain boot entries (although it's not disallowed). And individual boot menu drop in scripts are how new boot entries are added. The bootloader then merges them together. 4. An issue with using syslinux's format, as well as the original bootloader spec format, and a major source of disagreement, is the assumption that the kernel and initrd are on the same file system as the bootloader and its configuration file. No cross volume hopping. This is necessary to avoid putting the kernel and initrd on the EFI System partition, and causing a lot of installation grief with how to deal with dual boot support. Anyway, regardless of what format you want to base things on, it probably should be a superset of the menu entry functions, including a way to specify volumes by device designation, LVM, or volume UUID, or now your format isn't actually compatible with GRUB on UEFI as well as a bunch of less common scenarios. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
