On Tue, Oct 11, 2016 at 1:53 AM, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: >> 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, ... No. The format must provide superset functionality for all bootloaders. The bootloader can choose how to fail gracefully if a particular boot entry snippet references files in a manner it doesn't support. >> 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 > that way? No. The EFI system partition is intended to be for the firmware: bootloaders and configuration files. That's why by default no system installer, not Fedora's, Ubuntu's, openSUSE, Apple or Microsoft, make them bigger than 260MiB. Many are a good deal smaller. One of the first things the Microsoft bootloader teaches the firmware is how to read NTFS, so it can find and boot the Windows kernel. It's no different than what Fedora and most other distros do. And as I said earlier in the thread, for dual and multiboot systems, the existing ESP is only barely big enough to share when restricted to bootloaders and their files. There simply isn't enough room to put kernels and initramfs's on them at all. And there's no practical way to resize or replace them. > > It isn't that simple on !EFI systems though. Very simple technically, not at all simple politically/cooperatively. > >> 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. It's not workable for all the reasons I've previously mentioned, more reasoning is in this proposed variant of the spec [1]. Plus it's a step backwards for anyone wanting to snapshot /boot along with /usr, so that kernels aren't orphaned from their modules. [1] https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
