> > ... 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
Yep. You see some fallout from that on arm for example, with uboot
printing "don't understand $this, skipping line" style messages when
> 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.
And that would make the grub2.cfg mess alot less painful.
> 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.
Dropping that assumption makes the boot loaders alot more complex
though. Suddenly you can't rely on the firmware any more for file
access, need to understand partition schemes and filesystems, ...
> 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.
Hmm, not sure why you want avoid that, as I understand it the idea of
the efi system partition is that everything needed to boot is there (for
all operating systems in case of dual/multi-boot). So why don't use it
It isn't that simple on !EFI systems though.
> 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.
Well, the bootloaderspec menu *entries* should not need that, just place
them next to kernel + initrd and have a pointer to the directory (plus
optional volume in case you place them outside the efi system partition,
or on !EFI systems) to scan into the bootloader config file.
devel mailing list -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org