[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #60892] Using blscfg /loader/entries from other bootloaders

From: Mike Beaton
Subject: [bug #60892] Using blscfg /loader/entries from other bootloaders
Date: Wed, 7 Jul 2021 10:28:36 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36


                 Summary: Using blscfg /loader/entries from other bootloaders
                 Project: GNU GRUB
            Submitted by: bmju
            Submitted on: Wed 07 Jul 2021 02:28:34 PM UTC
                Category: Booting
                Severity: Major
                Priority: 5 - Normal
              Item Group: Feature Request
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Mike Beaton
        Originator Email: mjsbeaton@gmail.com
             Open/Closed: Open
                 Release: 2.02
         Discussion Lock: Any
         Reproducibility: Every Time
         Planned Release: None



I was looking at the use of Boot Loader Specification by blscfg, and as
documented e.g. at
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault the adherence
to the spec is somewhat loose.

Two key differences:

1. The /loader/entries files are on the boot partition itself, and not on
either ESP or XBOOTLDR partitions (the only locations allowed in BLSpec).

2. The /loader/entries files can include named variables (e.g. $kernelopts,
$tuned_initrd, etc.) which are obtained from various locations (though, in
principle, from anywhere within the grub config scripts).

I was hoping that the presence of these /loader/entries files would allow
another bootloader to identify the correct boot args to directly start an
EFISTUB kernel.

Point 1 helps with this.

Point 2 however currently makes it not possible to successfully parse the
files. ($kernelopts can be found within grub2/grubenv, but the $tuned_### vars
are unfortunately inlined within the grub config scripts.)

Is there any possibility at all of an update which overcomes this - perhaps
either by standardising on a way of specifying (the file locations of) all
such variables, so that they can be found and applied by other bootloaders; or
simply by expanding out all such variable references in these files?


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]