On Mon, Sep 11, 2023 at 06:48:58 +0000, 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):
> >
> > if test -f ${sysconfdir}/default/grub ; then
> > . ${sysconfdir}/default/grub
> > fi
> >
> > The vars then get exported further down (lines 213-258) before running
> > the various config snippets:
> >
> > # These are optional, user-defined variables.
> > export GRUB_DEFAULT \
> > GRUB_HIDDEN_TIMEOUT \
> > GRUB_HIDDEN_TIMEOUT_QUIET \
> > GRUB_TIMEOUT \
> > GRUB_TIMEOUT_STYLE \
> > GRUB_DEFAULT_BUTTON \
> > # ... snip ...
>
> Thanks for the explanation about the vars! I've found it.
>
>
> >> The decision to reuse GRUB_DISABLE_LINUX_UUID was because:
> >> 1) This is more of an addition on top of UUID rather than "disabling"
> >> it, it still uses UUID internally, and it falls back to UUID
> >> 2) I could not come up with a better way to do it
> >
> > I'm not a fan of overloading a "disable" var to mean "try something
> > else first". Something like GRUB_DISABLE_LINUX_LABEL with the
> > appropriate logic would make more sense IMO.
>
> Then how should we do it? I wouldn't want this to be the default
> behaviour - it's only useful in specific cases, so I think
> GRUB_DISABLE_LINUX_LABEL is a bad idea. So then we have
> GRUB_DISABLE_LINUX_UUID and GRUB_ENABLE_TRYING_LABEL_BEFORE_UUID, which
> requires not disabling UUID. This looks much more like a mess.
> GRUB_DISABLE_LINUX_LABEL could be default-true if it's only useful in specific cases like you say. > My reasoning was: previously, we had two modes - "use UUID" and "don't > use UUID". Now we are introducing a third more - "try labels, then use > UUID". It feels like the mode should be controlled by one variable that > accepts one of three possible values. Since renaming the variable to > GRUB_LINUX_MODE would be too much of a breaking change, maybe we should > just make the old one accept one of three possible values? > - true - enable UUID > - LABEL - enable UUID, but try labels on top of UUID first > - anything else - don't use UUID > > Maybe later we can figure out the best way to do this based on feedback, > but to minimize change when introducing a proof-of-concept feature, this > seems more appropriate, doesn't it? > Is there a reason using labels can't be a separate third option? Completely distinct and not tied to UUID's at all. I haven't played around with it, whereas you probably have. If there isn't a need to have them together, then the third mode would be "use labels" (and possibly a fourth of "use labels or UUID's"). - Oskari
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
