Re: grub, grubby, btrfs, was: PSA: Do not run 'dnf update' inside GNOME, KDE ...
On Mon, Oct 10, 2016 at 2:17 AM, Gerd Hoffmann <kraxel(a)redhat.com> 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