On 9/12/23 03:42, darkpenguin wrote:
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.
The scenario "try labels, then fallback to nothing" makes no sense
because it's not a valid scenario. If all *UUID options are disabled,
GRUB falls back to device name. Moreover, the case where everything is
enabled also needs to be considered.
Any supporting initramfs can boot-by-label, but what about the kernel?
Turns out the kernel source file init/do_mounts.c lists it as the 9th
valid boot option.
Since both kernel and initramfs support booting by label, you need a
variable that can independently enable and disable it. For compatibility
with existing settings, this variable needs to default to disabling
boot-by-label. Three possible names for the variable come to mind:
GRUB_DISABLE_LINUX_LABEL, GRUB_ENABLE_LINUX_LABEL,
GRUB_PREFER_LINUX_LABEL. I believe the first name would be the most
consistent with existing GRUB practice.
How does this variable interact with the other options? If both label
and UUID booting are enabled, does GRUB give up complaining about
conflicting settings? Certainly an option. Perhaps it prefers UUID over
labels? That's also an option. However, this is a feature you want, so
why make it any more difficult to use than you have to? Make
boot-by-label the preferred method over everything else!
Now you just need to describe how all these pieces interact in an
easy-to-understand manner. The GRUB_DISABLE_LINUX_PARTUUID uses a table
in the help-text. Perhaps modifying that would be a good start. I
recommend drawing this table before making any code changes, as the
table will help you both in development and testing.
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.
Answered in a different reply, but I'll provide a short summary here.
When /etc/fstab is read, it has access to all mounting methods the
system supports. At boot, the mounting methods are restricted to what
the kernel or initramfs supports. It's possible that the neither the
kernel nor the initramfs support the method written in /etc/fstab. In
those cases, using the mount method mentioned in /etc/fstab will cause a
boot failure.
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
