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
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\
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>> 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
> .
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
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
20 matches
Mail list logo
