GRUB Issues: os-prober Not Detecting Manjaro Root Subvolume, BTRFS

jackdinn · 19 2024 22:23

Hello,

I’m encountering an issue with os-prober not detecting my Manjaro root subvolume when I run update-grub. Here are the details of my system:

System Information:

inxi -b

System:
Host: greg-venusseries Kernel: 6.9.12-1-MANJARO arch: x86_64 bits: 64
Desktop: KDE Plasma v: 6.0.5 Distro: Manjaro Linux
Machine:
Type: Desktop System: Micro (HK) Tech product: Venus Series v: N/A
Mobo: Shenzhen Meigao Equipment model: AHWSA serial:
UEFI: American Megatrends LLC. v: AHWSA.1.22 date: 03/12/2024

Issue Description:

I am running update-grub with os-prober enabled to detect any additional OS installations on my system.
My Manjaro installation is on a Btrfs filesystem, with the root subvolume located at @.

❱cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=F6F9-F0D0                            /boot/efi      vfat    umask=0077 0 2
UUID=992bfc64-a9b6-4084-a727-cb2c64726fc2 /              btrfs   subvol=/@,defaults,noatime,discard=async,ssd 0 0
UUID=992bfc64-a9b6-4084-a727-cb2c64726fc2 /home          btrfs   subvol=/@home,defaults,noatime,discard=async,ssd 0 0
UUID=992bfc64-a9b6-4084-a727-cb2c64726fc2 /var/cache     btrfs   subvol=/@cache,defaults,noatime,discard=async,ssd 0 0
UUID=992bfc64-a9b6-4084-a727-cb2c64726fc2 /var/log       btrfs   subvol=/@log,defaults,noatime,discard=async,ssd 0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
UUID=9cf42b0a-d6e9-4cb2-9c17-e8e1c0c786d7 none swap sw 0 0

os-prober is failing to detect my Manjaro installation. As a result, I’m concerned that running update-grub with os-prober active could remove my existing GRUB entry for Manjaro, leaving me unable to boot into my system.

Here is the relevant GRUB entry for my current OS:

menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-992bfc64-a9b6-4084-a727-cb2c64726fc2' {
    load_video
    set gfxpayload=keep
    insmod gzio
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 992bfc64-a9b6-4084-a727-cb2c64726fc2
    linux   /@/boot/vmlinuz-6.9-x86_64 root=UUID=992bfc64-a9b6-4084-a727-cb2c64726fc2 rw rootflags=subvol=@  udev.log_priority=3
    initrd  /@/boot/intel-ucode.img /@/boot/amd-ucode.img /@/boot/initramfs-6.9-x86_64.img
}

My btrfs list

❱sudo btrfs subvolume list /
ID 257 gen 70349 top level 5 path @home
ID 258 gen 70195 top level 5 path @cache
ID 259 gen 70349 top level 5 path @log
ID 1398 gen 70349 top level 5 path @
ID 1409 gen 69959 top level 5 path timeshift-btrfs/snapshots/2024-08-18_19-00-00/@
ID 1410 gen 67966 top level 5 path timeshift-btrfs/snapshots/2024-08-18_19-00-00/@home
ID 1411 gen 69959 top level 5 path timeshift-btrfs/snapshots/2024-08-18_20-00-01/@
ID 1412 gen 68083 top level 5 path timeshift-btrfs/snapshots/2024-08-18_20-00-01/@home
ID 1413 gen 69959 top level 5 path timeshift-btrfs/snapshots/2024-08-18_21-00-00/@
ID 1414 gen 68201 top level 5 path timeshift-btrfs/snapshots/2024-08-18_21-00-00/@home
ID 1415 gen 69959 top level 5 path timeshift-btrfs/snapshots/2024-08-18_22-00-01/@
ID 1416 gen 68319 top level 5 path timeshift-btrfs/snapshots/2024-08-18_22-00-01/@home
ID 1417 gen 69959 top level 5 path timeshift-btrfs/snapshots/2024-08-18_23-00-00/@
ID 1418 gen 68438 top level 5 path timeshift-btrfs/snapshots/2024-08-18_23-00-00/@home
ID 1419 gen 69959 top level 5 path timeshift-btrfs/snapshots/2024-08-19_00-00-00/@
ID 1420 gen 68556 top level 5 path timeshift-btrfs/snapshots/2024-08-19_00-00-00/@home
ID 1421 gen 69959 top level 5 path timeshift-btrfs/snapshots/2024-08-19_01-00-01/@
ID 1422 gen 68674 top level 5 path timeshift-btrfs/snapshots/2024-08-19_01-00-01/@home
ID 1423 gen 69959 top level 5 path timeshift-btrfs/snapshots/2024-08-19_01-30-32/@

What I’ve Tried:

Cleared out Btrfs snapshots that were listed before the root subvolume (@), but os-prober still doesn’t detect any OS. It was detecting the very first snapshot but i deleted it and now it does not detect any of them.
Ran os-prober manually, which only detects my Windows Boot Manager but not my Manjaro installation.
Checked boot files in /@/boot/ and verified that they exist.

It was detecting the very top snapshot, which was incorrect:

❱sudo os-prober
/dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi
/dev/nvme0n1p5:Manjaro Linux:Manjaro:linux:btrfs:UUID=992bfc64-a9b6-4084-a727-cb2c64726fc2:subvol=timeshift-btrfs/snapshots/2024-07-21_13-59-14/@

So i tried deleting it, but that did not work:

❱sudo os-prober
/dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi

Concerns:

If I proceed with running update-grub with os-prober active, could this remove the GRUB entry for my Manjaro installation, leaving me with no option to boot into my system?

Request for Assistance:

How can I ensure os-prober correctly detects my Manjaro root subvolume?
Is there a safer way to use os-prober with Btrfs subvolumes to avoid losing my GRUB entry for Manjaro?
Any suggestions or alternative approaches would be greatly appreciated!

Thank you for your help!

Molski · 20 2024 00:02

When viewing the subvolume list, it defaults to sort by subvolid, so the order does not matter. After any type of restore, you would have your @ down at the bottom with a higher number subvolid, as one example.

I may be wrong, but I was always under the assumption os-prober was for other OSs (even ones contained within the current mounted filesystem). I just tested the command on two of my systems, and it’s detecting a Timeshift volume, instead of my main Manjaro btrfs @ volume on both. (Which is not the case.)

findmnt /
TARGET SOURCE             FSTYPE OPTIONS
/      /dev/nvme0n1p2[/@] btrfs  rw,relatime,ssd,discard=async,space_cache=v2,autodefrag,subvolid=715,subvol=/@

sudo os-prober
/dev/nvme0n1p2:Manjaro Linux:Manjaro:linux:btrfs:UUID=310e0472-f96e-485c-8fa1-585bcccfb624:subvol=timeshift-btrfs/snapshots/2024-05-29_15-03-50/@
/dev/nvme1n1p1@/efi/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi

Still different results unfortunately. But in the stable release channel, kernel 6.9 has been EOL. Have you tried a supported kernel?

jackdinn · 20 2024 00:26

So you think that because i would be running update-grub from this system that im currently using that it should not remove the grub menu for this os?

I really dont want to test it just to see without knowing 100%.

yep, thats what is/was happening on mine, snapshots/2024-05-29_15-03-50/@ is certainly the wrong subvolume, (its not even a subvol, its a readonly snapshot, so that would be fun if it did try to mount and use it).

Im not sure how a different kernel would make a difference? (Im on Kernel: 6.9.12-1). I would think this is down to the script of os-prober.

I often install plenty of other os’s in parallel but now i have switched over to btrfs i dare not touch it. I would need to use os-prober if i want to install any more (and i do).

Molski · 20 2024 01:04

I was having different btrfs problems when I was running 6.9 after the last stable update (setting NoCoW on files and dirs). The switch fixed it.

The /boot/grub/grub.cfg file is generated from the grub package. It puts the files in /etc/grub.d for this. os-prober puts one file in here.

When you update-grub, you can see when os-prober gets called after it generates grub.cfg:

sudo update-grub
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-6.6-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.6-x86_64.img
Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img
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.
Found Manjaro Linux on /dev/nvme0n1p2
Found Windows Boot Manager on /dev/nvme1n1p1@/efi/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
Detecting snapshots ...
Found snapshot: 2024-08-13:15:51 | timeshift-btrfs/snapshots/2024-08-09_20-15-51/@ | ondemand | {timeshift-autosnap}
Found snapshot: 2024-08-09 10:55:53 | timeshift-btrfs/snapshots/2024-08-13_10-55-53/@ | ondemand | Manual - remove 17 orphans
...
Found 22 snapshot(s)
Unmount /tmp/grub-btrfs.PHugQA2zAB .. Success
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done

Then the package btrfs-grub puts all the RW snapshots it detects in there too. But even going into the packages’ shell scripts of both grub and os-prober. You can easily see it’s all grub.

Here’s what package owns what file here:

pacman -Qo /etc/grub.d/*
/etc/grub.d/00_header is owned by grub 2.12-4
/etc/grub.d/10_linux is owned by grub 2.12-4
/etc/grub.d/15_ostree is owned by ostree 2024.7-1
/etc/grub.d/20_linux_xen is owned by grub 2.12-4
/etc/grub.d/25_bli is owned by grub 2.12-4
/etc/grub.d/30_os-prober is owned by grub 2.12-4
/etc/grub.d/30_uefi-firmware is owned by grub 2.12-4
/etc/grub.d/35_fwupd is owned by fwupd 1.9.22-2
/etc/grub.d/40_custom is owned by grub 2.12-4
/etc/grub.d/41_custom is owned by grub 2.12-4
/etc/grub.d/41_snapshots-btrfs is owned by grub-btrfs 4.13-2
/etc/grub.d/60_memtest86+ is owned by memtest86+ 7.00-1
/etc/grub.d/README is owned by grub 2.12-4

P.S.:

Snapshots are a type of volume, and you treat them as volumes. And you can mount root and boot RO volumes with overlayfs just fine. But it’s even easier to create a snapshot of that RO volume, that defaults to RW.

And I’m really rushing to get this post done, as I’m walking out the door. I’m sure I’ll edit grammar later, possiblly with better info.

jackdinn · 20 2024 07:07

So what do I do? I need to use os-prober but I don’t know what to do if I lose the menu for this OS?

Is there a way to run update-grub without actually changing anything (like dry run)?

Can I take a copy of /boot/grub/grub.cfg and then if it loses the menu for this OS after running update-grub just replace what was created at /boot/grub/grub.cfg with the backup copy?

I don’t really know how it all works here, but I need to be able to use the prober.

Aragorn · 20 2024 07:36

How do you know that? The “Manjaro Linux” menu entry will normally be the one that boots your default installation.

You don’t need os-prober for that. You need to install grub-btrfs instead of the regular grub.

Correct.

What makes you believe you would lose your GRUB menu?

Yes.

jackdinn · 20 2024 07:52

Ok, if you are sure.

I had disabled os-prober some months ago but i could not remember exactly why. I know it was causing a problem with the boot menu, maybe it was creating an extra entry that i couldn’t figure why but i was worried that it was because it was removing the main menu entry.

So i came to ask.

jackdinn · 20 2024 08:21

Yes, its fine. Thank you.

When my btrfs list looked like this It was creating an extra menu entry for timeshift-btrfs/snapshots/2024-07-21_13-59-14/@

ID 256 gen 70212 top level 5 path timeshift-btrfs/snapshots/2024-07-21_13-59-14/@
ID 257 gen 70217 top level 5 path @home
ID 258 gen 70195 top level 5 path @cache
ID 259 gen 70217 top level 5 path @log
ID 262 gen 70079 top level 5 path timeshift-btrfs/snapshots/2024-07-13_08-00-24/@
ID 263 gen 493 top level 5 path timeshift-btrfs/snapshots/2024-07-13_08-00-24/@home
ID 266 gen 70079 top level 5 path timeshift-btrfs/
...

So I assume if I use the timeshift restore again and the /@ gets moved down in the list that os-prober may well start creating an unrequired menu entry.again.

For now its ok though.

system · 23 2024 08:21

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.