Le mer. 27 sept. 2023, 17:43, darkpenguin 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 --n
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"
Le mer. 27 sept. 2023, 08:52, darkpenguin 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 tri
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.
>>
>> Supporting whitespace or other sym
On Wed, Sep 27, 2023 at 06:51:38AM +, 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
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
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
Le lun. 11 sept. 2023, 13:16, darkpenguin 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 re
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:
>> 1) This is more of an addition o
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 o
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:
1) This is more of an addition on top of UUID rather than "disabling"
it, it still uses UUID inte
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 specifi
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:
1) This is more of an addition on top of UUID rather than "disabling"
it, it still uses UUID internally, and it falls back
On Mon, Sep 11, 2023 at 06:48:58 +, 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)
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 unders
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 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 mount
>> 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
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
Unlike UUID, label may contain spaces. AFAICT your code fails with spaces
Le dim. 10 sept. 2023, 11:31, darkpenguin 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
On Sun, Sep 10, 2023 at 09:30:24 +, 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 f
20 matches
Mail list logo
