Head_on_a_Stick wrote:

This is starting to ring a bell with me about an old fdn thread that p.H handled and subsequently opened a bug report about. I'll see if I can find it again...

Ha! found it: http://forums.debian.net/viewtopic.php? … 09&start=0

Bug report: https://bugs.debian.org/cgi-bin/bugrepo … bug=925309

So try copying /boot/efi/EFI/devuan to /boot/efi/EFI/debian

EDIT: or perhaps use

# grub-install --target=x86_64-efi --bootloader-id=debian

Thanks for tracking that down! I have just skimmed it for now, but there is a LOT of UEFI/grub lore in there. I will peruse it tomorrow with fresh eyes - my eyes just don't work very well at the end of the day...

This is starting to ring a bell with me about an old fdn thread that p.H handled and subsequently opened a bug report about. I'll see if I can find it again...

Ha! found it: http://forums.debian.net/viewtopic.php? … 09&start=0

Bug report: https://bugs.debian.org/cgi-bin/bugrepo … bug=925309

So try copying /boot/efi/EFI/devuan to /boot/efi/EFI/debian

EDIT: or perhaps use

# grub-install --target=x86_64-efi --bootloader-id=debian

sgage wrote:

If you think it would help, I will post the output of bootinfoscript

No, let's leave it for now. I think it's aimed more at non-UEFI systems anyway.

sgage wrote:

the problem seems to lie with grubx64.efi...

Indeed. This is starting to ring a bell with me about an old fdn thread that p.H handled and subsequently opened a bug report about. I'll see if I can find it again...

Yes, I took bootinfoscript for a spin, and it did seem to be geared for legacy type systems.

I'd be interested in knowing if others have encountered this. I have a workaround for now, but it's something that ought to get fixed...

Thanks for your help - really appreciate it!

If you think it would help, I will post the output of bootinfoscript

No, let's leave it for now. I think it's aimed more at non-UEFI systems anyway.

Indeed. This is starting to ring a bell with me about an old fdn thread that p.H handled and subsequently opened a bug report about. I'll see if I can find it again...

sgage wrote:

what is telling grub where to get its menu from?

I think the information is embedded in grubx64.efi

It may be time to unleash /usr/sbin/bootinfoscript — the output will be lengthy so perhaps use https://paste.debian.net/

Before I release the Kraken, I mean, unleash bootinfoscript, here's an interesting observation:

I saved an image of my beowulf install with dd, then restored an image of ascii to p6. It had been on p5, so I used grub-install to fix up the EFI/devuan directory. It indeed generated a new grubx64.efi, and did not touch grub.cfg. And it booted using the grub.cfg in ascii, at p6. So, I copied that grubx64.efi to a safe place, restored beowulf. It booted using beowulf's grub.cfg! Since, presumably, the /devuan/grubx64.efi points now to p6.

I ran grub-install, rebooted, and sure enough, it booted using the grub.cfg from p5 (a buster installation). I copied the grubx64.efi that I had saved back over to /devuan, and behold, it booted using grub.cfg from p6.

It seems to me that beowulf's grub-install is not generating a proper grubx64.efi. Does no one else have this issue?

If you think it would help, I will post the output of bootinfoscript, but the problem seems to lie with grubx64.efi...

what is telling grub where to get its menu from?

I think the information is embedded in grubx64.efi

It may be time to unleash /usr/sbin/bootinfoscript — the output will be lengthy so perhaps use https://paste.debian.net/

How very strange

Is the EFI system partition definitely mounted under /boot/efi?

lsblk -f

Try changing /boot/efi/EFI/devuan/grub.cfg to this:

search.fs_uuid 9685be15-8423-402b-b734-f92844748a90 root hd0,gpt6
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

I'm booting via $ESP/EFI/BOOT/bootx64.efi using GRUB but there is no grub.cfg in $ESP/EFI/BOOT/ so I'm not sure if that's actually needed.

Yes, EFI definitely mounted at /boot/efi.

Your grub change didn't change anything. I also tried

configfile (hd0,gpt6)/boot/grub/grub.cfg

that I got from an old script I had kicking around.

I am starting to believe that the grub.cfg in the EFI/(distro) isn't really being used. But then what is telling grub where to get its menu from? Yes, very strange...

Is the EFI system partition definitely mounted under /boot/efi?

lsblk -f

Try changing /boot/efi/EFI/devuan/grub.cfg to this:

search.fs_uuid 9685be15-8423-402b-b734-f92844748a90 root hd0,gpt6
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

I'm booting via $ESP/EFI/BOOT/bootx64.efi using GRUB but there is no grub.cfg in $ESP/EFI/BOOT/ so I'm not sure if that's actually needed.

sgage wrote:

It seems that beowulf's grub does not parse the grub.cfg file in /boot/efi/EFI/devuan

Can we see the content of that file please.

sgage wrote:

reinstalled grub to create a new one

How did you do that, exactly?

And can we please see the output of

# parted --list
efibootmgr -v
/sbin/blkid

The boot-info-script package (/usr/sbin/bootinfoscript) will show exactly what's going on but I can't be bothered trawling through the wall-of-output so give me a few posts to work it out for myself first. Thanks.

The grub.cfg generated in the /devuan directory is:

search.fs_uuid 9685be15-8423-402b-b734-f92844748a90 root 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

It is the correct UUID for the beowulf partition.

I created the /devuan directory in EFI/ the way I have been for a couple of years now:

sudo grub-install --recheck --no-floppy --force

parted --list gives:

Number  Start   End    Size    File system  Name                          Flags
 1      1049kB  274MB  273MB   fat32        EFI System Partition          boot, esp
 2      274MB   290MB  16.8MB               Microsoft reserved partition  msftres
 3      290MB   275GB  275GB   ntfs                                       msftdata
 4      275GB   344GB  68.7GB  ntfs                                       msftdata
 5      344GB   370GB  25.8GB  ext4
 6      370GB   395GB  25.8GB  ext4

efibootmgr -v gives:

# efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0005,0007,0000,0008,0002,000A,0003,0009,0004,0006,000B,000C
Boot0000* Windows Boot Manager	HD(1,GPT,ba36c9c3-856c-4a3a-bf6b-a0aaa7decb7e,0x800,0x82000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0001* devuan	HD(1,GPT,ba36c9c3-856c-4a3a-bf6b-a0aaa7decb7e,0x800,0x82000)/File(\EFI\DEVUAN\SHIMX64.EFI)
Boot0002* USB Floppy/CD	VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0500000001)..BO
Boot0003* USB Hard Drive	VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0200000001)..BO
Boot0004* ATAPI CD-ROM Drive	VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0300000001)..BO
Boot0005* debian	HD(1,GPT,ba36c9c3-856c-4a3a-bf6b-a0aaa7decb7e,0x800,0x82000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0006  UEFI:CD/DVD Drive	BBS(129,,0x0)
Boot0007* ubuntu	HD(1,GPT,ba36c9c3-856c-4a3a-bf6b-a0aaa7decb7e,0x800,0x82000)/File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0008* debian	HD(1,GPT,ba36c9c3-856c-4a3a-bf6b-a0aaa7decb7e,0x800,0x82000)/File(\EFI\DEBIAN\GRUBX64.EFI)
Boot0009* UEFI: SanDisk	PciRoot(0x0)/Pci(0x14,0x0)/USB(5,0)/HD(1,MBR,0x3bf4ec9f,0x390944,0x1f00)..BO
Boot000A* UEFI: SanDisk	PciRoot(0x0)/Pci(0x14,0x0)/USB(5,0)/CDROM(1,0x390944,0x7c00)..BO
Boot000B  UEFI:Removable Device	BBS(130,,0x0)
Boot000C  UEFI:Network Device	BBS(131,,0x0)

Thanks for having a look...

It seems that beowulf's grub does not parse the grub.cfg file in /boot/efi/EFI/devuan

Can we see the content of that file please.

How did you do that, exactly?

And can we please see the output of

# parted --list
efibootmgr -v
/sbin/blkid

The boot-info-script package (/usr/sbin/bootinfoscript) will show exactly what's going on but I can't be bothered trawling through the wall-of-output so give me a few posts to work it out for myself first. Thanks.

I have deleted /boot/efi/EFI/devuan and reinstalled grub to create a new one. I am definitely booting from /devuan - I bring up the BIOS boot menu and select 'devuan'.

Update-grub indeed generates the intended grub.cfg in the beowulf /boot/grub - if I copy it to /boot/grub of the first ext4 partition, grub comes up with the beowulf boot menu, in all of its cinnabar glory.

I am booting off of an nvme SSD drive, for what that's worth. nvme0n1p1 is the EFI partition, followed by some ntfs partitions. The first ext4 partition is p5 (currently buster), and beowulf is on p6.

I do a fair amount of experimentation with distros, and this is the first time I've encountered this. It's been going on for some weeks now.

What gives?