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

[darkpenguin]

On 12/09/23 06:54, Oskari Pirhonen wrote:
> On Mon, Sep 11, 2023 at 06:48:58 +0000, darkpenguin wrote:
>>>> 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

I think "try labels, then fall back to nothing" makes no sense. The only
reasonable configuration is "try labels, then fall back to UUID".
Because unlike UUIDs, labels can easily fail (there could be no label),
so there should be a very sensible fallback.

But beside that, why don't we just use whatever is specified in fstab
like Olaf suggested? Do we really need to find a label specified in
fstab, then find its corresponding UUID or device based on a separate
option and use that instead? Well, maybe doing this optionally wouldn't
hurt, but not by default.