On Wed, Nov 15, 2023 at 03:12:44AM -0800, Oliver Steffen wrote: > Quoting Vladimir 'phcoder' Serbinenko (2023-11-14 19:21:49) > > In general series looks good. Few comments: > > * I'm unsure about the name. It seems to suggest that people put the > > dependencies there by default while in fact it's the last place for it. > > Maybe > > extra_deps.lst? > > > Sounds good to me. > > Are we ok with the '.lst' extension? Files of this type are listed in > .gitignore and this would be an exception.
I think we can live with lst extension if we do not come up with something better. > > * EFI supports both GPT and msdos. GPT is a more common choice but I still > > think that a dependency on part_msdos is warranted > > bli does not make use of msdos partitions. It ignores them. > > bli implements a small part of the Boot Loader Interface spec [1], by > setting some EFI variables that are later consumed by systemd. One of > them contains the GPT UUID of the ESP/the partition used during boot. > This is needed to make systemd's partition autodetection work [2,3]. All > of this is build around GPT and uses the UUIDs of GPTm and does not work > with msdos formatted disks. > > [1] https://systemd.io/BOOT_LOADER_INTERFACE/ > [2] > https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html > [3] > https://uapi-group.org/specifications/specs/discoverable_partitions_specification I expected that Boot Loader Interface does not use MBR at all and rely entirely on GPT. However, I think we should make it clear in the GRUB documentation to avoid complaints/confusion/... in the future. Oliver, could you add relevant blurb to docs? > > * Please elaborate commit message as to why bli needs those mods rather than > > "not functions properly". Detail that it needs to identify partitions. > > I can do that. > bli tries to read the UUID of the ESP/the partition Grub was loaded > from. If that is not GPT or otherwise not reachable, then it does not > set the corresponding EFI variable, but c Yeah, more or less like that makes sense for me. Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
