Closed legendofmiracles closed 3 years ago
Yeah, I don't trim quotes from the "volume" option so it most probably couldn't match your stanza because "archlinux" != archlinux (which is what findmnt returns, without quotes). Your filesystem label is "archlinux", right? If so, try removing the quotes until I fix this, that is change the "volume" option to:
volume archlinux
rEFInd shouldn't complain, I defined a boot stanza without quotes around the "volume" option's value and it works just fine.
Based on the output, it looks like it even found my stanza! How else would it know that it's @?
It found the @ subvolume mounted as root as well as its snapshots. That's it, really.
That fixed it!
But when i run the script now, it returns a new error ;-;
[root@hydrogen legend]# refind-btrfs
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/nvme0n1p1'.
Found the root partition on '/dev/nvme0n1p4'.
Searching for snapshots of the '@' subvolume in the '/.snapshots' directory.
Found subvolume '@' mounted as the root partition.
Found 7 snapshots of the '@' subvolume.
Searching for the 'refind.conf' file on '/dev/nvme0n1p1'.
Analyzing the 'refind.conf' file.
Found 1 boot stanza matched with the root partition.
Found 5 snapshots for addition.
Creating the '/root/.refind-btrfs' destination directory with 750 permissions.
Creating a new writable snapshot from the read-only '@/.snapshots/7/snapshot' snapshot at '/root/.refind-btrfs/rwsnap_2021-02-15_23-14-54_ID918'.
Initializing the static partition table for subvolume '@/root/.refind-btrfs/rwsnap_2021-02-15_23-14-54_ID918' from its fstab file.
ERROR (refind_btrfs.state_management.refind_btrfs_machine/refind_btrfs_machine.py/run): Mount options are not matched with the current subvolume!
I rebooted after changing the volume to without "". And i'm really not sure what that error is supposed to mean.
Before modifying the snapshot's fstab file's / mount point's its mount options are first checked to see whether they match the current root subvolume (by "subvol" and/or "subvolid"). Please paste the contents of "/root/.refind-btrfs/rwsnap_2021-02-15_23-14-54_ID918/etc/fstab" so that I can have a look. You can also paste the contents of "/etc/fstab" while you're at it.
It's the first time I see this error being reported.
/root/.refind-btrfs/rwsnap_2021-02-15_23-14-54_ID918/etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p4
UUID=21b2c6c8-472c-43a7-9957-6feb23022325 / btrfs rw,relatime,compress=zstd,ssd,space_cache 0 0
# ESP, /dev/nvme0n1p1
UUID=C499-7EB8 /efi vfat defaults 0 0
and /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p4
UUID=21b2c6c8-472c-43a7-9957-6feb23022325 / btrfs rw,relatime,compress=zstd,ssd,space_cache 0 0
# ESP, /dev/nvme0n1p1
UUID=C499-7EB8 /efi vfat defaults 0 0
to save you the minute of checking them for differences:
Should I add the mount options to the fstab as well?
As far as I can tell, you haven't created any nested subvolumes which means that you're using the default subvolume (ID = 5) for everything, including snapshots. This is problematic for my tool because it is assumed that that one would create a more elaborate subvolume setup. See my fstab, for instance:
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p8 LABEL=ARCH
UUID=95250e8a-5870-45df-a7b3-3b3ee8873c16 / btrfs rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=256,subvol=/@ 0 0
# /dev/nvme0n1p8 LABEL=ARCH
UUID=95250e8a-5870-45df-a7b3-3b3ee8873c16 /home btrfs rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=257,subvol=/@home 0 0
# /dev/nvme0n1p8 LABEL=ARCH
UUID=95250e8a-5870-45df-a7b3-3b3ee8873c16 /tmp btrfs rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=258,subvol=/@tmp 0 0
# /dev/nvme0n1p8 LABEL=ARCH
UUID=95250e8a-5870-45df-a7b3-3b3ee8873c16 /var/cache btrfs rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=259,subvol=/@var-cache 0 0
# /dev/nvme0n1p8 LABEL=ARCH
UUID=95250e8a-5870-45df-a7b3-3b3ee8873c16 /var/log btrfs rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=260,subvol=/@var-log 0 0
# /dev/nvme0n1p8 LABEL=ARCH
UUID=95250e8a-5870-45df-a7b3-3b3ee8873c16 /var/tmp btrfs rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=261,subvol=/@var-tmp 0 0
# /dev/nvme0n1p8 LABEL=ARCH
UUID=95250e8a-5870-45df-a7b3-3b3ee8873c16 /.snapshots btrfs rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=262,subvol=/@snapper-root 0 0
# /dev/nvme0n1p8 LABEL=ARCH
UUID=95250e8a-5870-45df-a7b3-3b3ee8873c16 /home/.snapshots btrfs rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=263,subvol=/@snapper-home 0 0
# /dev/nvme0n1p8 LABEL=ARCH
UUID=95250e8a-5870-45df-a7b3-3b3ee8873c16 /root/.refind-btrfs btrfs rw,noatime,compress-force=zstd:2,ssd,space_cache=v2,commit=15,subvolid=264,subvol=/@rw-snapshots 0 0
# /dev/nvme0n1p3
UUID=8A38-56EE /efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 2
# /dev/nvme0n1p7 LABEL=SWAP
UUID=1c0ba137-3fea-4dac-afb4-3a3b01bbdfad none swap defaults 0 0
What you can try is adding the "subvolid=5" to the mount options in all of the fstab files:
rw,relatime,compress=zstd,ssd,space_cache,subvolid=5
If my assumption is wrong, please check the output of:
btrfs subvolume show /
and modify the mount options as such:
rw,relatime,compress=zstd,ssd,space_cache,subvolid=<Subvolume ID>,subvol=/@
where "Subvolume ID" is returned by the "subvolume show" command.
The alternative is perhaps executing genfstab but just make sure to clean up duplicate "subvol" mount options if any appear.
You're going to have to make the Snapper's snapshots writable before changing their fstab, obviously. Every snapshot taken after you've made the changes to the @ subvolume's fstab file should be fine.
Check this comment from a previous issue, it might help you.
I'm not sure if your assumption is correct or not. But i think that it's wrong because my snapshots are also a subvolume. The Subvolume is after all not 5.
@
Name: @
UUID: b8fa7706-9f46-0348-844a-8ce0b8a31013
Parent UUID: -
Received UUID: -
Creation time: 2021-01-16 10:01:32 +0000
Subvolume ID: 256
Generation: 53202
Gen at creation: 7
Parent ID: 5
Top level ID: 5
Flags: -
Snapshot(s):
@/.snapshots/1/snapshot
@/.snapshots/2/snapshot
@/.snapshots/3/snapshot
@/.snapshots/4/snapshot
@/.snapshots/5/snapshot
@/.snapshots/6/snapshot
@/.snapshots/7/snapshot
Quota group: 0/256
Limit referenced: -
Limit exclusive: -
Usage referenced: 530.68GiB
Usage exclusive: 2.04GiB
So i just append that to my /etc/fstab?
So i added those to /etc/fstab:
UUID=21b2c6c8-472c-43a7-9957-6feb23022325 / btrfs rw,relatime,compress=zstd,ssd,space_cache,subvolid=256,subvol=/@ 0 0
And it still booted! But it still prints the same error :(
Did you amend the fstab file in all of the snapshots, including the one created in /root/.refind-btrfs? Other than that, I really don't see why it wouldn't match the mount options.
EDIT: Each snapshot created after your changes will contain the correct / mount point definition in its fstab file but not those that were created beforehand, obviously.
I removed all my snapshots, and r/w ones this tool made, generated a new snapshot and now it works. I was too lazy to do that 8 times 😄
I removed all my snapshots, and r/w ones this tool made, generated a new snapshot and now it works. I was too lazy to do that 8 times smile
Great, I'm glad you persuaded it to work.
I've added the "volume" option trimming but I didn't push that yet because I have some other local changes on master. Also, I should validate the snapshot's fstab file prior to modifying it. I have a few other validations that I'm trying to implement right now. All in good time, I suppose.
I have my EFI mounted, a manual boot stanza set up (proven by the fact that i can consistently boot from it)
And yet, it prints this error. Based on the output, it looks like it even found my stanza! How else would it know that it's
@
?Any help would be appreciated!