Can't get BTRFS Linux Mint install to be added to grub

So basically I converted my Mint partition to BTRFS and am trying to add it to Endeavour’s grub
Unfortunately os-prober doesn’t seem to work with btrfs and using the os-prober-btrfs AUR package makes it show up in the OS list but doesn’t add it to the grub.cfg
If it’s relevant the root partition (including /boot (not /boot/efi that’s its own partition)) of Mint is in the @mintroot subvolume and home directories in @minthome subvolume

I reckon the issue might be with 30_os-prober since with the patched os-prober the output seems fine
/dev/sda6:Linux Mint 21.3:Linux:linux:btrfs:UUID=e9f06825-1028-4dfe-84d4-982bb2cedd60:subvol=@mintroot

You can install os-prober-btrfs on endeavouros and it should find Mint.

Edit: Did you run sudo grub-mkconfig -o /boot/grub/grub.cfg after.

I already said I tried that
Nothing gets added to the grub.cfg no mention of mint despite os-prober finding it
And yes i did enable os-prober in the grub file

Well you didn’t say if you ran the update grub command. :smirk:

Do they have different bootloader IDs? If you use “GRUB” for both of them, one will overwrite the other and you’ll have to chroot in and reinstall the bootloader.

Check in /boot/efi/EFI/ and see what directories are in there if you aren’t sure.

The issue isnt that it doesnt show up in grub the issue is that it doesnt show up in grub.cfg at all after updating it

Perhaps the output of the following commands would give some people some more insight into your setup:

sudo parted -l

efibootmgr

tree /boot/efi

Model: ATA KINGSTON SA400S3 (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system     Name         Flags
 1      1049kB  106MB  105MB   fat32           EFI          boot, esp
 2      106MB   123MB  16,8MB                  Micr         msftres
 3      123MB   247GB  247GB   ntfs                         msftdata
 5      247GB   263GB  16,0GB  linux-swap(v1)               swap
 6      263GB   427GB  164GB   btrfs
 7      427GB   479GB  52,4GB  ext4            endeavouros
 4      479GB   480GB  633MB   ntfs                         hidden, diag

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0002,0000
Boot0000* Windows Boot Manager  HD(1,GPT,53d37c81-f163-4a28-8950-8c1955262a24,0x800,0x32000)/\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000064000100000010000000040000007fff0400
Boot0001* endeavouros   HD(1,GPT,53d37c81-f163-4a28-8950-8c1955262a24,0x800,0x32000)/\EFI\ENDEAVOUROS\GRUBX64.EFI
Boot0002* ubuntu        HD(1,GPT,53d37c81-f163-4a28-8950-8c1955262a24,0x800,0x32000)/\EFI\UBUNTU\SHIMX64.EFI
/boot/efi/EFI
├── Boot
│   ├── bootx64.efi
│   ├── fbx64.efi
│   └── mmx64.efi
├── endeavouros
│   └── grubx64.efi
└── ubuntu
    ├── BOOTX64.CSV
    ├── grub.cfg
    ├── grubx64.efi
    ├── mmx64.efi
    └── shimx64.efi

(Windows omitted because its tree is quite la- dang that sounds wrong)

1 Like

Is this EFI boot entry functional:

?

If so, one relatively easy way to have a Grub boot menu with boot entries from both of your systems would be to create a custom.cfg in your Mint’s /boot/grub.

You could then copy the menuentries from your EnOS’ grub.cfg to this custom.cfg.

This file will not be overwritten when there is an update to your Mint’s grub.

Also, since kernel images in Arch/EnOS are not named after the version, the menuentries specified in the custom.cfg won’t need to be updated whenever kernels are updated in your EnOS.

Put the boot0002 first in boot order and you should be pretty much good to go.

Not entirely sure about that
I’d rather use Endeavour’s grub due to Endeavour being more modifyable
Would it be possible to chainload Mint’s grub from Endeavour’s? I feel like for now it would be the most elegant solution

The OS being more modifiable? I fail to see what does that have to do with using a functional solution regardless the Grub being used.

At any rates, that is irrelevant. If you don’t like the proposed “workaround” you may try to chainload Mint’s Grub and see if that would get you the desired result.

Also, myself, I use systemd-boot as “boot manager” (note: not bootloader) to manage the Grub of different systems I have on one and the same btrfs partition:

https://wiki.archlinux.org/title/Systemd-boot#GRUB

This is an elegant enough solution to me. Your “mileage” may vary.

Fixed it
Had to regenerate the initramfs

mount -t btrfs -o subvol=@subvolume /mountpoint
mount /dev/sdx /mountpoint/boot/efi
for i in sys proc dev dev/pts run sys/firmware/efi/efivars; do mount -o bind "/$i" "/mountpoint/$i"; done
chroot /mountpoint /bin/bash
export HOME=/root
export PATH=$PATH:/sbin:/usr/sbin
update-initramfs -ck all
exit
grub-mkconfig -o /boot/grub/grub.cfg

Note: I did use os-prober-btrfs

1 Like

It seems to me there should have been an easier way to just regenerate the initramfs with grub on eos using btrfs and dracut? I’m not knowledgeable enough on all things btrfs and grub and dracut to really say even though I’m using btrfs myself. I have just gotten away from multibooting.

They needed to regenerate initramfs for Mint.

Okay … i wasn’t thinking about that. As i say my knowledge is limited to what i know using btrfs on eos and dual booting only with Windows on one machine. I know Mint doesn’t play nice with arch based distros when it comes to grub so it is better to use eos to control the boot. I haven’t used Mint in a while with eos and never on btrfs.

1 Like

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