So far, good, but when booting the Void entry is absent. https://easthope.ca/GrubMenu.jpg
Ideas?
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?
So you've got a stable/testing/unstable system on hd1?
And a 14-month old bullseye system on hd0, which is currently running?
The system has booted into a bookworm Grub (deb12u1).
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
Instead of 40_custom, I use 41_custom, but copied to 07_custom.
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
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.
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.
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.
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.
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.
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.
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.
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?
You took out the tail!
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.
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
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.
grep uent customAB250-51.cfgmenuentry "memtest86 8.3 EFI" {
grep uent customAB250-51.cfg | wc30 221 1339
wc customAB250-51.cfg199 937 10599 customAB250-51.cfg
ls -gGh customAB250-51.cfg… 11K Oct 23 17:47 customAB250-51.cfg
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:
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.
Tim & all,
From: Tim Woodall <debianuser@woodall.me.uk>
Date: Fri, 25 Oct 2024 22:35:50 +0100 (BST)
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.
That's it! The working system is in (hd0,gpt1) and update-grub2 was
updating (hd0,gpt1)/boot/grub/grub.cfg. Grub2 was displaying the menu according to (hd0,gpt2)/boot/grub/grub.cfg which hadn't changed since
an earlier installation.
Therefore booted into (hd0,gpt1), as usual, and execute "grub-install /dev/sda". The fresh grub refers to (hd0,gpt1)/boot/grub/grub.cfg
which has the stanza from (hd0,gpt1)/etc/grub.d/40_custom as intended.
After that, a further problem. The grub ls command didn't show the
USB attached drive containing the Void Linux system. A Web search
found mention of grub command nativedisk which I added.
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 "Void linux"{
insmod part_gpt
insmod ext2
echo 'Grub is running nativedisk to allow access to a USB store.'
nativedisk
echo 'These disks are accessible.'
ls
echo 'Setting root part.'
set root='(usb2,gpt6)'
echo 'Booting Linux.'
linux /boot/vmlinuz-6.6.56_2 root=UUID=e5c7eb47-8d4c-49da-9038-09c27e8e8990 ro
echo 'Loading ramdisk.'
initrd /boot/initramfs-6.6.56_2.img
}
The USB attached drive was then reported by grub2 ls. Then another
problem. Appears the drive doesn't respond quickly enough for the
linux command to succeed. Grub2 shows this.
...
Booting Linux.
error: error communication with USB Mass Storage device.
Loading ramdisk.
error: you need to load the kernel first.
Press any key to continue...
A bug in grub2 nativedisk? The USB 2.0 adapter is too slow? Replace
with a USB 3 adapter?
This setup is needed only to configure the USB connected system. When working, the drive will be installed in another machine. Currently
speed isn't required. Any ideas for a software solution?
That earlier installation is presumably the bookworm that
wrote (hd0,gpt2)/boot/grub/grub.cfg with the Grub deb12u1,
which I pointed out in my first post, but wasn't confirmed
by your follow-up.
I don't know anything about nativedisk or the distinctions between
various types of driver.
OTO you could just let os-prober run when you build Grub and let it
do the job for you. Is there any reason why you don't want to run
os-prober? Sorry, I'm repeating myself.
type
set -x
before you run os-prober and
set +x
afterwards, and track what it does.
Well, it could be because Void apparently isn't a glibc OS.
You could check /usr/lib/os-probes/mounted/90linux-distro
to see whether the first test would succeed. Or a lazy way:
type
set -x
before you run os-prober and
set +x
afterwards, and track what it does. You'd probably want to
capture the output as it could be voluminous; it looks for
linux systems just about last.
Well, it's presumably not Grub, as you say you can boot Void
from your handcrafted menuentry once you've booted into the
correct grub.cfg.
BTW I forgot to mention, your Grub ls command, which you reported
on earlier, will fail to see the Void OS because there's no
insmod part_gpt command in the grub.cfg until you press Return
on the Void menuentry. So that's ok for booting the Void entry,
but up until that moment, Grub can't read GPT partition tables
without the part_gpt. So type an insmod part_gpt command first,
if you need to type ls.
Rather than spend more time investigating, will put the HDD in the
target machine and work there.
BTW I assume your second disk, being GPT, has a BIOS Boot partition?
Or is this target machine going to boot with UEFI, in which case
you need an EFI partition.
I think moving disks between differently
booting machines can be "fun"; it's why my own disks typically have
both a BIOS Boot partition and an EFI partition. The former is only
3MB and ends at sector 8191; the latter can be borrowed for swap
in MBR machines.
On Mon 28 Oct 2024 at 07:08:12 (-0400), Greg Wooledge wrote:
On Sun, Oct 27, 2024 at 22:42:15 -0500, David Wright wrote:
type
set -x
before you run os-prober and
set +x
afterwards, and track what it does.
os-prober is a script, so that won't work as written. You'd either
need to modify os-prober (change the second line from "set -e" to
"set -ex" for example) and then run it; or do something like:
script
set -x
source /usr/bin/os-prober
exit
(That assumes your interactive shell is bash.)
I see what you mean. I guess one could make the shell explicit
and then set x with:
script
bash -x /usr/bin/os-prober
exit
(I can't remember where I saw that construction.)
Rather than spend more time investigating, will put the HDD in the
target machine and work there. Remove some of the complications.
From: peter@easthope.ca
Date: 27 Oct 2024 11:26:12 -0700
Rather than spend more time investigating, will put the HDD in the
target machine and work there. Remove some of the complications.
Happened to connect a USB hub before dealing with the Void drive.
Noticed the USB socket where the Void drive was connected had a black
plastic contact carrier and another socket had a blue carrier. Blue is
USB 3. Black isn't? So plugged the USB adapter with the Void drive
into the blue socket. Voila; Grub was able to boot the Void system
reliably. Spent the better part of a day investigating when a USB plug
just needed moving. =8~/
In case anyone is interested, these topics remain.
* Why does the ThinkCentre have differing USB sockets?
* With the adapter labeled USB 2.0, why is plugging in USB 3 necessary
to boot the external system?
* The Grub2 manual could explain more about USB and the nativedisk
command. In fact, the manual needs work in many places.
From: peter@easthope.ca
Date: 27 Oct 2024 11:26:12 -0700
Rather than spend more time investigating, will put the HDD in the
target machine and work there. Remove some of the complications.
Happened to connect a USB hub before dealing with the Void drive.
Noticed the USB socket where the Void drive was connected had a black plastic contact carrier and another socket had a blue carrier. Blue is
USB 3. Black isn't? So plugged the USB adapter with the Void drive
into the blue socket. Voila; Grub was able to boot the Void system reliably. Spent the better part of a day investigating when a USB plug
just needed moving. =8~/
In case anyone is interested, these topics remain.
* Why does the ThinkCentre have differing USB sockets?
* With the adapter labeled USB 2.0, why is plugging in USB 3 necessary
to boot the external system?
So you need to boot into your bullseye system, and run
# grub-install /dev/sdX
where X is probably a, your first disk.
I'm not sure why you want to avoid running os-prober:
* With the adapter labeled USB 2.0, why is plugging in USB 3 necessary
to boot the external system?
... is the hub separate?
Maintainers may need feedback about what and where [grub2 doc] needs attention.
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 01:11:59 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,577 |
