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

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

[darkpenguin]

Specifying the boot device by its label rather than its UUID can be
pretty useful in various situations (e.g. multiple test VMs).

This might have to be adapted a little to meet the coding standards I'm
not familiar with. Please feel free to improve it in any way you want.

This patch works for me on an older version of grub2 (=2.06-13 in Debian
Bookworm), but it's rather trivial, and only touches two parts that are
otherwise untouched for ages.

- Specify "GRUB_DISABLE_LINUX_UUID=LABEL" in /etc/default/grub
- It will attempt to use a label instead of UUID
- If a device with the necessary label is not found in
/dev/disk/by-label/ , it falls back to using UUID
- If you just assigned new labels, run 'partprobe' to populate
/dev/disk/by-label/ properly

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
3) I could not figure out how to source other variables from
/etc/defaults/grub and why not all of them are there. :)


---
diff --git a/util/grub-mkconfig_lib.in b/util/grub-mkconfig_lib.in
index 0895328..bd43bc0 100644
--- a/util/grub-mkconfig_lib.in
+++ b/util/grub-mkconfig_lib.in
@@ -158,14 +158,22 @@ prepare_grub_to_access_device ()
   fi
   if [ "x${GRUB_DISABLE_UUID}" != "xtrue" ] &&
fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2> /dev/null`" ; then
     hints="`"${grub_probe}" --device $@ --target=hints_string 2>
/dev/null`" || hints=
+
+    if [ "x${GRUB_DISABLE_LINUX_UUID}" = "xLABEL" ] \
+        && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${fs_uuid} -s
LABEL -o value)" ]; then
+      device="--label $(blkid -l -t UUID=${fs_uuid} -s LABEL -o value)"
+    else
+      device="--fs-uuid ${fs_uuid}"
+    fi
+
     if [ "x$hints" != x ]; then
       echo "if [ x\$feature_platform_search_hint = xy ]; then"
-      echo "  search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}"
+      echo "  search --no-floppy --set=root ${hints} ${device}"
       echo "else"
-      echo "  search --no-floppy --fs-uuid --set=root ${fs_uuid}"
+      echo "  search --no-floppy --set=root ${device}"
       echo "fi"
     else
-      echo "search --no-floppy --fs-uuid --set=root ${fs_uuid}"
+      echo "search --no-floppy --set=root ${device}"
     fi
   fi
   IFS="$old_ifs"
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index cc393be..d29a004 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -61,6 +61,9 @@ if ( [ "x${GRUB_DEVICE_UUID}" = "x" ] && [
"x${GRUB_DEVICE_PARTUUID}" = "x" ] )
 elif [ "x${GRUB_DEVICE_UUID}" = "x" ] \
     || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ]; then
   LINUX_ROOT_DEVICE=PARTUUID=${GRUB_DEVICE_PARTUUID}
+elif [ "x${GRUB_DISABLE_LINUX_UUID}" = "xLABEL" ] \
+    && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${GRUB_DEVICE_UUID}
-s LABEL -o value)" ]; then
+  LINUX_ROOT_DEVICE=LABEL="$(blkid -l -t UUID=${GRUB_DEVICE_UUID} -s
LABEL -o value)"
 else
   LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
 fi

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

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

[Oskari Pirhonen]

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

On Sun, Sep 10, 2023 at 09:30:24 +0000, darkpenguin wrote:
> Specifying the boot device by its label rather than its UUID can be
> pretty useful in various situations (e.g. multiple test VMs).
> 
> This might have to be adapted a little to meet the coding standards I'm
> not familiar with. Please feel free to improve it in any way you want.
> 
> This patch works for me on an older version of grub2 (=2.06-13 in Debian
> Bookworm), but it's rather trivial, and only touches two parts that are
> otherwise untouched for ages.
> 
> - Specify "GRUB_DISABLE_LINUX_UUID=LABEL" in /etc/default/grub
> - It will attempt to use a label instead of UUID
> - If a device with the necessary label is not found in
> /dev/disk/by-label/ , it falls back to using UUID
> - If you just assigned new labels, run 'partprobe' to populate
> /dev/disk/by-label/ properly
> 
> 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.

> 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 ...

Hope that helps.

- 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

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

[darkpenguin]

>> 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.

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?

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

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

[Oskari Pirhonen]

[-- 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

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.

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

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

[Nicholas Vinson]

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

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

[darkpenguin]

On 12/09/23 17:02, Nicholas Vinson wrote:
> 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.

What are the options supported by mount, the kernel and grub? Seems like
most of them are supported by all three. If whatever is in fstab is not
supported by the other two, then obviously booting by that is not
supported, so a fallback should be used. This logic would be simple to
understand.

Alternatively, there could be one new variable GRUB_BOOT_BY that
specifies a list of what to try in what order, and if present, overrides
the current default behaviour for compatibility:

GRUB_BOOT_BY="label,uuid,partuuid,path"

But doing it automatically seems more intuitive than a complex
multi-variable setup that requires tables just to explain the logic
behind something that could be done automatically with a simple fallback
option.

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

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

[Vladimir 'phcoder' Serbinenko]

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

Unlike UUID, label may contain spaces. AFAICT your code fails with spaces

Le dim. 10 sept. 2023, 11:31, darkpenguin <darkpenguin@posteo.de> a écrit :

> Specifying the boot device by its label rather than its UUID can be
> pretty useful in various situations (e.g. multiple test VMs).
>
> This might have to be adapted a little to meet the coding standards I'm
> not familiar with. Please feel free to improve it in any way you want.
>
> This patch works for me on an older version of grub2 (=2.06-13 in Debian
> Bookworm), but it's rather trivial, and only touches two parts that are
> otherwise untouched for ages.
>
> - Specify "GRUB_DISABLE_LINUX_UUID=LABEL" in /etc/default/grub
> - It will attempt to use a label instead of UUID
> - If a device with the necessary label is not found in
> /dev/disk/by-label/ , it falls back to using UUID
> - If you just assigned new labels, run 'partprobe' to populate
> /dev/disk/by-label/ properly
>
> 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
> 3) I could not figure out how to source other variables from
> /etc/defaults/grub and why not all of them are there. :)
>
>
> ---
> diff --git a/util/grub-mkconfig_lib.in b/util/grub-mkconfig_lib.in
> index 0895328..bd43bc0 100644
> --- a/util/grub-mkconfig_lib.in
> +++ b/util/grub-mkconfig_lib.in
> @@ -158,14 +158,22 @@ prepare_grub_to_access_device ()
>    fi
>    if [ "x${GRUB_DISABLE_UUID}" != "xtrue" ] &&
> fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2> /dev/null`" ;
> then
>      hints="`"${grub_probe}" --device $@ --target=hints_string 2>
> /dev/null`" || hints=
> +
> +    if [ "x${GRUB_DISABLE_LINUX_UUID}" = "xLABEL" ] \
> +        && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${fs_uuid} -s
> LABEL -o value)" ]; then
> +      device="--label $(blkid -l -t UUID=${fs_uuid} -s LABEL -o value)"
> +    else
> +      device="--fs-uuid ${fs_uuid}"
> +    fi
> +
>      if [ "x$hints" != x ]; then
>        echo "if [ x\$feature_platform_search_hint = xy ]; then"
> -      echo "  search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}"
> +      echo "  search --no-floppy --set=root ${hints} ${device}"
>        echo "else"
> -      echo "  search --no-floppy --fs-uuid --set=root ${fs_uuid}"
> +      echo "  search --no-floppy --set=root ${device}"
>        echo "fi"
>      else
> -      echo "search --no-floppy --fs-uuid --set=root ${fs_uuid}"
> +      echo "search --no-floppy --set=root ${device}"
>      fi
>    fi
>    IFS="$old_ifs"
> diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
> index cc393be..d29a004 100644
> --- a/util/grub.d/10_linux.in
> +++ b/util/grub.d/10_linux.in
> @@ -61,6 +61,9 @@ if ( [ "x${GRUB_DEVICE_UUID}" = "x" ] && [
> "x${GRUB_DEVICE_PARTUUID}" = "x" ] )
>  elif [ "x${GRUB_DEVICE_UUID}" = "x" ] \
>      || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ]; then
>    LINUX_ROOT_DEVICE=PARTUUID=${GRUB_DEVICE_PARTUUID}
> +elif [ "x${GRUB_DISABLE_LINUX_UUID}" = "xLABEL" ] \
> +    && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${GRUB_DEVICE_UUID}
> -s LABEL -o value)" ]; then
> +  LINUX_ROOT_DEVICE=LABEL="$(blkid -l -t UUID=${GRUB_DEVICE_UUID} -s
> LABEL -o value)"
>  else
>    LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
>  fi
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #1.2: Type: text/html, Size: 5394 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

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

[darkpenguin]

On 11/09/23 01:20, Vladimir 'phcoder' Serbinenko wrote:
> Unlike UUID, label may contain spaces. AFAICT your code fails with spaces

Good catch! I'll fix it.


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

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

[darkpenguin]

On 11/09/23 01:20, Vladimir 'phcoder' Serbinenko wrote:
> Unlike UUID, label may contain spaces. AFAICT your code fails with spaces

It fails indeed. However, I can't even figure out how to make spaces in
labels work for *anything* - not only grub.cfg, but also fstab. Neither
quoting nor escaping them works. Also, it can probably contain other
symbols that get mangled into escaped sequences in /dev/disk/by-label/.
So, seeing that supporting spaces and other symbols in the boot device
is barely possible, wouldn't it be better to just fall back to UUID if
the label is too "unusual" to not require any "mangling" into escape
sequences?

If not, then how should I approach this for both grub.cfg and fstab?

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

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

[darkpenguin]

Here is an updated patch that uses GRUB_ENABLE_LINUX_LABEL=true instead.

Supporting whitespace or other symbols in the label doesn't make sense
until we can figure out how to properly specify them in grub.cfg - so
far, nothing I've tried works (escaping, quoting, %20, \x20).


---
diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index 32c480dae..fb5000d3f 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -244,6 +244,7 @@ export GRUB_DEFAULT \
   GRUB_DISABLE_UUID \
   GRUB_DISABLE_LINUX_UUID \
   GRUB_DISABLE_LINUX_PARTUUID \
+  GRUB_ENABLE_LINUX_LABEL \
   GRUB_DISABLE_RECOVERY \
   GRUB_VIDEO_BACKEND \
   GRUB_GFXMODE \
diff --git a/util/grub-mkconfig_lib.in b/util/grub-mkconfig_lib.in
index 08953287c..dd726c4b3 100644
--- a/util/grub-mkconfig_lib.in
+++ b/util/grub-mkconfig_lib.in
@@ -158,14 +158,22 @@ prepare_grub_to_access_device ()
   fi
   if [ "x${GRUB_DISABLE_UUID}" != "xtrue" ] &&
fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2> /dev/null`" ; then
     hints="`"${grub_probe}" --device $@ --target=hints_string 2>
/dev/null`" || hints=
+
+    if [ "x${GRUB_ENABLE_LINUX_LABEL}" = "xtrue" ] \
+        && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${fs_uuid} -s
LABEL -o value)" ]; then
+      device="--label $(blkid -l -t UUID=${fs_uuid} -s LABEL -o value)"
+    else
+      device="--fs-uuid ${fs_uuid}"
+    fi
+
     if [ "x$hints" != x ]; then
       echo "if [ x\$feature_platform_search_hint = xy ]; then"
-      echo "  search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}"
+      echo "  search --no-floppy --set=root ${hints} ${device}"
       echo "else"
-      echo "  search --no-floppy --fs-uuid --set=root ${fs_uuid}"
+      echo "  search --no-floppy --set=root ${device}"
       echo "fi"
     else
-      echo "search --no-floppy --fs-uuid --set=root ${fs_uuid}"
+      echo "search --no-floppy --set=root ${device}"
     fi
   fi
   IFS="$old_ifs"
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index cc393be7e..04b973fe7 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -61,6 +61,9 @@ if ( [ "x${GRUB_DEVICE_UUID}" = "x" ] && [
"x${GRUB_DEVICE_PARTUUID}" = "x" ] )
 elif [ "x${GRUB_DEVICE_UUID}" = "x" ] \
     || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ]; then
   LINUX_ROOT_DEVICE=PARTUUID=${GRUB_DEVICE_PARTUUID}
+elif [ "x${GRUB_ENABLE_LINUX_LABEL}" = "xtrue" ] \
+    && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${GRUB_DEVICE_UUID}
-s LABEL -o value)" ]; then
+  LINUX_ROOT_DEVICE=LABEL="$(blkid -l -t UUID=${GRUB_DEVICE_UUID} -s
LABEL -o value)"
 else
   LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
 fi

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

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

[Daniel Kiper]

On Wed, Sep 27, 2023 at 06:51:38AM +0000, darkpenguin wrote:
> Here is an updated patch that uses GRUB_ENABLE_LINUX_LABEL=true instead.
>
> Supporting whitespace or other symbols in the label doesn't make sense
> until we can figure out how to properly specify them in grub.cfg - so
> far, nothing I've tried works (escaping, quoting, %20, \x20).

I suggest to repost this patch using "git format-patch" and
"git send-email" commands with proper commit message and CC
all people involved in this thread.

Daniel

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

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

[darkpenguin]

Oh, so that's how you send them! Thanks, I did not know the correct
procedure.


On 27/09/23 14:16, Daniel Kiper wrote:
> On Wed, Sep 27, 2023 at 06:51:38AM +0000, darkpenguin wrote:
>> Here is an updated patch that uses GRUB_ENABLE_LINUX_LABEL=true instead.
>>
>> Supporting whitespace or other symbols in the label doesn't make sense
>> until we can figure out how to properly specify them in grub.cfg - so
>> far, nothing I've tried works (escaping, quoting, %20, \x20).
> 
> I suggest to repost this patch using "git format-patch" and
> "git send-email" commands with proper commit message and CC
> all people involved in this thread.
> 
> Daniel
> 
> _______________________________________________
> 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

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

[Vladimir 'phcoder' Serbinenko]

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

Le mer. 27 sept. 2023, 08:52, darkpenguin <darkpenguin@posteo.de> a écrit :

> Here is an updated patch that uses GRUB_ENABLE_LINUX_LABEL=true instead.
>
> Supporting whitespace or other symbols in the label doesn't make sense
> until we can figure out how to properly specify them in grub.cfg - so
> far, nothing I've tried works (escaping, quoting, %20, \x20).
>
Escaping and quoting both work as long as escaping/quoting is propagated to
actual generated grub.cfg

>
>
> ---
> diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
> index 32c480dae..fb5000d3f 100644
> --- a/util/grub-mkconfig.in
> +++ b/util/grub-mkconfig.in
> @@ -244,6 +244,7 @@ export GRUB_DEFAULT \
>    GRUB_DISABLE_UUID \
>    GRUB_DISABLE_LINUX_UUID \
>    GRUB_DISABLE_LINUX_PARTUUID \
> +  GRUB_ENABLE_LINUX_LABEL \
>    GRUB_DISABLE_RECOVERY \
>    GRUB_VIDEO_BACKEND \
>    GRUB_GFXMODE \
> diff --git a/util/grub-mkconfig_lib.in b/util/grub-mkconfig_lib.in
> index 08953287c..dd726c4b3 100644
> --- a/util/grub-mkconfig_lib.in
> +++ b/util/grub-mkconfig_lib.in
> @@ -158,14 +158,22 @@ prepare_grub_to_access_device ()
>    fi
>    if [ "x${GRUB_DISABLE_UUID}" != "xtrue" ] &&
> fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2> /dev/null`" ;
> then
>      hints="`"${grub_probe}" --device $@ --target=hints_string 2>
> /dev/null`" || hints=
> +
> +    if [ "x${GRUB_ENABLE_LINUX_LABEL}" = "xtrue" ] \
> +        && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${fs_uuid} -s
> LABEL -o value)" ]; then
> +      device="--label $(blkid -l -t UUID=${fs_uuid} -s LABEL -o value)"
> +    else
> +      device="--fs-uuid ${fs_uuid}"
> +    fi
> +
>      if [ "x$hints" != x ]; then
>        echo "if [ x\$feature_platform_search_hint = xy ]; then"
> -      echo "  search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}"
> +      echo "  search --no-floppy --set=root ${hints} ${device}"
>        echo "else"
> -      echo "  search --no-floppy --fs-uuid --set=root ${fs_uuid}"
> +      echo "  search --no-floppy --set=root ${device}"
>        echo "fi"
>      else
> -      echo "search --no-floppy --fs-uuid --set=root ${fs_uuid}"
> +      echo "search --no-floppy --set=root ${device}"
>      fi
>    fi
>    IFS="$old_ifs"
> diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
> index cc393be7e..04b973fe7 100644
> --- a/util/grub.d/10_linux.in
> +++ b/util/grub.d/10_linux.in
> @@ -61,6 +61,9 @@ if ( [ "x${GRUB_DEVICE_UUID}" = "x" ] && [
> "x${GRUB_DEVICE_PARTUUID}" = "x" ] )
>  elif [ "x${GRUB_DEVICE_UUID}" = "x" ] \
>      || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ]; then
>    LINUX_ROOT_DEVICE=PARTUUID=${GRUB_DEVICE_PARTUUID}
> +elif [ "x${GRUB_ENABLE_LINUX_LABEL}" = "xtrue" ] \
> +    && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${GRUB_DEVICE_UUID}
> -s LABEL -o value)" ]; then
> +  LINUX_ROOT_DEVICE=LABEL="$(blkid -l -t UUID=${GRUB_DEVICE_UUID} -s
> LABEL -o value)"
>  else
>    LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
>  fi
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #1.2: Type: text/html, Size: 5448 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

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

[darkpenguin]

I've tried manually specifying a boot device, by editing the menu items
while in the grub menu - to confirm that it works before tackling
propagation. And I just confirmed it again - no, none of them work.

I manually change "search --no-floppy --set=root --fs-uuid ..." to
"<...> --label my\ label", and "linux <...> root=UUID=..." to "linux
<...> root=LABEL=my\ label". The boot process stops at "No root device
specified. Boot arguments must include a root= parameter".

But even if whitespace works, there is still an issue with all the other
possible symbols. Which are also escaped differently in
/dev/disk/by-label/ . So to keep the scope of the change to a minimum, I
suggest a "label is only supported with no weird stuff in it" approach.


On 27/09/23 19:22, Vladimir 'phcoder' Serbinenko wrote:
> 
> 
> Le mer. 27 sept. 2023, 08:52, darkpenguin <darkpenguin@posteo.de
> <mailto:darkpenguin@posteo.de>> a écrit :
> 
>     Here is an updated patch that uses GRUB_ENABLE_LINUX_LABEL=true instead.
> 
>     Supporting whitespace or other symbols in the label doesn't make sense
>     until we can figure out how to properly specify them in grub.cfg - so
>     far, nothing I've tried works (escaping, quoting, %20, \x20).
> 
> Escaping and quoting both work as long as escaping/quoting is propagated
> to actual generated grub.cfg
> 
> 
> 
>     ---
>     diff --git a/util/grub-mkconfig.in <http://grub-mkconfig.in>
>     b/util/grub-mkconfig.in <http://grub-mkconfig.in>
>     index 32c480dae..fb5000d3f 100644
>     --- a/util/grub-mkconfig.in <http://grub-mkconfig.in>
>     +++ b/util/grub-mkconfig.in <http://grub-mkconfig.in>
>     @@ -244,6 +244,7 @@ export GRUB_DEFAULT \
>        GRUB_DISABLE_UUID \
>        GRUB_DISABLE_LINUX_UUID \
>        GRUB_DISABLE_LINUX_PARTUUID \
>     +  GRUB_ENABLE_LINUX_LABEL \
>        GRUB_DISABLE_RECOVERY \
>        GRUB_VIDEO_BACKEND \
>        GRUB_GFXMODE \
>     diff --git a/util/grub-mkconfig_lib.in <http://grub-mkconfig_lib.in>
>     b/util/grub-mkconfig_lib.in <http://grub-mkconfig_lib.in>
>     index 08953287c..dd726c4b3 100644
>     --- a/util/grub-mkconfig_lib.in <http://grub-mkconfig_lib.in>
>     +++ b/util/grub-mkconfig_lib.in <http://grub-mkconfig_lib.in>
>     @@ -158,14 +158,22 @@ prepare_grub_to_access_device ()
>        fi
>        if [ "x${GRUB_DISABLE_UUID}" != "xtrue" ] &&
>     fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2>
>     /dev/null`" ; then
>          hints="`"${grub_probe}" --device $@ --target=hints_string 2>
>     /dev/null`" || hints=
>     +
>     +    if [ "x${GRUB_ENABLE_LINUX_LABEL}" = "xtrue" ] \
>     +        && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${fs_uuid} -s
>     LABEL -o value)" ]; then
>     +      device="--label $(blkid -l -t UUID=${fs_uuid} -s LABEL -o value)"
>     +    else
>     +      device="--fs-uuid ${fs_uuid}"
>     +    fi
>     +
>          if [ "x$hints" != x ]; then
>            echo "if [ x\$feature_platform_search_hint = xy ]; then"
>     -      echo "  search --no-floppy --fs-uuid --set=root ${hints}
>     ${fs_uuid}"
>     +      echo "  search --no-floppy --set=root ${hints} ${device}"
>            echo "else"
>     -      echo "  search --no-floppy --fs-uuid --set=root ${fs_uuid}"
>     +      echo "  search --no-floppy --set=root ${device}"
>            echo "fi"
>          else
>     -      echo "search --no-floppy --fs-uuid --set=root ${fs_uuid}"
>     +      echo "search --no-floppy --set=root ${device}"
>          fi
>        fi
>        IFS="$old_ifs"
>     diff --git a/util/grub.d/10_linux.in <http://10_linux.in>
>     b/util/grub.d/10_linux.in <http://10_linux.in>
>     index cc393be7e..04b973fe7 100644
>     --- a/util/grub.d/10_linux.in <http://10_linux.in>
>     +++ b/util/grub.d/10_linux.in <http://10_linux.in>
>     @@ -61,6 +61,9 @@ if ( [ "x${GRUB_DEVICE_UUID}" = "x" ] && [
>     "x${GRUB_DEVICE_PARTUUID}" = "x" ] )
>      elif [ "x${GRUB_DEVICE_UUID}" = "x" ] \
>          || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ]; then
>        LINUX_ROOT_DEVICE=PARTUUID=${GRUB_DEVICE_PARTUUID}
>     +elif [ "x${GRUB_ENABLE_LINUX_LABEL}" = "xtrue" ] \
>     +    && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${GRUB_DEVICE_UUID}
>     -s LABEL -o value)" ]; then
>     +  LINUX_ROOT_DEVICE=LABEL="$(blkid -l -t UUID=${GRUB_DEVICE_UUID} -s
>     LABEL -o value)"
>      else
>        LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
>      fi
> 
>     _______________________________________________
>     Grub-devel mailing list
>     Grub-devel@gnu.org <mailto: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
> 

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

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

[Vladimir 'phcoder' Serbinenko]

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

Le mer. 27 sept. 2023, 17:43, darkpenguin <darkpenguin@posteo.de> a écrit :

> I've tried manually specifying a boot device, by editing the menu items
> while in the grub menu - to confirm that it works before tackling
> propagation. And I just confirmed it again - no, none of them work.
>
> I manually change "search --no-floppy --set=root --fs-uuid ..." to
> "<...> --label my\ label", and "linux <...> root=UUID=..." to "linux
> <...> root=LABEL=my\ label". The boot process stops at "No root device
> specified. Boot arguments must include a root= parameter".
>

root= is not handled by GRUB but by kernel. You need to consult separately
with kernel and initramfs scripts on how to handle it and it's separate
from handling search line.

>
> But even if whitespace works, there is still an issue with all the other
> possible symbols. Which are also escaped differently in
> /dev/disk/by-label/ . So to keep the scope of the change to a minimum, I
> suggest a "label is only supported with no weird stuff in it" approach.
>

That is the road to creating unbootable system. It's better not to push
such a risk to the distros.

>
>
> On 27/09/23 19:22, Vladimir 'phcoder' Serbinenko wrote:
> >
> >
> > Le mer. 27 sept. 2023, 08:52, darkpenguin <darkpenguin@posteo.de
> > <mailto:darkpenguin@posteo.de>> a écrit :
> >
> >     Here is an updated patch that uses GRUB_ENABLE_LINUX_LABEL=true
> instead.
> >
> >     Supporting whitespace or other symbols in the label doesn't make
> sense
> >     until we can figure out how to properly specify them in grub.cfg - so
> >     far, nothing I've tried works (escaping, quoting, %20, \x20).
> >
> > Escaping and quoting both work as long as escaping/quoting is propagated
> > to actual generated grub.cfg
> >
> >
> >
> >     ---
> >     diff --git a/util/grub-mkconfig.in <http://grub-mkconfig.in>
> >     b/util/grub-mkconfig.in <http://grub-mkconfig.in>
> >     index 32c480dae..fb5000d3f 100644
> >     --- a/util/grub-mkconfig.in <http://grub-mkconfig.in>
> >     +++ b/util/grub-mkconfig.in <http://grub-mkconfig.in>
> >     @@ -244,6 +244,7 @@ export GRUB_DEFAULT \
> >        GRUB_DISABLE_UUID \
> >        GRUB_DISABLE_LINUX_UUID \
> >        GRUB_DISABLE_LINUX_PARTUUID \
> >     +  GRUB_ENABLE_LINUX_LABEL \
> >        GRUB_DISABLE_RECOVERY \
> >        GRUB_VIDEO_BACKEND \
> >        GRUB_GFXMODE \
> >     diff --git a/util/grub-mkconfig_lib.in <http://grub-mkconfig_lib.in>
> >     b/util/grub-mkconfig_lib.in <http://grub-mkconfig_lib.in>
> >     index 08953287c..dd726c4b3 100644
> >     --- a/util/grub-mkconfig_lib.in <http://grub-mkconfig_lib.in>
> >     +++ b/util/grub-mkconfig_lib.in <http://grub-mkconfig_lib.in>
> >     @@ -158,14 +158,22 @@ prepare_grub_to_access_device ()
> >        fi
> >        if [ "x${GRUB_DISABLE_UUID}" != "xtrue" ] &&
> >     fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2>
> >     /dev/null`" ; then
> >          hints="`"${grub_probe}" --device $@ --target=hints_string 2>
> >     /dev/null`" || hints=
> >     +
> >     +    if [ "x${GRUB_ENABLE_LINUX_LABEL}" = "xtrue" ] \
> >     +        && [ -b "/dev/disk/by-label/$(blkid -l -t UUID=${fs_uuid} -s
> >     LABEL -o value)" ]; then
> >     +      device="--label $(blkid -l -t UUID=${fs_uuid} -s LABEL -o
> value)"
> >     +    else
> >     +      device="--fs-uuid ${fs_uuid}"
> >     +    fi
> >     +
> >          if [ "x$hints" != x ]; then
> >            echo "if [ x\$feature_platform_search_hint = xy ]; then"
> >     -      echo "  search --no-floppy --fs-uuid --set=root ${hints}
> >     ${fs_uuid}"
> >     +      echo "  search --no-floppy --set=root ${hints} ${device}"
> >            echo "else"
> >     -      echo "  search --no-floppy --fs-uuid --set=root ${fs_uuid}"
> >     +      echo "  search --no-floppy --set=root ${device}"
> >            echo "fi"
> >          else
> >     -      echo "search --no-floppy --fs-uuid --set=root ${fs_uuid}"
> >     +      echo "search --no-floppy --set=root ${device}"
> >          fi
> >        fi
> >        IFS="$old_ifs"
> >     diff --git a/util/grub.d/10_linux.in <http://10_linux.in>
> >     b/util/grub.d/10_linux.in <http://10_linux.in>
> >     index cc393be7e..04b973fe7 100644
> >     --- a/util/grub.d/10_linux.in <http://10_linux.in>
> >     +++ b/util/grub.d/10_linux.in <http://10_linux.in>
> >     @@ -61,6 +61,9 @@ if ( [ "x${GRUB_DEVICE_UUID}" = "x" ] && [
> >     "x${GRUB_DEVICE_PARTUUID}" = "x" ] )
> >      elif [ "x${GRUB_DEVICE_UUID}" = "x" ] \
> >          || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ]; then
> >        LINUX_ROOT_DEVICE=PARTUUID=${GRUB_DEVICE_PARTUUID}
> >     +elif [ "x${GRUB_ENABLE_LINUX_LABEL}" = "xtrue" ] \
> >     +    && [ -b "/dev/disk/by-label/$(blkid -l -t
> UUID=${GRUB_DEVICE_UUID}
> >     -s LABEL -o value)" ]; then
> >     +  LINUX_ROOT_DEVICE=LABEL="$(blkid -l -t UUID=${GRUB_DEVICE_UUID} -s
> >     LABEL -o value)"
> >      else
> >        LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
> >      fi
> >
> >     _______________________________________________
> >     Grub-devel mailing list
> >     Grub-devel@gnu.org <mailto: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
> >
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #1.2: Type: text/html, Size: 10469 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

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

[Olaf Hering]

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

Sun, 10 Sep 2023 09:30:24 +0000 darkpenguin <darkpenguin@posteo.de>:

> 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 mounted. The details how it must be done is
configured by the local admin via the well establish file /etc/fstab,
and of course other block device related configuration files.

As you have noted, any such decision is outright ignored by grub2.

So instead of adding more to the existing arrogance, please remove
the offending code and implement something that respects the local
configuration files.

Thank you.


Olaf

[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 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

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

[darkpenguin]

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 understandable in the past, when maybe Grub did not support
UUIDs or labels, so the algorithm would have been "find the specified
device, then find its path and use that". But now we can simply reuse
exactly what's specified in fstab, can't we? (Though I'm afraid figuring
out that process is beyond my skill or capacity at the moment.)


On 11/09/23 14:44, Olaf Hering wrote:
> Sun, 10 Sep 2023 09:30:24 +0000 darkpenguin <darkpenguin@posteo.de>:
> 
>> 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 mounted. The details how it must be done is
> configured by the local admin via the well establish file /etc/fstab,
> and of course other block device related configuration files.
> 
> As you have noted, any such decision is outright ignored by grub2.
> 
> So instead of adding more to the existing arrogance, please remove
> the offending code and implement something that respects the local
> configuration files.
> 
> Thank you.
> 
> 
> Olaf
> 
> 
> 
> _______________________________________________
> 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

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

[Nicholas Vinson]

On 9/11/23 07:15, darkpenguin wrote:
> 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 understandable in the past, when maybe Grub did not support
> UUIDs or labels, so the algorithm would have been "find the specified
> device, then find its path and use that". But now we can simply reuse
> exactly what's specified in fstab, can't we? (Though I'm afraid figuring
> out that process is beyond my skill or capacity at the moment.)
>
You can write an entry into /etc/fstab that identifies the the rootfs by 
label, uuid, or something else that's supported by `mount`, the init 
system will correctly remount the rootfs using that entry, but if you 
told the kernel to do it, it'd panic with an error (most likely "unknown 
block-device") because the kernel is limited to supporting a very small 
subset of methods.The same argument hold with initramfs images too; 
however, the de-facto standard is that initramfs images support 
root=UUID=... where the UUID is the fs UUID. Therefore, it's assumed 
that with an initramfs, you can mount with device name, partition uuid, 
or fs-uuid. Without an initramfs, booting can only be done using device 
name and partition uuid.

Put simply, the rootfs entry in /etc/fstab (assuming it has one) cannot 
be used to determine how to mount the device at boot time because the 
entry might use a method that neither the kernel nor the initramfs supports.

> On 11/09/23 14:44, Olaf Hering wrote:
>> Sun, 10 Sep 2023 09:30:24 +0000 darkpenguin <darkpenguin@posteo.de>:
>>
>>> 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 mounted. The details how it must be done is
>> configured by the local admin via the well establish file /etc/fstab,
>> and of course other block device related configuration files.
>>
>> As you have noted, any such decision is outright ignored by grub2.
>>
>> So instead of adding more to the existing arrogance, please remove
>> the offending code and implement something that respects the local
>> configuration files.
>>
>> Thank you.
>>
>>
>> Olaf
>>
>>
>>
>> _______________________________________________
>> 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

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

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

[darkpenguin]

On 12/09/23 16:10, Nicholas Vinson wrote:
> On 9/11/23 07:15, darkpenguin wrote:
>> 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 understandable in the past, when maybe Grub did not support
>> UUIDs or labels, so the algorithm would have been "find the specified
>> device, then find its path and use that". But now we can simply reuse
>> exactly what's specified in fstab, can't we? (Though I'm afraid figuring
>> out that process is beyond my skill or capacity at the moment.)
>>
> You can write an entry into /etc/fstab that identifies the the rootfs by 
> label, uuid, or something else that's supported by `mount`, the init 
> system will correctly remount the rootfs using that entry, but if you 
> told the kernel to do it, it'd panic with an error (most likely "unknown 
> block-device") because the kernel is limited to supporting a very small 
> subset of methods.The same argument hold with initramfs images too; 
> however, the de-facto standard is that initramfs images support 
> root=UUID=... where the UUID is the fs UUID. Therefore, it's assumed 
> that with an initramfs, you can mount with device name, partition uuid, 
> or fs-uuid. Without an initramfs, booting can only be done using device 
> name and partition uuid.
> 
> Put simply, the rootfs entry in /etc/fstab (assuming it has one) cannot 
> be used to determine how to mount the device at boot time because the 
> entry might use a method that neither the kernel nor the initramfs supports.

So then... Get whatever is specified in fstab, then try to use that
as-is, or fall back to either UUID of device name as per
GRUB_ENABLE_LINUX_UUID ?

There are now labels, which seem to be supported by any of those (or
not?); what else could there be in fstab that's not supported by
grub/kernel?

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

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

[Vladimir 'phcoder' Serbinenko]

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

Le lun. 11 sept. 2023, 13:16, darkpenguin <darkpenguin@posteo.de> a écrit :

> Hmmm, this is actually a good idea. Grub does determine the boot device
> by analyzing fstab, doesn't it?


No it doesn't

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 understandable in the past, when maybe Grub did not support
> UUIDs or labels, so the algorithm would have been "find the specified
> device, then find its path and use that". But now we can simply reuse
> exactly what's specified in fstab, can't we? (Though I'm afraid figuring
> out that process is beyond my skill or capacity at the moment.)
>
>
> On 11/09/23 14:44, Olaf Hering wrote:
> > Sun, 10 Sep 2023 09:30:24 +0000 darkpenguin <darkpenguin@posteo.de>:
> >
> >> 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 mounted. The details how it must be done is
> > configured by the local admin via the well establish file /etc/fstab,
> > and of course other block device related configuration files.
> >
> > As you have noted, any such decision is outright ignored by grub2.
> >
> > So instead of adding more to the existing arrogance, please remove
> > the offending code and implement something that respects the local
> > configuration files.
> >
> > Thank you.
> >
> >
> > Olaf
> >
> >
> >
> > _______________________________________________
> > 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
>

[-- Attachment #1.2: Type: text/html, Size: 3172 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