Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #274015 > unrolled thread

Grub menu entry for a system on a second drive.

Back to article view | Back to linux.debian.user

Contents

  Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-24 22:50 +0200
    Re: Grub menu entry for a system on a second drive. Felix Miata <mrmazda@earthlink.net> - 2024-10-24 23:00 +0200
    Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 05:30 +0200
      Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-25 17:50 +0200
        Re: Grub menu entry for a system on a second drive. Joe <joe@jretrading.com> - 2024-10-25 18:10 +0200
          Re: Grub menu entry for a system on a second drive. Max Nikulin <manikulin@gmail.com> - 2024-10-25 18:40 +0200
          Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-25 21:00 +0200
            Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 21:20 +0200
              Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-25 22:50 +0200
                Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-11-10 02:30 +0100
                  Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-11-12 05:00 +0100
        Re: Grub menu entry for a system on a second drive. Greg Wooledge <greg@wooledge.org> - 2024-10-25 18:50 +0200
        Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 20:20 +0200
    Re (2): Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-25 18:40 +0200
      Re: Grub menu entry for a system on a second drive. Felix Miata <mrmazda@stanis.net> - 2024-10-25 20:00 +0200
        Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 21:10 +0200
          Re: Grub menu entry for a system on a second drive. Felix Miata <mrmazda@stanis.net> - 2024-10-25 22:50 +0200
          Re: Grub menu entry for a system on a second drive. Felix Miata <mrmazda@stanis.net> - 2024-10-26 06:00 +0200
            Re: Grub menu entry for a system on a second drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-26 07:10 +0200
      Re: Re (2): Grub menu entry for a system on a second drive. Tim Woodall <debianuser@woodall.me.uk> - 2024-10-25 23:40 +0200
        [solved, partly] Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-27 05:20 +0100
          Re: [solved, partly] Re: Grub menu entry for a system on a second  drive. David Wright <deblis@lionunicorn.co.uk> - 2024-10-27 16:00 +0100
            Re: [solved, partly] Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-27 19:50 +0100
              Re: [solved, partly] Re: Grub menu entry for a system on a second  drive. Greg Wooledge <greg@wooledge.org> - 2024-10-28 12:10 +0100
                Re: [solved, partly] Re: Grub menu entry for a system on a second  drive. Greg Wooledge <greg@wooledge.org> - 2024-11-01 12:10 +0100
              Re: [solved, partly] Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-10-28 17:30 +0100
              Re: [solved, more] Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-11-02 16:10 +0100
                Re: [solved, more] Re: Grub menu entry for a system on a second  drive. David Wright <deblis@lionunicorn.co.uk> - 2024-11-04 05:50 +0100
                  Re: [solved, more] Re: Grub menu entry for a system on a second drive. peter@easthope.ca - 2024-11-10 04:00 +0100
                Re: [solved, more] Re: Grub menu entry for a system on a second  drive. Dan Purgert <dan@djph.net> - 2024-11-04 13:50 +0100
            Re: [solved, partly] Re: Grub menu entry for a system on a second  drive. Max Nikulin <manikulin@gmail.com> - 2024-11-03 03:50 +0100

Page 1 of 2  [1] 2  Next page →

#274015 — Grub menu entry for a system on a second drive.

Hi, 

root@imager:~# grep PROBER /etc/default/grub
GRUB_DISABLE_OS_PROBER=true

Also,

root@imager:~# cat /etc/grub.d/40*
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
#
menuentry "Void linux"{
        insmod part_gpt
        insmod ext2
        set root=(hd1,gpt6) reboot=bios
        linux /boot/vmlinuz-6.6.56_2 root=UUID=e5c7eb47-8d4c-49da-9038-09c27e8e8
990 ro single
        echo    'Loading ramdisk.'
        initrd  /boot/initramfs-6.6.56_2.img
}

Then,

root@imager:~# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-24-amd64
Found initrd image: /boot/initrd.img-5.10.0-24-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done

/boot/grub/grub.cfg has the menu entry.

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
#
menuentry "Void linux"{
        insmod part_gpt
        insmod ext2
        set root=(hd1,gpt6) reboot=bios
        linux /boot/vmlinuz-6.6.56_2 root=UUID=e5c7eb47-8d4c-49da-9038-09c27e8e8
990 ro single
        echo    'Loading ramdisk.'
        initrd  /boot/initramfs-6.6.56_2.img
}
### END /etc/grub.d/40_custom ###

So far, good, but when booting the Void entry is absent.
https://easthope.ca/GrubMenu.jpg

Ideas?

Thanks,         ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [next] | [standalone]

#274016

peter@easthope.ca composed on 2024-10-24 12:52 (UTC-0700):

> So far, good, but when booting the Void entry is absent.
> https://easthope.ca/GrubMenu.jpg

> Ideas?

Why I don't know, but:

Instead of 40_custom, I use 41_custom, but copied to 07_custom. Grub.cfg then
reads custom entries from /boot/grub/custom.cfg at runtime, placing them ahead of
its own entries. Any changes you make to /boot/grub/custom.cfg are read without
any additional fuss next boot and beyond, until you change it again.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#274025

On Thu 24 Oct 2024 at 12:52:59 (-0700), peter@easthope.ca wrote:
> root@imager:~# grep PROBER /etc/default/grub
> GRUB_DISABLE_OS_PROBER=true
> 
> Also,
> 
> root@imager:~# cat /etc/grub.d/40*
> #!/bin/sh
> exec tail -n +3 $0
> # This file provides an easy way to add custom menu entries.  Simply type the
> # menu entries you want to add after this comment.  Be careful not to change
> # the 'exec tail' line above.
> #
> menuentry "Void linux"{
>         insmod part_gpt
>         insmod ext2
>         set root=(hd1,gpt6) reboot=bios
>         linux /boot/vmlinuz-6.6.56_2 root=UUID=e5c7eb47-8d4c-49da-9038-09c27e8e8
> 990 ro single
>         echo    'Loading ramdisk.'
>         initrd  /boot/initramfs-6.6.56_2.img
> }

So you've got a stable/testing/unstable system on hd1?

> Then,
> 
> root@imager:~# update-grub
> Generating grub configuration file ...
> Found linux image: /boot/vmlinuz-5.10.0-24-amd64
> Found initrd image: /boot/initrd.img-5.10.0-24-amd64

And a 14-month old bullseye system on hd0, which is currently running?

> Warning: os-prober will not be executed to detect other bootable partitions.
> Systems on them will not be added to the GRUB boot configuration.
> Check GRUB_DISABLE_OS_PROBER documentation entry.
> done
> 
> /boot/grub/grub.cfg has the menu entry.
> 
> ### BEGIN /etc/grub.d/40_custom ###
> # This file provides an easy way to add custom menu entries.  Simply type the
> # menu entries you want to add after this comment.  Be careful not to change
> # the 'exec tail' line above.
> #
> menuentry "Void linux"{
>         insmod part_gpt
>         insmod ext2
>         set root=(hd1,gpt6) reboot=bios
>         linux /boot/vmlinuz-6.6.56_2 root=UUID=e5c7eb47-8d4c-49da-9038-09c27e8e8
> 990 ro single
>         echo    'Loading ramdisk.'
>         initrd  /boot/initramfs-6.6.56_2.img
> }
> ### END /etc/grub.d/40_custom ###
> 
> So far, good, but when booting the Void entry is absent.
> https://easthope.ca/GrubMenu.jpg
> 
> Ideas?

The system has booted into a bookworm Grub (deb12u1). It would appear
that your MBR/UEFI has booted into a grub.cfg that isn't the one
created above, ie on the other disk. After all, that Grub menu looks
as if it was created on a system that (a) isn't bullseye, and (b) ran
os-prober to produce its bullseye lines 3 and 4.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#274041

    From: David Wright <deblis@lionunicorn.co.uk>
    Date: Thu, 24 Oct 2024 22:22:19 -0500
> So you've got a stable/testing/unstable system on hd1?

hd1 has Void Linux.  They don't use the stable/testing/unstable terminology.

> And a 14-month old bullseye system on hd0, which is currently running?

Yes.
root@imager:~# cat /etc/debian*
11.11

> The system has booted into a bookworm Grub (deb12u1). 

I don't understand.  To my understanding, booted into Debian 11 on hd0.

A new-to-me detail is hd0 having FAT and hd1 having GPT.
According to this, OK for Grub2.
https://www.gnu.org/software/grub/manual/grub/grub.html#BIOS-installation

Thanks,               ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]

#274043

On 25 Oct 2024 08:26:21 -0700
peter@easthope.ca wrote:

>     From: David Wright <deblis@lionunicorn.co.uk>
>     Date: Thu, 24 Oct 2024 22:22:19 -0500
> > So you've got a stable/testing/unstable system on hd1?  
> 
> hd1 has Void Linux.  They don't use the stable/testing/unstable
> terminology.
> 
> > And a 14-month old bullseye system on hd0, which is currently
> > running?  
> 
> Yes.
> root@imager:~# cat /etc/debian*
> 11.11
> 
> > The system has booted into a bookworm Grub (deb12u1).   
> 
> I don't understand.  To my understanding, booted into Debian 11 on
> hd0.
> 
> A new-to-me detail is hd0 having FAT and hd1 having GPT.
> According to this, OK for Grub2.
> https://www.gnu.org/software/grub/manual/grub/grub.html#BIOS-installation

Modern drives use GPT partitioning, and modern computers generally have
UEFI firmware rather than BIOS. The EFI partition *must* be one of the
FAT family, for any OS using UEFI.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#274044

On 25/10/2024 23:06, Joe wrote:
> On 25 Oct 2024 08:26:21 -0700 peter@easthope.ca wrote:
>>
>> A new-to-me detail is hd0 having FAT and hd1 having GPT.
>> According to this, OK for Grub2.
[...]
> Modern drives use GPT partitioning, and modern computers generally have
> UEFI firmware rather than BIOS. The EFI partition *must* be one of the
> FAT family, for any OS using UEFI.

I suspect some confusion. Either MBR (not FAT) vs. GPT partition table 
or FAT filesystem on specific partition like (hd0,gpt1) or (hd0,msdos1), 
not on whole (hd0) or (hd1) drive.

A plugged USB stick may shift drive numbers, so hd1 may accidentally 
become hd2. Grub installer may add a command to rely on filesystem UUID, 
not on drive numbering:

search.fs_uuid 12345678-90ab-cdef-1234-567890abcdef root

or a variant with a hint where this partition is expected

search.fs_uuid 12345678-90ab-cdef-1234-567890abcdef root hd1,gpt3

to set the "root" variable.

[toc] | [prev] | [next] | [standalone]

#274050

Joe & all,
    
    From: Joe <joe@jretrading.com>
    Date: Fri, 25 Oct 2024 17:06:21 +0100
> Modern drives use GPT partitioning, and modern computers generally have
> UEFI firmware rather than BIOS. 

The machine here is ThinkCentre 1S3237C13MJTVBGW.  Older than 
machines commonplace now.

It has UEFI but I couldn't make it boot the machine. Noticed comments 
on the Web mentioning bugs in some early EFI implementations.  So I 
kept GPT on the drive and reverted to BIOS.

> The EFI partition *must* be one of the FAT family, for any OS using 
> UEFI.

Understood.  Have that.  Not using it.  Booting with BIOS rather 
than EFI.

Incidentally, the Void Linux system on (hd1,gpt6) boots when directed 
from the BIOS.  The problem is to boot it through Grub on (hd0) 
without switching in the BIOS.

If my /etc/grub.d/40_custom is problematic for update-grub2 an error 
message from update-grub2 or grub-mkconfig could help.  Don't see a 
way to get a progress or error report without recompiling.

The /boot/grub/grub.cfg created by update-grub2 is at 
https://easthope.ca/grub.cfg .  My 40_custom stanza is there but not 
in the boot menu.  If someone can spot an error, good, thanks.

Thanks,                        ... P.


-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]

#274056

On Fri 25 Oct 2024 at 11:33:37 (-0700), peter@easthope.ca wrote:
> The /boot/grub/grub.cfg created by update-grub2 is at 
> https://easthope.ca/grub.cfg .  My 40_custom stanza is there but not 
> in the boot menu.  If someone can spot an error, good, thanks.

You took out the tail!

It should look like:

  $ cat /etc/grub.d/40_custom 
  #!/bin/sh
  exec tail -n +3 $0
  # This file provides an easy way to add custom menu entries.  Simply type the
  # menu entries you want to add after this comment.  Be careful not to change
  # the 'exec tail' line above.
  menuentry "Install Debian via HTTP" {
      search --no-floppy --label --set=root noah03
      linux   /boot/vmlinuz priority=low
      initrd  /boot/initrd.gz
  }
  $ 

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#274058

    From: David Wright <deblis@lionunicorn.co.uk>
    Date: Fri, 25 Oct 2024 14:13:50 -0500
> You took out the tail!

Appears we're at crossed purposes. You catted /etc/grub.d/40_custom.  
I posted /boot/grub/grub.cfg.

My 40_custom has the "exec tail" line as you posted and produces a 
stanza in /boot/grub/grub.cfg appearing OK.

Thx,                  ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]

#274432

    From: David Wright <deblis@lionunicorn.co.uk>
    Date: Fri, 25 Oct 2024 21:12:21 -0500
> So you need to boot into your bullseye system, and run
>   # grub-install /dev/sdX
> where X is probably a, your first disk.

Done.  Resulting menu here.
https://easthope.ca/GrubMenu1.jpg

For reference, this was the earlier menu. 
https://easthope.ca/GrubMenu.jpg

> I'm not sure why you want to avoid running os-prober: 

If I avoid dopey blunders, 40_custom can achieve the same result 
while requiring clearer thought.  Also there's security.
https://lists.ubuntu.com/archives/ubuntu-devel/2021-December/041769.html

Thanks!                       ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]

#274493

On Sat 09 Nov 2024 at 17:03:53 (-0700), peter@easthope.ca wrote:
>     From: David Wright <deblis@lionunicorn.co.uk>
>     Date: Fri, 25 Oct 2024 21:12:21 -0500
> > So you need to boot into your bullseye system, and run
> >   # grub-install /dev/sdX
> > where X is probably a, your first disk.
> 
> Done.  Resulting menu here.
> https://easthope.ca/GrubMenu1.jpg
> 
> For reference, this was the earlier menu. 
> https://easthope.ca/GrubMenu.jpg

I've always felt it a failing that Grub's mkconfig strips the
suite and root disk information from the principal menuentries.

> > I'm not sure why you want to avoid running os-prober: 
> 
> If I avoid dopey blunders, 40_custom can achieve the same result 
> while requiring clearer thought.  Also there's security.
> https://lists.ubuntu.com/archives/ubuntu-devel/2021-December/041769.html

Fair enough: I don't know the environment of your machines.
For single user machines like mine, it's difficult to see
how os-prober's vulnerabilities would be exploited.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#274046

On Fri, Oct 25, 2024 at 08:26:21 -0700, peter@easthope.ca wrote:
> A new-to-me detail is hd0 having FAT and hd1 having GPT.
> According to this, OK for Grub2.
> https://www.gnu.org/software/grub/manual/grub/grub.html#BIOS-installation

FAT is a type of file system.  The disk partitioning table type that
you're thinking of is variously called "MSDOS" or "MBR", depending
on which tool you use.

[toc] | [prev] | [next] | [standalone]

#274048

On Fri 25 Oct 2024 at 08:26:21 (-0700), peter@easthope.ca wrote:
>     From: David Wright <deblis@lionunicorn.co.uk>
>     Date: Thu, 24 Oct 2024 22:22:19 -0500
> > So you've got a stable/testing/unstable system on hd1?
> 
> hd1 has Void Linux.  They don't use the stable/testing/unstable terminology.

I'm looking at your system through a tiny peephole!
All I've done is to conjure up a scenario that doesn't
AFAICT contradict anything you've written.

> > And a 14-month old bullseye system on hd0, which is currently running?
> 
> Yes.
> root@imager:~# cat /etc/debian*
> 11.11
> 
> > The system has booted into a bookworm Grub (deb12u1). 
> 
> I don't understand.  

Booting is a multistage process. By means of an MBR or EFI, you
reached the Grub menu, which you photographed. At the top, it says:
  GNU GRUB  version 2.06-13+deb12u1
which is the bang up-to-date bookworm version of Grub.
Having photographed this menu, and commented on its
lack of a particular menu, all I see is evidence of bookworm.

Now, if you press Return while in the state the photo recorded,
then you'll end up in a bullseye system. Hence:

> To my understanding, booted into Debian 11 on hd0.

But I have no /evidence/ that there's any connection between the
grub.cfg you were editing and the grub.cfg that displayed that
screen. I would need to know what else was on the machine and its
disks to do anything more than guess from shaky assumptions.

> A new-to-me detail is hd0 having FAT and hd1 having GPT.

I think you mean MBR on hd0. Is hd0 the legacy disk and
hd1 a new one? Would it be correct to assume that the machine
booted from the MBR, and still does? Can we assume that you
haven't tried to install Grub onto hd1? There's a stack of
unknowns at this end.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#274045 — Re (2): Grub menu entry for a system on a second drive.

    From: Felix Miata <mrmazda@earthlink.net>
    Date: Thu, 24 Oct 2024 16:55:37 -0400
> Instead of 40_custom, I use 41_custom, but copied to 07_custom.

You have two copies of the custom configuration.  One in 
/etc/grub.d/07_custom and one in /etc/grub.d/41_custom.  Correct?

Are both entries in the menu?  Only the one from 07_custom?

The immediate puzzle here is the custom menu entry in 
/etc/boot/grub.cfg and not displayed in the boot menu.  As if menu 
display stops before the custom section.

Don't want to be stuck with a broken system.  Need to be a careful 
monkeying.

Thanks,                                     ... P.



-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]

#274047

peter composed on 2024-10-25 09:23 (UTC-0700):

> You have two copies of the custom configuration.  One in 
> /etc/grub.d/07_custom and one in /etc/grub.d/41_custom.  Correct?

> Are both entries in the menu?  Only the one from 07_custom?

> The immediate puzzle here is the custom menu entry in 
> /etc/boot/grub.cfg and not displayed in the boot menu.  As if menu 
> display stops before the custom section.

> Don't want to be stuck with a broken system.  Need to be a careful 
> monkeying.

My actual custom stanzas are in /boot/grub2/custom.cfg, because I use only one
bootloader per PC, no matter how many installations it contains, which averages in
excess of 20, and I use whatever version of Grub2 that Tumbleweed provides,
usually the latest available. That shouldn't make any difference in Debian use,
other than the "2" in directory name.

In /etc/grub.d/ I copy 41_custom to 07_custom. Then I empty 41_custom and make it
immutable so that the entries 07_custom refers to are not duplicated by 41_custom
after every time whatever Grub package providing it is updated.

Manual editing of /boot/grub/grub.cfg does not persist. Every kernel addition or
removal causes its regeneration anew based upon the content of /etc/default/grub
and the regeneration script(s), same as running grub-mkconfig.

Details of 40_custom use I'm completely unfamiliar with, as I've never used it,
though I empty and lock it the same it as I do 41_custom.

I have only one set of custom entries per PC, those in /boot/grub2/custom.cfg.
It's such a long list that I normally don't see the automatically generated
entries before I've made a selection from among my own.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#274054

On Fri 25 Oct 2024 at 13:51:06 (-0400), Felix Miata wrote:
> My actual custom stanzas are in /boot/grub2/custom.cfg, because I use only one
> bootloader per PC, no matter how many installations it contains, which averages in
> excess of 20, and I use whatever version of Grub2 that Tumbleweed provides,
> usually the latest available. That shouldn't make any difference in Debian use,
> other than the "2" in directory name.
> 
> In /etc/grub.d/ I copy 41_custom to 07_custom. Then I empty 41_custom and make it
> immutable so that the entries 07_custom refers to are not duplicated by 41_custom
> after every time whatever Grub package providing it is updated.

Do you mean that the previously inserted copies of custom.cfg are
preserved, and a new copy inserted, each time grub-mkconfig runs?
If that's not the case, then does it really matter that you have
the same menuentry contents at positions 07 and 41?

> Details of 40_custom use I'm completely unfamiliar with, as I've never used it,
> though I empty and lock it the same it as I do 41_custom.

It's static, and just gets inserted as is, which you can see from
any grub.cfg created in the normal manner. Mine currently contains:

  #!/bin/sh
  exec tail -n +3 $0
  # This file provides an easy way to add custom menu entries.  Simply type the
  # menu entries you want to add after this comment.  Be careful not to change
  # the 'exec tail' line above.
  menuentry "Install Debian via HTTP" {
      search --no-floppy --label --set=root noah03
      linux   /boot/vmlinuz priority=low
      initrd  /boot/initrd.gz
  }

on a machine that can't reliably boot from a USB stick,
particularly a Debian netinst confection. (The two files come from
http://http.us.debian.org/debian/dists/<codename>/main/install
er-i386/current/images/hd-media/
rather than
https://cdimage.debian.org/cdimage/release/current/amd64/iso-cd/
)

I also use 07_custom on the same machine, avoiding the
filename versioning in the system-generated entries:

  #!/bin/sh
  exec tail -n +3 $0
  # This file provides an easy way to add custom menu entries.  Simply type the
  # menu entries you want to add after this comment.  Be careful not to change
  # the 'exec tail' line above.
  menuentry 'My bullseye' $menuentry_id_option 'custom' {
      load_video
      set gfxpayload=keep
      insmod gzio
      insmod part_gpt
      insmod ext2
      search --no-floppy --set=root --label noah03
      echo    'Load /vmlinuz …'
      linux   /vmlinuz root=LABEL=noah03 ro systemd.show_status=true quiet
      echo    'Load initial ramdisk /initrd.img …'
      initrd  /initrd.img
  }

> Manual editing of /boot/grub/grub.cfg does not persist. Every kernel addition or
> removal causes its regeneration anew based upon the content of /etc/default/grub
> and the regeneration script(s), same as running grub-mkconfig.

FTR, editing the Grub menu itself is, of course, totally ephemeral.
Type whatever you like, boot from it, and the edits are gone for good.

But editing /boot/grub/grub.cfg does persist as long as
that particular grub.cfg is not reconfigured with
grub-mkconfig/update-grub, which is done by kernel upgrades,
and, of course, the very occasional Grub upgrades.

I postprocess my grub.cfg files as a matter of routine, mainly
to convert UUIDs to LABELs, but also to uniquify them, if I may
use that word. In the OP's case, I would do just that: after
grub-mkconfig/update-grub runs, I would edit grub.cfg to add
something, anything, to one or more menuentry labels; say,
  Debian 2024-10-25 A GNU/Linux    so that you can correlate
the menu you later see with the file you earlier wrote.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#274059

David Wright composed on 2024-10-25 14:08 (UTC-0500):

> On Fri 25 Oct 2024 at 13:51:06 (-0400), Felix Miata wrote:

>> My actual custom stanzas are in /boot/grub2/custom.cfg, because I use only one
>> bootloader per PC, no matter how many installations it contains, which averages in
>> excess of 20, and I use whatever version of Grub2 that Tumbleweed provides,
>> usually the latest available. That shouldn't make any difference in Debian use,
>> other than the "2" in directory name.

>> In /etc/grub.d/ I copy 41_custom to 07_custom. Then I empty 41_custom and make it
>> immutable so that the entries 07_custom refers to are not duplicated by 41_custom
>> after every time whatever Grub package providing it is updated.

> Do you mean that the previously inserted copies of custom.cfg are
> preserved, and a new copy inserted, each time grub-mkconfig runs?

I don't understand this "insertion" business, thus neither "preserved". My
grub.cfgs contain zilch that is contained in custom.cfgs.

grub.cfg always contains:
…
### END /etc/grub.d/06_custom ###

### BEGIN /etc/grub.d/07_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/07_custom ###

### BEGIN /etc/grub.d/10_linux ###
…
This code means custom.cfg is read at boot, with result that custom.cfg stanzas
are displayed before those contained within grub.cfg itself.

> If that's not the case, then does it really matter that you have
> the same menuentry contents at positions 07 and 41?

07… stanzas are displayed prior to grub.cfg's own (10…) stanzas. 41… entries are
displayed after. These numbers beginning filenames in /etc/grub.d/ are about the
order of presentation when grub is putting up a menu at boot.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#274062

David Wright composed on 2024-10-25 14:08 (UTC-0500):

> On Fri 25 Oct 2024 at 13:51:06 (-0400), Felix Miata wrote:

>> Manual editing of /boot/grub/grub.cfg does not persist. Every kernel addition or
>> removal causes its regeneration anew based upon the content of /etc/default/grub
>> and the regeneration script(s), same as running grub-mkconfig.

> FTR, editing the Grub menu itself is, of course, totally ephemeral.
> Type whatever you like, boot from it, and the edits are gone for good.

> But editing /boot/grub/grub.cfg does persist as long as

Therein lies the difference between my word collection and yours - as long as. It
persists, but only until some _inevitable_ event occurs, as we both described:

> that particular grub.cfg is not reconfigured with
> grub-mkconfig/update-grub, which is done by kernel upgrades,
> and, of course, the very occasional Grub upgrades.

Just a little editing of my text produces an equivalent result. Change

	does not persist. Every kernel addition or removal…
to
	persists only until kernel addition or removal…

and what I wrote is equivalent to what you wrote.

> I postprocess my grub.cfg files as a matter of routine, mainly
> to convert UUIDs to LABELs, but also to uniquify them, if I may
> use that word.

Such postprocess is pointless here. The bulk of my custom.cfg entries use LABELS.
None use UUIDs. And, grub.cfg entries are ignored, displayed onscreen as available
selections only after scrolling past 20-30 or more custom.cfg entries:

> grep uent customAB250-51.cfg
menuentry "memtest86 8.3 EFI" {
menuentry "openSUSE TW defkernel 5 nolog novid" {
menuentry "openSUSE TW defkernel 3 on P07" {
menuentry "memtest86 7.4 EFI" {
menuentry "openSUSE Slowroll defkernel 3 on P19" {
menuentry "openSUSE 15.6 defkernel 3 on P20" {
menuentry "Debian 13 Testing (Trixie) defkernel 3 on P13" {
menuentry "Fedora 41 defkernel 3 on P23" {
menuentry "openSUSE 15.5 defkernel 3 on P11" {
menuentry "Fedora 39 defkernel 3 on P15" {
menuentry "Tubuntu 24 defkernel 3 on P24" {
menuentry "Mageia 9 defkernel 3" {
menuentry "Fedora 40 defkernel 3 on P18" {
menuentry "Neon User defkernel 3 on P25" {
menuentry "Debian 12 Bookworm defkernel 3 on P10" {
menuentry "Tubuntu 22 defkernel 3 on P12" {
menuentry "openSUSE 15.4 defkernel 3 on P16" {
menuentry "Debian 11 Bullseye defkernel 3 on P14" {
menuentry "openSUSE 15.3 defkernel 3 on P08" {
menuentry "openSUSE 15.1 defkernel 3 on P09" {
menuentry "Tubuntu 20 defkernel 5 on P17" {
menuentry "Tubuntu 18 defkernel 5 on P21" {
menuentry "Custom from ESP partition" {
menuentry "Install Buntu via HTTP" {
menuentry "Install Slackware via HTTP" {
menuentry "Install openSUSE TW via HTTP" {
menuentry "Install Mageia from mirrors.us.kernel.org"{
menuentry "Install openSUSE 15.6 via HTTP" {
menuentry "Install Neon via HTTP" {
menuentry "Install Debian via HTTP" {
> grep uent customAB250-51.cfg | wc
     30     221    1339
> wc customAB250-51.cfg
  199   937 10599 customAB250-51.cfg
> ls -gGh customAB250-51.cfg
… 11K Oct 23 17:47 customAB250-51.cfg
>
So, the auto-generateds are rarely observed, much less selected.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#274063

On Fri 25 Oct 2024 at 23:50:05 (-0400), Felix Miata wrote:
> David Wright composed on 2024-10-25 14:08 (UTC-0500):
> > On Fri 25 Oct 2024 at 13:51:06 (-0400), Felix Miata wrote:
> 
> >> Manual editing of /boot/grub/grub.cfg does not persist. Every kernel addition or
> >> removal causes its regeneration anew based upon the content of /etc/default/grub
> >> and the regeneration script(s), same as running grub-mkconfig.
> 
> > FTR, editing the Grub menu itself is, of course, totally ephemeral.
> > Type whatever you like, boot from it, and the edits are gone for good.
> 
> > But editing /boot/grub/grub.cfg does persist as long as
> 
> Therein lies the difference between my word collection and yours - as long as. It
> persists, but only until some _inevitable_ event occurs, as we both described:
> 
> > that particular grub.cfg is not reconfigured with
> > grub-mkconfig/update-grub, which is done by kernel upgrades,
> > and, of course, the very occasional Grub upgrades.
> 
> Just a little editing of my text produces an equivalent result. Change
> 
> 	does not persist. Every kernel addition or removal…
> to
> 	persists only until kernel addition or removal…
> 
> and what I wrote is equivalent to what you wrote.

I felt "does not persist" was too emphatic. Although kernel upgrades
etc. are kind of inevitable, they are (or should be) active events,
which take place when the sysadmin decides¹, and I felt that your
words made it sound more passively driven by "external" events.

> > I postprocess my grub.cfg files as a matter of routine, mainly
> > to convert UUIDs to LABELs, but also to uniquify them, if I may
> > use that word.
> 
> Such postprocess is pointless here. The bulk of my custom.cfg entries use LABELS.
> None use UUIDs. And, grub.cfg entries are ignored, displayed onscreen as available
> selections only after scrolling past 20-30 or more custom.cfg entries:

Sure, I would expect you to write custom.cfg entries exactly as you
want them to appear. OTOH my postprocessing operates on the entries
generated by Grub's scripts. Many years ago, I looked at the scripts
to see whether I could make them produce LABELs instead of UUIDs, but
it didn't appear to be trivial, so I just generate a little lookup
array from the E:ID_FS_UUID and E:ID_FS_LABEL values in /run/udev/data/b*.

¹ Obviously I'm assuming no unattended upgrades and other such horrors.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#274060 — Re: Re (2): Grub menu entry for a system on a second drive.

On Fri, 25 Oct 2024, peter@easthope.ca wrote:

>    From: Felix Miata <mrmazda@earthlink.net>
>    Date: Thu, 24 Oct 2024 16:55:37 -0400
>> Instead of 40_custom, I use 41_custom, but copied to 07_custom.
>
> You have two copies of the custom configuration.  One in
> /etc/grub.d/07_custom and one in /etc/grub.d/41_custom.  Correct?
>
> Are both entries in the menu?  Only the one from 07_custom?
>
> The immediate puzzle here is the custom menu entry in
> /etc/boot/grub.cfg and not displayed in the boot menu.  As if menu
> display stops before the custom section.
>
> Don't want to be stuck with a broken system.  Need to be a careful
> monkeying.
>
> Thanks,                                     ... P.
>
>
>
>

It's possibly not reading the grub.cfg you think it is reading.  I've
hit this problem before - IIRC grub uses the grub.cfg from the *first*
place it finds one - this can even be a partition (or in my case a LV)
that is not used anywhere on any system.

So the first thing to check is whether there's a grub.cfg on any other
partition.

One thing you can try is changing something innocuous in what you think
is the live stanza, and then checking whether it's visible when you go
to edit the commands in the grub menu - if it's not then that tells you
it's not using that grub.cfg but another one that looks like it.

I have no idea if grub hides things that aren't parseable - that would
be my other guess.

Tim.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web