Migrating from grub to rEFInd. Snapshots and other things

I have no issue setting it up with booting from grub or the vmlinux-linux image file. On grub i can boot and have the snapshots because it’s grub. Booting from the image file and trying to set it up with refind-btrfs isn’t booting for me. It ends up messing up the current image file to be able to boot from it. I have been able to get a snapshot icon on the screen but fails to boot also.

Ok, tha didn’t work either. This is pretty frustrating. It’s not the end of the world, the snapshots are visible in grub if I really need them. But it’s the principle of the thing, I want to get them visible in rEFInd too. :wink:

Messing with it in vm but i still can’t get it to boot on the arch icons or snapshot entry. I also don’t know how to create more snapshot entries? snap-pac makes lots. Just don’t have enough understanding. But i tried. :sob:

Screenshot_20220911_224758

Screenshot_20220911_224831

Edit: The snapshot entries are there if I press f2 but none are bootable.

What happens when you select that entry (shown in the second picture)?

Can you explain the problem you are trying to solve in the first place? Why does it matter where the subvolume mounted at @ has a parent UUID or not? I am not sure I follow the issue from reading the github link.

The problem is that there is only one ESP which contains the rEFInd installation and nested generated snapshot boot stanzas. The latter ones are contained in their own files which are overwritten with each refind-btrfs run.

Now, considering the fact that at any given time there is exactly one root subvolume (the one mounted at /, to avoid confusion - let’s name it ‘@’) and at least one snapshot of that subvolume (let’s name it ‘@-snapshot-1’) it is challenging to support flattening the union of created snapshots (and presenting it in a single generated boot stanza) for both ‘@’ AND ‘@-snapshot-1’ once you’ve booted into the latter because, remember, there is exactly one ESP.
What happens when, for example, Snapper creates a snapshot of ‘@-snapshot-1’ (let’s name it ‘@-snapshot-1-snapshot-1’ - you can see where this is going, I hope…) once you’ve chosen to boot from it? Snapper (and Timeshift as well, I imagine) does not care whether the subvolume mounted at / is a snapshot or not.

Currently, once you boot into ‘@-snapshot-1’ (while having this flag turned off) and its own snapshot is created (by Snapper, Timeshift or some other tool) refind-btrfs will generate a new manual boot stanza which will contain solely an entry for the newly created ‘@-snapshot-1-snapshot-1’ and overwrite whatever was created for the previously mounted ‘@’ subvolume which means that you won’t even be able to select ‘@-snapshot-1’ if you reboot after the fact. That is quite unfortunate, if you ask me.

Hence why I’ve proposed an elegant, albeit somewhat cumbersome, solution where the current root subvolume’s UUID is explicitly defined within the refind-btrfs.conf file. That way, the scenario described in the previous paragraph wouldn’t happen at all because I could detect the mismatch, issue an error and exit prematurely.

Couldn’t the same thing by achieved using the subvolume path relative to the root of the filesystem instead of the UUID? i.e. specify @ in the config file? In theory the path to the subvolume would always be the same even if you restored it with a different UUID.

When you click on it and press enter it just stays at the same spot. I’m not sure if permission changes are needed to be made to the snapshots? It just kind of flickers but does nothing.

Edit: I’m not sure whether i have it configured correctly either?

It’s pretty hard to tell with the information I’ve got, sorry.

That does seem like a better solution, agreed. Booting into a snapshot would mean that the currently mounted subvolume’s logical path is different that one expected in the config file.
After the actual root subvolume is restored from a chosen snapshot all should be well because these two paths should be matched, once again.

Thank you for the suggestion, I’ll try playing around with it on my machine.

1 Like

I can understand that. I just have xfce on btrfs with swap file. I installed btrfs-assistant, snapper and snap-pac.
I set up btrfs assistant snapper config for root only. I then installed refind which works to boot from grubx64.efi or the vmlinuz-linux image file. Added the icon for eos using the grubx64.efi. I kept theTux icon for the vmlinuz-linux imag file. Then i installed refind-btrfs.

I added to scan all dirs with also_scan_dirs @/boot,ESP2:EFI/linux/kernels
I added this manual stanza

menuentry "Arch Linux - Stable" {
    icon /EFI/refind/icons/os_arch.png
    volume ARCH
    loader /@/boot/vmlinuz-linux
    initrd /@/boot/initramfs-linux.img
    options "root=PARTUUID=4291d82f-b88f-4b2d-89e0-738d44b6e8c3 rw add_efi_memmap rootflags=subvol=@ initrd=@\boot\amd-ucode.img"
    submenuentry "Boot - fallback" {
        initrd /@/boot/initramfs-linux-fallback.img
    }
    submenuentry "Boot - terminal" {
        add_options "systemd.unit=multi-user.target"
    }
}

I think that’s all i did but not sure if i forget something. I don’t think i did anything else. I did look at the refind-btrfs.conf file.

Try this:

  • stop the refind-btrfs.service (if it is running) - systemctl stop refind-btrfs
  • manually create a new snapshot with Snapper
  • run the refind-btrfs command and paste its output here

EDIT:
This is the output on my machine (three kernels, each with its own separate boot stanza):

Initializing the block devices using lsblk.
Initializing the physical partition table for device '/dev/nvme0n1' using lsblk.
Initializing the live partition table for device '/dev/nvme0n1' using findmnt.
Found the ESP mounted at '/efi' on '/dev/nvme0n1p3'.
Found the root partition on '/dev/nvme0n1p8'.
Searching for snapshots of the '@' subvolume in the '/.snapshots' directory.
Found subvolume '@' mounted as the root partition.
Found 33 snapshots of the '@' subvolume.
Searching for the 'refind.conf' file on '/dev/nvme0n1p3'.
Found 3 boot stanzas matched with the root partition.
Initializing the static partition table for subvolume '@snapper-root/2502/snapshot' from its fstab file.
Found 1 snapshot for addition.
Found 1 snapshot for removal.
Creating a new writable snapshot from the read-only '@snapper-root/2502/snapshot' snapshot at '/root/.refind-btrfs/rwsnap_2022-09-12_16-22-18_ID7172'.
Modifying the '/root/.refind-btrfs/rwsnap_2022-09-12_16-22-18_ID7172/etc/fstab' file.
Deleting the '@rw-snapshots/rwsnap_2022-09-12_10-00-11_ID7159' snapshot.
Writing to the 'btrfs-snapshot-stanzas/arch_vmlinuz-linux-xanmod.conf' file.
Writing to the 'btrfs-snapshot-stanzas/arch_vmlinuz-linux.conf' file.
Writing to the 'btrfs-snapshot-stanzas/arch_vmlinuz-linux-lts.conf' file.

Yes i did have refind-btrfs.service running. Is stopped now. Made a manual snapshot. Ran sudo refind-btrfs

[sudo] password for ricklinux: 
Initializing the block devices using lsblk.
Initializing the physical partition table for device '/dev/sda' using lsblk.
Initializing the live partition table for device '/dev/sda' using findmnt.
Initializing the physical partition table for device '/dev/sr0' using lsblk.
Initializing the live partition table for device '/dev/sr0' using findmnt.
Found the ESP mounted at '/boot/efi' on '/dev/sda1'.
ERROR (refind_btrfs.state_management.conditions/conditions.py/check_filtered_block_devices): Could not find the root partition!
[ricklinux@rick-virtualbox ~]$ 

Edit: So it’s not finding root?
Edit2: This is on virtual box also just f.y.i.

It looks like that’s the case. Try pasting the output of findmnt -t btrfs here.

[ricklinux@rick-virtualbox ~]$ findmnt -t btrfs
TARGET       SOURCE                                                          FSTYPE OPTIONS
/            /dev/disk/by-uuid/4291d82f-b88f-4b2d-89e0-738d44b6e8c3[/@]      btrfs  rw,noatime,compr
├─/home      /dev/disk/by-uuid/4291d82f-b88f-4b2d-89e0-738d44b6e8c3[/@home]  btrfs  rw,noatime,compr
├─/swap      /dev/disk/by-uuid/4291d82f-b88f-4b2d-89e0-738d44b6e8c3[/@swap]  btrfs  rw,noatime,compr
├─/var/log   /dev/disk/by-uuid/4291d82f-b88f-4b2d-89e0-738d44b6e8c3[/@log]   btrfs  rw,noatime,compr
└─/var/cache /dev/disk/by-uuid/4291d82f-b88f-4b2d-89e0-738d44b6e8c3[/@cache] btrfs  rw,noatime,compr
[ricklinux@rick-virtualbox ~]$ 

Yeah, that’s a bit different compared to mine:

/                     /dev/nvme0n1p8[/@]             btrfs  rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=256,subvol=/@
├─/root/.refind-btrfs /dev/nvme0n1p8[/@rw-snapshots] btrfs  rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=264,subvol=/@rw-snapshots
├─/.snapshots         /dev/nvme0n1p8[/@snapper-root] btrfs  rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=262,subvol=/@snapper-root
├─/var/tmp            /dev/nvme0n1p8[/@var-tmp]      btrfs  rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=261,subvol=/@var-tmp
├─/home               /dev/nvme0n1p8[/@home]         btrfs  rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=257,subvol=/@home
│ └─/home/.snapshots  /dev/nvme0n1p8[/@snapper-home] btrfs  rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=263,subvol=/@snapper-home
├─/tmp                /dev/nvme0n1p8[/@tmp]          btrfs  rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=258,subvol=/@tmp
├─/var/cache          /dev/nvme0n1p8[/@var-cache]    btrfs  rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=259,subvol=/@var-cache
└─/var/log            /dev/nvme0n1p8[/@var-log]      btrfs  rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=260,subvol=/@var-log

Should i have also scan all directories with /@/boot?

Nope, that’s an option specific to rEFInd.

Is what i have correct then? I’m not very well versed with btrfs. :wink:

also_scan_dirs @/boot,ESP2:EFI/linux/kernels

It’s not really necessary once you’ve defined a working manual boot stanza.

So i can comment that out? Maybe the stanza is incorrect?