Drivemap in grub2 opensuse and booting systems on second hard drive

Opensuse and Widows 10 installed on first hard disk, grub2 in efi boots both systemas.
I add a second hard drive, install other opensuse, with grub in linux partition and other windows in it.
Grub2 is not capable of booting them. It recognizes them, adds them to the boot menu, but when booting I always have an error.

When booting windows the error is this

and if trying to boot linux, this

As far as I have found it is a problem of the OS thinking that they are in the first drive when booting, and to solve the problem I have found in a lot o places to add this line with drivemap in grub configuration (/etc/grub.d/38_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 "Windows second disk" {
        insmod part_gpt
        insmod fat
        drivemap -s hd0 hd1
        search --no-floppy --fs-uuid --set=root 647D-D3A4
        chainloader /efi/Microsoft/Boot/bootmgfw.efi
}

and for the linux grub installed in part5 of the second disk something like this (/etc/grub.d/39_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 "Second Disk grub" {
    insmod part_gpt
    set root='hd2,gpt5'
    drivemap -s hd1 hd2
    chainloader (hd2)+1
}

I can generate and install grub2 configuration in efi

localhost:~ # grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-6.4.0-150600.23.22-default
Found initrd image: /boot/initrd-6.4.0-150600.23.22-default
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.
Adding boot menu entry for UEFI Firmware Settings ...
done
localhost:~ # shim-install --config-file=/boot/grub2/grub.cfg
copying /usr/share/efi/x86_64/grub.efi to /boot/efi/EFI/opensuse/grub.efi
Installing for x86_64-efi platform.
Installation finished. No error reported.
BootCurrent: 0008
Timeout: 2 seconds
BootOrder: 0006,0005,0004,0000,0001,0002,0003,0007
Boot0000* EFI VMware Virtual NVME Namespace (NSID 1)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot0002* EFI Network
Boot0003* EFI Internal Shell (Unsupported option)
Boot0004* Windows Boot Manager
Boot0005* Windows Boot Manager
Boot0006* opensuse
Boot0007* EFI VMware Virtual NVME Namespace (NSID 2)
BootCurrent: 0008
Timeout: 2 seconds
BootOrder: 0008,0006,0005,0004,0000,0001,0002,0003,0007
Boot0000* EFI VMware Virtual NVME Namespace (NSID 1)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot0002* EFI Network
Boot0003* EFI Internal Shell (Unsupported option)
Boot0004* Windows Boot Manager
Boot0005* Windows Boot Manager
Boot0006* opensuse
Boot0007* EFI VMware Virtual NVME Namespace (NSID 2)
Boot0008* opensuse-secureboot
localhost:~ # 

But when booting I get a error from grub2
image

But this is in gnu-grub 2.12 manual

Is drivemap removed from opensuse grub2?

NOTE: Only available on i386-pc.

ups, I think you are right. I thought of it as “it is not for ARM”

I can’t found the way to boot a OS in a different disk, I can’t believe this was posible before and not now.

Show output of lsblkf -f -o +partuuid and upload grub.cfg to https://paste.opensuse.org/

I use the chainload approach on my multiboot systems. An example chainload entry (for grub2 on another disk) looks like this. No drivemap needed.

/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 "mga9_chainload" {
     insmod part_gpt
     insmod ext2
     search --no-floppy --fs-uuid --set=root 11da21ab-ea1d-460e-8f57-c87d02598489
     configfile /boot/grub2/grub.cfg
}

No, you do not.

That is not chainloading. That is interpreting some other configuration file. Which may work or may not work depending on how different two grubs are. It is for sure valid approach (after all, that is what os-prober effectively does), but do not confuse users and internet search engines using the wrong name for it.

In my installations the openSUSE bootloader (grub2) calls the bootloader from another drive and distribution (also grub2). Isn’t this the definition of chainloading? The configfile is from the second drive and bootloader…

os-prober does not call the complete grub2 from another installation. It directly calls single boot menu entries (e.g.kernel x.y.). Via the example boot menu entry shown above, the complete grub from another system is called with all boot entries from the second system.

GRUB manual says

17.2.1 chainloader

Command: chainloader [–force] file [args…]

Load file as a chain-loader. Like any other file loaded by the filesystem code, it can use the blocklist notation (see Block list syntax) to grab the first sector of the current partition with ‘+1’. On EFI platforms, any arguments after file will be sent to the loaded image.

I have just reinstalled a fresh new opensuse 15.6 to the second drive. I had installed lubunto to check if the grub version of ubuntu behave the same way as the opensuse one … and it did.

localhost:~ # lsblk -f -o +partuuid
NAME FSTYPE FSVER LABEL                            UUID                                 FSAVAIL FSUSE% MOUNTPOINTS PARTUUID
sr0  iso966 Jolie openSUSE-Leap-15.6-NET-x86_64710 2024-06-20-11-42-31-91                                          
nvme0n1
                                                                                                                   
├─nvme0n1p1
│    vfat   FAT32                                  34B9-B301                                                       41b61d26-075b-4ed9-ab03-5bd2914b155c
├─nvme0n1p2
│                                                                                                                  f5d3fddd-26c8-49d2-9338-c358609f77e7
├─nvme0n1p3
│    ntfs                                          2682BA5882BA2C65                                                7212e048-2692-4b2f-b231-0cc2fe0dabe4
├─nvme0n1p4
│    ntfs                                          5A4A2B834A2B5B51                                                a9d09a52-ce28-4466-b8fd-9afc1eea85b1
├─nvme0n1p5
│    btrfs                                         837be9a5-1eef-4ee6-890a-97ea192b2208                            77df2e89-8c30-4d76-bb13-78176b5b03e8
└─nvme0n1p6
     swap   1                                      a9f5c28e-5033-4b59-aa7c-721d74de5580                            160dc668-4dc9-4714-a04c-47a82d253644
nvme0n2
                                                                                                                   
├─nvme0n2p1
│    vfat   FAT32                                  647D-D3A4                              21.8M    77% /boot/efi   3543c403-b9b9-4c23-b0cb-40aa8c05af15
├─nvme0n2p2
│                                                                                                                  50283e45-39aa-4aea-8b15-9f2556fea88c
├─nvme0n2p3
│    ntfs                                          927C7F117C7EEF7B                                                60af0464-ed38-467f-b289-cb622554f26e
├─nvme0n2p4
│    ntfs                                          40CA8C3BCA8C2EEA                                                9715f50c-c03d-4881-8ddc-610fe2df06a7
├─nvme0n2p5
│    btrfs                                         072df7d3-097c-4d6b-91c7-76b9abcd36ae  941.2G     1% /var        c489f8f3-eabf-4585-9dea-373db79bcb95
│                                                                                                      /root       
│                                                                                                      /boot/grub2/x86_64-efi 
│                                                                                                      /tmp        
│                                                                                                      /usr/local  
│                                                                                                      /boot/grub2/i386-pc 
│                                                                                                      /srv        
│                                                                                                      /opt        
│                                                                                                      /home       
│                                                                                                      /.snapshots 
│                                                                                                      /           
└─nvme0n2p6
     swap   1                                      29105f78-efb6-46aa-a447-9a30fd4b775a                [SWAP]      65649910-4729-40e8-9858-ec1c2bb58a10
localhost:~ # 

This opensuse is installed in nvme0n2p5

I’m using a virtual machine with two NVME disks to test this (I want to do this in a real machine, but I’m just testing now).

Is the configuration of this opensuse installed on second disk that has been installed in efi. The grub menu is this

I can boot OK the first entry which is the opensuse in nvme0n2p5 and the 6th entry (windows installed in nvme0n2p1).
Booting the Opensuse installed on the first disk on nvme0n1p5 returns an error

Screenshot_20240929_150503

but then boots well.

Booting the windows of the first disk (installed in nvme0n1p1) fails with this error

this is grub.cfg.

@fperal, I use a KISS approach, only one bootloader installed to incorporate custom.cfg, no matter how many GNU/Linux installations or storage units in the machine. In /etc/grub.d/ on the UEFI installation that includes Grub, I copy 41_custom to 07_custom, and empty and immute 41_ custom, so that entries in custom.cfg are shown ahead of those that were automatically generated. Key to my method is using precisely vmlinuz and initrd, no versioning, in custom.cfg, to minimize required maintenance when kernels are added or removed. Actual maintenance required is then limited to when a distro is added, removed, or relocated, plus, creating vmlinuz and initrd symlinks for installations on which none are auto-generated.

We have a desktop machine that has two [Samsung] NVME drives. The GRUB on each drive has an entry to boot its native (local) Leap, and can also boot the Leap installed on the other NVME drive.

The idea is if one of the Leap installs has a catastrophic failure (the NVME or the OS), we can instantly boot to the other NVME and do work. (and take my time to fix whatever the issue is).

Think of it as redundancy.

We didn’t have to do any “drive map” stuff. We simply installed Leap to nvme1 , then installed Leap to nvme2, which detected the Leap on nvme1 … in a later boot of nvme1, it detected the Leap on nvme2.

(Sidenote: we don’t duel boot with Windows (it’s not worth the hassle) - we have a laptop that is dedicated only for Win10 for legacy reasons).

Mi system is now booting both linux from the grub installed in the second drive, altough when booting the linux in the first drive it reports an error … and then boots ok

The error is very funny

error: ../../grub-core/commands/search.c:316:no such device:
837be9a5-1eef-4ee6-890a-97ea192b2208

Press any key to continue...

The funny thing is that

menuentry 'openSUSE Leap 15.6 (on /dev/nvme0n1p5)' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-837be9a5-1eef-4ee6-890a-97ea192b2208' {
        search --no-floppy --fs-uuid --set=root 837be9a5-1eef-4ee6-890a-97ea192b2208
        linux /boot/vmlinuz-6.4.0-150600.23.22-default root=UUID=837be9a5-1eef-4ee6-890a-97ea192b2208 ${extra_cmdline} splash=silent preempt=full mitigations=auto quiet security=apparmor

is the root partition of the linux in the first disk

localhost:~ # ls -lh /dev/disk/by-uuid |grep 837be9a5-1eef-4ee6-890a-97ea192b2208
lrwxrwxrwx 1 root root 15 Sep 29 18:49 837be9a5-1eef-4ee6-890a-97ea192b2208 -> ../../nvme0n1p5
localhost:~ # 

it is there and it boots


Anyway my problem still is booting both windows


I have read it but I can’t see if it has something to do with booting both windows installations in both disks

Windows isn’t there because I don’t have it on any UEFI PC here. Windows chainloading would be just another entry in custom.cfg, working just like when os-prober is used. With my old PCs, I don’t have licenses except for two 10s, which are chainloaded from Grub Legacy, and booted only maybe twice or less per year.

I have tried this.

#!/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 "First disk" {
     insmod part_gpt
     insmod ext2
     search --no-floppy --fs-uuid --set=root 837be9a5-1eef-4ee6-890a-97ea192b2208
     configfile /boot/grub2/grub.cfg
}

where 837be9a5-1eef-4ee6-890a-97ea192b2208 is the uuid of the opensuse partition in first disk

localhost:/etc/grub.d # grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-6.4.0-150600.23.22-default
Found initrd image: /boot/initrd-6.4.0-150600.23.22-default
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
3870.838399 | DM multipath kernel driver not loaded
Found Windows Boot Manager on /dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi
Found openSUSE Leap 15.6 on /dev/nvme0n1p5
Found Windows Boot Manager on /dev/nvme0n2p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done
localhost:/etc/grub.d # shim-install --config-file=/boot/grub2/grub.cfg
copying /usr/share/efi/x86_64/grub.efi to /boot/efi/EFI/opensuse/grub.efi
Installing for x86_64-efi platform.
Installation finished. No error reported.
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0002,0001,0004,0005,0006,0007,0008
Boot0001* Windows Boot Manager
Boot0002* Windows Boot Manager
Boot0004* EFI VMware Virtual NVME Namespace (NSID 1)
Boot0005* EFI VMware Virtual NVME Namespace (NSID 2)
Boot0006* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot0007* EFI Network
Boot0008* EFI Internal Shell (Unsupported option)
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0002,0001,0004,0005,0006,0007,0008
Boot0001* Windows Boot Manager
Boot0002* Windows Boot Manager
Boot0004* EFI VMware Virtual NVME Namespace (NSID 1)
Boot0005* EFI VMware Virtual NVME Namespace (NSID 2)
Boot0006* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot0007* EFI Network
Boot0008* EFI Internal Shell (Unsupported option)
Boot0000* opensuse-secureboot

When I boot in the grub menu I have a entry “First disk”, if I select it I have a little flash as if trying to boot something and then the same grub menu appears again

The --fs-uuid needs to be from the second system/drive if you want to call grub from the second system/drive.

The grub I’m installing and configuring is the one in the second drive, and from here I want to call grub on the first drive, so I thought I should use de uuid of the linux in the first drive to call it.
Anyway, I have tried with both uuids and it does not work.
And I have boot with the firs disk linux, configure grub also whit this same configuration on 40_custom

menuentry "Second disk boot" {
     insmod part_gpt
     insmod ext2
     search --no-floppy --fs-uuid --set=root 072df7d3-097c-4d6b-91c7-76b9abcd36ae
     configfile /boot/grub2/grub.cfg
}

and try with both uuids (root partition of windows in first and second disks) and the result is the same, the grub menu resets again but do not show the other partiton grub menu