On Mon, Sep 11, 2023 at 06:48:58 +, darkpenguin wrote:
> >> 3) I could not figure out how to source other variables from
> >> /etc/defaults/grub and why not all of them are there. :)
> >>
> >
> > This looks to be in util/grub-mkconfig.in (lines 160-162 in git master
> > at the time of writing)
It turns out that setting $xen_version in linux_entry_xsm() override
$xen_version in the loop over $reverse_sorted_xen_list. This means
that only one entry per Xen version is going to enable XSM, but all
further entries are going to have "(XSM enabled)" in their titles
without enabling XSM.
When a
On Thu, Aug 31, 2023 at 07:46:52PM +0200, Daniel Kiper wrote:
> On Tue, Aug 15, 2023 at 03:00:53PM +0100, Anthony PERARD via Grub-devel wrote:
> > It turns out that setting $xen_version in linux_entry_xsm() override
> > $xen_version in the loop over $xen_list. This means that only one
>
> s/xen_li
Hmmm, this is actually a good idea. Grub does determine the boot device
by analyzing fstab, doesn't it? Why does it then use either UUIDs or
device paths, based on a configuration in a separate file, instead of
simply reusing exactly what it has found specified in fstab? That would
have been unders
Sun, 10 Sep 2023 09:30:24 + darkpenguin :
> Specifying the boot device by its label rather than its UUID can be
> pretty useful in various situations (e.g. multiple test VMs).
Yes, this is very true.
It is up to the local admin to decide how the various block devices
are supposed to be mount
