Re: [PATCH] Add support for specifying the boot device by label

[Oskari Pirhonen <xxc3ncoredxx@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2878 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel