Os-prober results not being added to grub menu

Ask Fedora
1

I have a dual-boot setup with two ssds, with Fedora 35 on a NVME drive and OpenSUSE Tumbleweed on a SATA drive (sda).

[jeremy@fedora ~]$ lsblk
NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda               8:0    0 465.8G  0 disk 
├─sda1            8:1    0   512M  0 part 
└─sda2            8:2    0 465.3G  0 part 
  ├─system-swap 253:0    0     2G  0 lvm  
  └─system-root 253:1    0 463.3G  0 lvm  
zram0           252:0    0     8G  0 disk [SWAP]
nvme0n1         259:0    0 931.5G  0 disk 
├─nvme0n1p1     259:1    0   600M  0 part /boot/efi
├─nvme0n1p2     259:2    0     1G  0 part /boot
└─nvme0n1p3     259:3    0 929.9G  0 part /home
                                          /

Fedora 35 is my everyday distro. The Tumbleweed install is recent, to check it out and compare to Fedora, etc. In the future I will probably put other distros on this secondary drive.

I can boot to either distro from the UEFI boot menu, but I have been trying for a few days to get Tumbleweed on to the grub menu so I can skip the UEFI boot menu altogether and I’m afraid I am stumped.

efibootmgr lists out both distros, pretty much as they appear in the UEFI boot menu.

[jeremy@fedora ~]$ sudo efibootmgr -v
BootCurrent: 0011
Timeout: 1 seconds
BootOrder: 0011,0010
Boot0010* opensuse      HD(1,GPT,ce98452a-a914-435f-bff7-664a91e927b0,0x800,0x100000)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO
Boot0011* Fedora        HD(1,GPT,3b94015c-1fbe-4fd5-8969-1e9aaa58db0f,0x800,0x12c000)/File(\EFI\FEDORA\SHIM.EFI)..BO

GRUB_DISABLE_OS_PROBER=“false” has been added to /etc/default/grub. I have tried it with and without quotes on the “false”; I get the impression either way should work.

GNU nano 5.8                                                   /etc/default/grub                                                              
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU="false"
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_DISABLE_OS_PROBER="false"

Execute bits are on for 30_os-prober (and all other scripts in /etc/grub.d)

[root@fedora ~]# cd /etc/grub.d
[root@fedora grub.d]# ls -l
total 104
-rwxr-xr-x. 1 root root  9346 Oct  7 15:02 00_header
-rwxr-xr-x. 1 root root   236 Oct  7 15:02 01_users
-rwxr-xr-x. 1 root root   835 Oct  7 15:02 08_fallback_counting
-rwxr-xr-x. 1 root root 18669 Oct  7 15:02 10_linux
-rwxr-xr-x. 1 root root   833 Oct  7 15:02 10_reset_boot_success
-rwxr-xr-x. 1 root root   892 Oct  7 15:02 12_menu_auto_hide
-rwxr-xr-x. 1 root root   410 Oct  7 15:02 14_menu_show_once
-rwxr-xr-x. 1 root root 13613 Oct  7 15:02 20_linux_xen
-rwxr-xr-x. 1 root root  2562 Oct  7 15:02 20_ppc_terminfo
-rwxr-xr-x. 1 root root 10869 Oct  7 15:02 30_os-prober
-rwxr-xr-x. 1 root root  1122 Oct  7 15:02 30_uefi-firmware
-rwxr-xr-x. 1 root root   703 Nov 19 05:58 35_fwupd
-rwxr-xr-x. 1 root root   218 Oct  7 15:02 40_custom
-rwxr-xr-x. 1 root root   219 Oct  7 15:02 41_custom
-rw-r--r--. 1 root root   483 Oct  7 15:02 README

os-prober is finding OpenSUSE.

[jeremy@fedora ~]$ sudo os-prober
/dev/mapper/system-root:openSUSE Tumbleweed:openSUSE:linux
/dev/mapper/system-root:openSUSE Tumbleweed:openSUSE1:linux:btrfs:UUID=fa6d8436-fd7a-4d53-a799-da2ff5a9fdac:subvol=@/.snapshots/1/snapshot

grub2-mkconfig is finding openSUSE.

[jeremy@fedora ~]$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Generating grub configuration file ...
Found openSUSE Tumbleweed on /dev/mapper/system-root
Found openSUSE Tumbleweed on /dev/mapper/system-root
Adding boot menu entry for UEFI Firmware Settings ...
done

But then when I reboot, the grub menu just has a handful of Fedora kernels and an entry to get to UEFI settings.

I am aware that adding a 40_custom script could get TW onto the grub menu, but I would like to figure out how to get the os-prober option working if possible. I feel like it will make booting other distros in the future all the simpler, without having to put together a new 40_custom script every time.

Any insight would be appreciated, thank you!

2

It looks like you may have 2 efi partitions and most systems work best with only one efi partition. With 2 efi partitions you have to use the bios boot menu to select the OS to boot or always allow it to boot just the one OS (or merge the content of the 2 efi partitions into one).
Also be aware that with 2 linux systems the one that most recently updates grub may take control of the grub boot menu unless you are careful with how you do the updates.

You are on fedora 35, and the command you used to update grub is wrong since fedora 34.
The grub.cfg file at /boot/efi/EFI/fedora/grub.cfg is a link that redirects grub to /boot/grub2/grub.cfg
The best command to use for updating grub is grub2-mkconfig -o /etc/grub2-efi.cfg for an efi system which you apparently have. Both the files /etc/grub2.cfg and /etc/grub2-efi.cfg are pointers to /boot/grub2/grub.cfg since that is the new location for the main grub.cfg file.

# ls -ld /etc/grub2*
lrwxrwxrwx. 1 root root   22 Oct  7 14:02 /etc/grub2.cfg -> ../boot/grub2/grub.cfg
lrwxrwxrwx. 1 root root   22 Oct  7 14:02 /etc/grub2-efi.cfg -> ../boot/grub2/grub.cfg

The content of /boot/efi/EFI/fedora/grub.cfg on a fedora 35 system should be the following, with UUID replaced with your system UUID for the partition mounted at /boot

# cat /boot/efi/EFI/fedora/grub.cfg
search --no-floppy --fs-uuid --set=dev   UUID
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

Now that you have replaced the original file with your command it should be restored to the install default by reinstalling the ‘grub2-efi’ packages or by inserting the text above into the grub.cfg file located in /boot/efi/EFI/fedora then rerunning the grub2-mkconfig command with the proper output location. (easiest would be the reinstall)

With all that said about grub on fedora, the issue of not booting opensuse will likely be fixed after you repair the grub on fedora and reboot.

1 Like
3

@computersavvy thank you for the thoughtful reply! I can see I am in a bit over my head… :grimacing:

It never would have occurred to me that each OS should not have a separate EFI partition, because the installer automatically makes one. Is skipping the creation of an EFI partition possible/recommended if installing a new (additional) OS? Does the new OS just borrow the existing EFI partition? It sounds like I need to do some additional reading on the EFI partition.

Is this possible? I poked around with a quick web search to see if perhaps it was something that could be easily done, but my search results were overloaded with people having problems with their Windows EFI partition getting messed up after setting up a dual-booting configuration.

On my machine, this is a fully-fledged config file (not a few lines of code like you posted above). Is that because I was running the incorrect command (grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg)? This command is from the Fedora docs website, which I was reading trying to get this all sorted out in the first place: https://docs.fedoraproject.org/en-US/Fedora/24/html/System_Administrators_Guide/ch-Working_with_the_GRUB_2_Boot_Loader.html. It sounds like maybe those pages are a little bit out of date.

I did reinstall grub2-efi like you suggested, then ran grub2-mkconfig -o /etc/grub2-efi.cfg and rebooted, but /boot/efi/EFI/fedora/grub.cfg is still a pages-long config file. Before I make a move I just wanted to ask a small point of clarification on your advice above: did you mean I should add that snippet of code to the existing grub.cfg file in /boot/efi/EFI/fedora, or that I should delete the existing file and make a new one that contains only that snippet of code?

4

The package grub2-efi creates that file in /boot/efi/EFI/fedora/grub.cfg. I do not know that it would overwrite an existing file.

What I would suggest is delete the larger file that was created and then create a new file with a text editor such as vi or nano and put only the lines I posted in the new file. You will need to run lsblk -f to get the uuid for the /boot/efi partition to put into that file before it will work.

Someone else who works with grub regularly and has already handled the issue with 2 efi partitions will need to assist in configuring the data so one grub can boot both systems. It is possible with 2 partitions but I have not tried it myself so have no experience.

5

@computersavvy I replaced the grub.cfg file in /boot/efi/EFI/fedora with the snippet of code you pasted, using lsblk -f to get the UUID of the first partition of the disk and adding that in place of “UUID” in the first line, but I am afraid it broke something and now I cannot boot into Fedora.

DSC_0243
DSC_02431920×1080 70.1 KB

I am not familiar with this prompt but it doesn’t look good! :grimacing:

Is this something I can recover from? I can still boot to openSUSE, but all my stuff is on the Fedora disk.

6

@computersavvy I am pretty sure I made a mistake following your directions; looking at the disk now with lsblk in openSUSE, I believe the first partition (the one I added the UUID of into the grub.cfg file) is the /boot/efi partition, not the /boot partition. :man_facepalming:

My plan now is to copy the disk out to an external drive and reinstall, and go from there. Thank you for trying to help me!

7

You have 2 threads on 2 forums open for this.

I have also answered in that forum since I did not recognize the issue until now. Posting the same question in multiple forums is discouraged.

I suspect you did not enter the UUID correctly, and you should be able to mount the /dev/nvme0n1p1 device in opensuse and fix the editing error.

If you mount /dev/nvme0n1p1 at /mnt, then post the content of /mnt/EFI/fedora/grub.cfg as well as the output of ‘lsblk -f’ I may be able to identify the errors and suggest a fix.

If that does not work then you may need to do everything in order, by mounting the entire fedora directory tree, do a chroot to that environment, then after fixing the grub.cfg error rerun grub2-mkconfig in the chroot fedora environ and fix it.

8

For some reason I thought posting the issue on two different websites would reach two different audiences, but it sounds like the truth is I may have wasted your time and I apologize about that. I can see you keep yourself busy!

Thank you for that idea of fixing the grub.cfg file by mounting the disk from openSUSE. That was obviously much easier than the rectification I was planning. I was able to slap the correct UUID into the file and Fedora booted up normally as if nothing had ever happened.

1 Like
9

It does reach different audiences, but there is also overlap.
The real issue is that the fix may be given on one site and never seen on the other site so readers cannot always find the fix.

In fact, my answer on the other site is different than what I posted here.

10

I did a bit more reading on the EFI partition, and found in the openSUSE documentation that SUSE is supposed to identify an existing EFI partition and sort of jump in with it instead of making a separate one. I started up the openSUSE installer again to see if there was some configuration choice I made that disrupted that, but I honestly couldn’t even figure out how to stop it from making a new EFI partition.

The only thing I can think of is that the two OS’s are on two physically separate disks (instead of one disk with two partitions), and configuring a setup where the OS uses a partition off of another disk to boot might be a little beyond the scope of the defaults in the installer. It is certainly beyond the scope of my skill set, in any case.

I think I am going to try to set up a second partition on the nvme drive and install TW there (and use the SATA drive for storage or something). That way it will hopefully piggyback on the Fedora EFI partition, I can probably get them both on the same grub menu. Who knows, I might still need that 40_custom script after all but I think that might be a good place to start.

Thanks again for your help.

11

Hi,

If your openSUSE use LVM, you should activate first logical volumes in a volume group:

# Find volume group
$ sudo vgscan

# Activate it
$ sudo vgchange -ay volume-group-from-vgscan

# Run grub2-mkconfig
# If in the past your grub.cfg located on /boot/efi/EFI/fedora/grub.cfg then
$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

# If you never run grub2-mkconfig before
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

But there are a caveat. Each time when you running grub2-mkconfig, your terminal will give you messages like:

File descriptor 3 (pipe:[14444]) leaked on vgs invocation. Parent PID 39999: grub2-probe
File descriptor 9 (pipe:[14444]) leaked on vgs invocation. Parent PID 39999: grub2-probe

But it’s should be ok.

12

@oprizal please pay attention to data in earlier posts.

One thing he did wrong was running grub2-mkconfig to the file under EFI. He is running fedora 35 and with that you should never use the file under EFI, but instead use one of the paths I listed in post #2 above.

I agree with the rest of your post. By default fedora 35 does not use LVM so he does need to activate the VG on fedora before he runs the grub2-mkconfig command.

@bluishhumility
I suspect the openSUSE installer is similar to the fedora installer in that an automatic install that has only one disk selected will not be able to select the existing efi partition on the other drive.

After thinking a bit more about the possibility of doing a reinstall of suse, here is my suggested path.

  1. From fedora, delete all the partitions on /dev/sda

  2. Make a backup of fedoras /boot/grub2 directory as well as a backup of the /boot/efi/EFI directory, and store them in your users home directory or on a USB so they are easy to recover if needed. The backup needs to have the files saved with the existing permissions.

  3. redo the install of suse, but select both drives. Do not allow it to erase fedora, but it should install the LVM on sda and use the existing efi partition for its efi configs.

  4. Attempt to boot fedora. It should, but may not. If it does not then boot to suse and we can recover with just a bit of playing. The suse grub install may allow booting fedora with no issues.

  5. Once fedora is booted then redo the grub2-mkconfig -o /etc/grub2-efi.cfg and that should put the suse OS into the fedora grub boot menu.

13

I gave it some thought and before you posted that suggestion I had already decided to divvy up the nvme drive into a few different partitions and try to lay out a couple OS’s on the same drive. The other drive I will maybe use for storage, or it will perhaps just sit there until I need it for something else.

[jeremy@fedora ~]$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 465.8G  0 disk 
zram0       252:0    0     8G  0 disk [SWAP]
nvme0n1     259:0    0 931.5G  0 disk 
├─nvme0n1p1 259:1    0   600M  0 part /boot/efi
├─nvme0n1p2 259:2    0     1G  0 part /boot
├─nvme0n1p3 259:3    0 691.3G  0 part /home
│                                     /
├─nvme0n1p4 259:4    0 119.2G  0 part 
├─nvme0n1p5 259:5    0 117.4G  0 part 
└─nvme0n1p6 259:6    0     2G  0 part [SWAP]

The first three partitions are still Fedora, five and six are suse, and the fourth one is set aside for something else to try out (maybe Manjaro?).

Installing to the same disk like this allowed suse to jump on to the EFI Fedora has set up, which was expected and good.

OS-prober finds suse:

[jeremy@fedora ~]$ sudo os-prober
[sudo] password for jeremy: 
/dev/nvme0n1p5:openSUSE Tumbleweed:openSUSE:linux
/dev/nvme0n1p5:openSUSE Tumbleweed:openSUSE1:linux:btrfs:UUID=9279cfde-ed01-4dbd-bfd6-68621efe0a75:subvol=@/.snapshots/1/snapshot

grub2-mkconfig lists it:

[jeremy@fedora ~]$ sudo grub2-mkconfig -o /etc/grub2-efi.cfg
Generating grub configuration file ...
Found openSUSE Tumbleweed on /dev/nvme0n1p5
Found openSUSE Tumbleweed on /dev/nvme0n1p5
Adding boot menu entry for UEFI Firmware Settings ...
done

I rebooted and was really hoping to finally see suse on the grub menu, but I must still be missing something! It’s still just a bunch of Fedora kernels and the UEFI settings menu entry.

For my use case this disk setup is probably going to be better anyway, and I have certainly learned a lot hacking around with this little project, but I sure am stumped on this grub menu.

14

Btw next time, no need to reboot to check if that work or not. Just open /boot/grub2/grub.cfg or /boot/efi/EFI/fedora/grub.cfg depending where you save your config and find menu entry part or Comment mentioning OS probe. It’s more fast rather than rebooting your pc each time you make new configuration. It also make us aware the changed happen in grub.cfg and minimize the probabilities of being stuck on boot.

15

Thank you for the tip! That does seem helpful.

Looking through /boot/grub2/grub.cfg after running grub2-mkconfig -o /etc/grub2-efi.cfg, it appears the os-prober space is empty when I guess I would expect it to be getting entries for suse.

### BEGIN /etc/grub.d/30_os-prober ###


### END /etc/grub.d/30_os-prober ###

So perhaps I should next direct my troubleshooting efforts toward figuring out why os-prober is not writing to this config file.

1 Like
16

Update:

I installed Manjaro on the 4th partition of the nvme drive.

[jeremy@fedora ~]$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 465.8G  0 disk 
zram0       252:0    0     8G  0 disk [SWAP]
nvme0n1     259:0    0 931.5G  0 disk 
├─nvme0n1p1 259:1    0   600M  0 part /boot/efi
├─nvme0n1p2 259:2    0     1G  0 part /boot
├─nvme0n1p3 259:3    0 691.3G  0 part /home
│                                     /
├─nvme0n1p4 259:4    0 119.2G  0 part 
├─nvme0n1p5 259:5    0 117.4G  0 part 
└─nvme0n1p6 259:6    0     2G  0 part [SWAP]

Fedora on p1-p3, Manjaro on p4, suse on p5&6.

I did not expect this third OS installation to change the situation with grub, but interestingly Manjaro is showing up on the grub menu.

OS-prober finds suse and Manjaro:

[jeremy@fedora ~]$ sudo os-prober
/dev/nvme0n1p4:Manjaro Linux (21.2rc):ManjaroLinux:linux
/dev/nvme0n1p5:openSUSE Tumbleweed:openSUSE:linux
/dev/nvme0n1p5:openSUSE Tumbleweed:openSUSE1:linux:btrfs:UUID=9279cfde-ed01-4dbd-bfd6-68621efe0a75:subvol=@/.snapshots/1/snapshot

grub2-mkconfig lists both OS:

[jeremy@fedora ~]$ sudo grub2-mkconfig -o /etc/grub2-efi.cfg
Generating grub configuration file ...
Found Manjaro Linux (21.2rc) on /dev/nvme0n1p4
Found openSUSE Tumbleweed on /dev/nvme0n1p5
Found openSUSE Tumbleweed on /dev/nvme0n1p5
Adding boot menu entry for UEFI Firmware Settings ...
done

And now there is an entry under 30_os-prober in /boot/grub2/grub.cfg–just for Manjaro though.

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Manjaro Linux (21.2rc) (on /dev/nvme0n1p4)' --class manjarolinux --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulin>
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root e2161676-1ce7-4dd7-a98f-83b7fef11d79
        linux /boot/vmlinuz-5.13-x86_64 root=UUID=e2161676-1ce7-4dd7-a98f-83b7fef11d79 rw quiet apparmor=1 security=apparmor udev.log_priority=3
        initrd /boot/intel-ucode.img
}
submenu 'Advanced options for Manjaro Linux (21.2rc) (on /dev/nvme0n1p4)' $menuentry_id_option 'osprober-gnulinux-advanced-e2161676-1ce7-4dd7-a98f-83b7fef>
        menuentry 'Manjaro Linux (on /dev/nvme0n1p4)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-5.13->
                insmod part_gpt
                insmod ext2
                search --no-floppy --fs-uuid --set=root e2161676-1ce7-4dd7-a98f-83b7fef11d79
                linux /boot/vmlinuz-5.13-x86_64 root=UUID=e2161676-1ce7-4dd7-a98f-83b7fef11d79 rw quiet apparmor=1 security=apparmor udev.log_priority=3
                initrd /boot/intel-ucode.img
        }
        menuentry 'Manjaro Linux (Kernel 5.13.19-2-MANJARO x64) (on /dev/nvme0n1p4)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprob>
                insmod part_gpt
                insmod ext2
                search --no-floppy --fs-uuid --set=root e2161676-1ce7-4dd7-a98f-83b7fef11d79
                linux /boot/vmlinuz-5.13-x86_64 root=UUID=e2161676-1ce7-4dd7-a98f-83b7fef11d79 rw quiet apparmor=1 security=apparmor udev.log_priority=3
                initrd /boot/intel-ucode.img
        }
        menuentry 'Manjaro Linux (Kernel 5.13.19-2-MANJARO x64 - fallback initramfs) (on /dev/nvme0n1p4)' --class gnu-linux --class gnu --class os $menuen>
                insmod part_gpt
                insmod ext2
                search --no-floppy --fs-uuid --set=root e2161676-1ce7-4dd7-a98f-83b7fef11d79
                linux /boot/vmlinuz-5.13-x86_64 root=UUID=e2161676-1ce7-4dd7-a98f-83b7fef11d79 rw quiet apparmor=1 security=apparmor udev.log_priority=3
                initrd /boot/initramfs-5.13-x86_64-fallback.img
        }
        menuentry 'Memory Tester (memtest86+) (on /dev/nvme0n1p4)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/>
                insmod part_gpt
                insmod ext2
                search --no-floppy --fs-uuid --set=root e2161676-1ce7-4dd7-a98f-83b7fef11d79
                linux /boot/memtest86+/memtest.bin
        }
}



# Other OS found, undo autohiding of menu unless menu_auto_hide=2
if [ "${orig_timeout_style}" -a "${menu_auto_hide}" != "2" ]; then
  set timeout_style=${orig_timeout_style}
  set timeout=${orig_timeout}
fi
### END /etc/grub.d/30_os-prober ###

So I guess the grub problem is related specifically to OpenSUSE TW, or at least seems to be.

@oprizal I did attempt to activate logical volumes like you suggested, but it looks like suse was installed without them.

[jeremy@fedora ~]$ sudo vgscan -v
  No volume groups found.

So perhaps there is something else unique about suse TW that is preventing os-prober from serving it as a grub entry.

Anyway I just wanted to pass along that update because it was not something I was expecting. I’ll keep digging and see if I can learn more about what’s going on.

17

This may be a bit of a cop-out solution, but I eventually decided to install the rEFInd bootloader and use that instead of grub.

I did want to get grub figured out, but I felt like I was getting into the weeds a bit. This seems like a good option for my setup.

My initial impression is positive. It is very easy to setup, works fine for booting into any of the three OS’s, and it looks nice.

18

If you still interest please run lsblk -f. With -f option we can see the LVM type of your partitions. Check if your partition where OpenSUSE located ( nvme0n1p5) if it using LVM2.

19

Hmm, I do not see LVM indicated in this output.

NAME        FSTYPE FSVER LABEL                 UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda         btrfs                              c56fd43b-8d8a-4e78-87a0-13b02ec1d32d    388G    16% /mnt/samsung860
zram0                                                                                              [SWAP]
nvme0n1                                                                                            
├─nvme0n1p1 vfat   FAT32                       2A3B-5241                             570.5M     5% /boot/efi
├─nvme0n1p2 ext4   1.0                         fca0009d-3afc-47cd-8b1f-8d5d53f366cc  657.8M    26% /boot
├─nvme0n1p3 btrfs        fedora_localhost-live c3b2f18c-a60e-47d1-99ab-c95f0150ffa0  565.3G     1% /home
│                                                                                                  /
├─nvme0n1p4 ext4   1.0                         e2161676-1ce7-4dd7-a98f-83b7fef11d79                
├─nvme0n1p5 btrfs                              9279cfde-ed01-4dbd-bfd6-68621efe0a75                
├─nvme0n1p6 swap   1                           e0fbc37c-1963-4bbb-92ad-809b023f71a7                [SWAP]
└─nvme0n1p7

When I was going throught the OpenSUSE installer, the default configuration was set up with the partition I wanted to use. Funnily, when I entered the custom installation menu it switched to trying to install to the second drive (/sda) and I couldn’t figure out how to get it back to the partition I wanted. So I just stuck with the default configuration, which might not have LVM automatically enabled. I am not familiar with LVM as it is, so it wasn’t a feature I was specifically seeking out.

20

I just give up :sweat_smile:

In opensuse, if we using UEFI, it will mount *.mod file on /boot/grub2/x86_64-efi folder. But on Legacy BIOS it will mount the *.mod in /boot/grub2/i386-pc.

If just chainloading boot to opensuse from Fedora grub, those 2 folder are empty (not mounted) and will failed to boot except we disable the secureboot.