Re: [PATCH] Allow specifying the boot device by its label instead of UUID

2023-09-28 Thread darkpenguin
t the proper procedure and conventions because they are not in the manuals. :) > On Wed, Sep 27, 2023 at 16:25:23 +, darkpenguin wrote: >> Here it is, as a single patch, and in reply to the corresponding thread this >> time! >> > > The way git handles patches, app

[PATCH] Allow specifying the boot device by its label instead of UUID

2023-09-27 Thread darkpenguin
Here it is, as a single patch, and in reply to the corresponding thread this time! --- util/grub-mkconfig.in | 1 + util/grub-mkconfig_lib.in | 14 +++--- util/grub.d/10_linux.in | 3 +++ 3 files changed, 15 insertions(+), 3 deletions(-) diff --git a/util/grub-mkconfig.in b/util

Re: [PATCH 1/2] Allow specifying the boot device by its label instead of UUID

2023-09-27 Thread darkpenguin
e sending? On 27/09/23 19:50, Vladimir 'phcoder' Serbinenko wrote: > Please don't segment patches like this showing 2 solutions. Just have > the patch for the agreed solution > > Le mer. 27 sept. 2023, 13:14, darkpenguin <mailto:darkpeng...@posteo.de>> a

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

2023-09-27 Thread darkpenguin
till 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 wrot

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

2023-09-27 Thread 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). dark

[PATCH 1/2] Allow specifying the boot device by its label instead of UUID

2023-09-27 Thread darkpenguin
--- util/grub-mkconfig_lib.in | 14 +++--- util/grub.d/10_linux.in | 3 +++ 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/util/grub-mkconfig_lib.in b/util/grub-mkconfig_lib.in index 08953287c..bd43bc01d 100644 --- a/util/grub-mkconfig_lib.in +++ b/util/grub-mkconfig_li

[PATCH 2/2] Use GRUB_ENABLE_LINUX_LABEL=true instead of GRUB_DISABLE_LINUX_UUID=LABEL

2023-09-27 Thread darkpenguin
--- util/grub-mkconfig.in | 1 + util/grub-mkconfig_lib.in | 2 +- util/grub.d/10_linux.in | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in index 32c480dae..fb5000d3f 100644 --- a/util/grub-mkconfig.in +++ b/util/grub-mkconf

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

2023-09-27 Thread 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 +, darkpenguin wrote: >> Here is an updated patch that uses GRUB_ENABLE_LINUX_LABEL=true instead. >> >> Supp

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

2023-09-26 Thread 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/uti

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

2023-09-26 Thread 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 t

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

2023-09-12 Thread 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 +, darkpenguin wrote: >>>>>> The decision to reuse GRUB_DISABLE_LINUX_UUID was because

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

2023-09-12 Thread 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 i

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

2023-09-12 Thread 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" >>>>

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

2023-09-11 Thread darkpenguin
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 + darkpenguin : > >> Specifying the boot device by its label rather than its UUID can be >> pretty useful in various situations (e.g. multiple te

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

2023-09-10 Thread 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 > . ${sys

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

2023-09-10 Thread 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-deve

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

2023-09-10 Thread 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