Closed Th3Whit3Wolf closed 3 years ago
I think I might have found something. I ran sudo refind-btrfs
and I got this
sudo refind-btrfs
Initializing the block devices using lsblk.
Initializing the physical partition table for device '/dev/zram0' using lsblk.
Initializing the live partition table for device '/dev/zram0' using findmnt.
Initializing the physical partition table for device '/dev/zram1' using lsblk.
Initializing the live partition table for device '/dev/zram1' using findmnt.
Initializing the physical partition table for device '/dev/zram2' using lsblk.
Initializing the live partition table for device '/dev/zram2' using findmnt.
Initializing the physical partition table for device '/dev/zram3' using lsblk.
Initializing the live partition table for device '/dev/zram3' using findmnt.
Initializing the physical partition table for device '/dev/zram4' using lsblk.
Initializing the live partition table for device '/dev/zram4' using findmnt.
Initializing the physical partition table for device '/dev/zram5' using lsblk.
Initializing the live partition table for device '/dev/zram5' using findmnt.
Initializing the physical partition table for device '/dev/zram6' using lsblk.
Initializing the live partition table for device '/dev/zram6' using findmnt.
Initializing the physical partition table for device '/dev/zram7' using lsblk.
Initializing the live partition table for device '/dev/zram7' using findmnt.
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 '/boot' on '/dev/nvme0n1p1'.
ERROR (refind_btrfs.state_management.model/model.py/check_block_devices): Could not find the root partition!
I think the issue is either that I use LUKS encryption or with how mountpoints are detected. Here is my lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
zram0 253:0 0 483.9M 0 disk [SWAP]
zram1 253:1 0 483.9M 0 disk [SWAP]
zram2 253:2 0 483.9M 0 disk [SWAP]
zram3 253:3 0 483.9M 0 disk [SWAP]
zram4 253:4 0 483.9M 0 disk [SWAP]
zram5 253:5 0 483.9M 0 disk [SWAP]
zram6 253:6 0 483.9M 0 disk [SWAP]
zram7 253:7 0 483.9M 0 disk [SWAP]
nvme0n1 259:0 0 953.9G 0 disk
├─nvme0n1p1 259:1 0 2G 0 part /boot
└─nvme0n1p2 259:2 0 951.9G 0 part
└─crypt 254:0 0 951.9G 0 crypt /btrfs
Please paste the output of:
lsblk --nodeps --merge --paths --output name,type,maj:min
and
lsblk --paths --tree --include 254,259 --output ptuuid,pttype,partuuid,parttype,partlabel,uuid,name,fstype,label,mountpoint
I'll have to somehow filter out these zram devices, also. As I can see in your fstab, you keep the kernels directly on the ESP - I guess because of the encryption? The problem I see in your lsblk output is that there is indeed no / mount point shown.
Also, the "refind_config" option mustn't be an absolute path - just the filename is enough. Some people don't name it "refind.conf" (the default name) so it's an option. This is would've also been a problem in your case but the tool fails before this step.
Please paste the output of:
lsblk --nodeps --merge --paths --output name,type,maj:min
NAME TYPE MAJ:MIN
/dev/zram0 disk 253:0
/dev/zram1 disk 253:1
/dev/zram2 disk 253:2
/dev/zram3 disk 253:3
/dev/zram4 disk 253:4
/dev/zram5 disk 253:5
/dev/zram6 disk 253:6
/dev/zram7 disk 253:7
/dev/nvme0n1 disk 259:0
and
lsblk --paths --tree --include 254,259 --output ptuuid,pttype,partuuid,parttype,partlabel,uuid,name,fstype,label,mountpoint
PTUUID PTTYPE PARTUUID PARTTYPE PARTLABEL UUID NAME FSTYPE LABEL MOUNTPOINT
bbc0d3f9-c8c8-9c46-b5f7-378e6585fbf3 gpt /dev/nvme0n1
bbc0d3f9-c8c8-9c46-b5f7-378e6585fbf3 gpt 632ce15f-1de8-484d-a1d4-eebbac6888c4 c12a7328-f81f-11d2-ba4b-00a0c93ec93b EE72-C5B0 ├─/dev/nvme0n1p1 vfat EFI /boot
bbc0d3f9-c8c8-9c46-b5f7-378e6585fbf3 gpt 90538cbd-a12a-c44b-a294-b1a99a8e03f6 0fc63daf-8483-4772-8e79-3d69d8477de4 e4dca43a-21bd-4598-88fc-371dd20695a4 └─/dev/nvme0n1p2 crypto_LUKS
a20b6dd5-3ba0-456a-9469-cad0a225a3ab └─/dev/mapper/crypt btrfs Arch /btrfs
I'll have to somehow filter out these zram devices, also. As I can see in your fstab, you keep the kernels directly on the ESP - I guess because of the encryption? The problem I see in your lsblk output is that there is indeed no / mount point shown.
Correct, otherwise refind wouldn't be able to read them. What can I do to fix this?
Also, the "refind_config" option mustn't be an absolute path - just the filename is enough. Some people don't name it "refind.conf" (the default name) so it's an option. This is would've also been a problem in your case but the tool fails before this step.
I'll change that.
I've never used dm-crypt with LUKS for encrypting a filesystem so I really don't know why there is no / mount point shown in your case.
Having the kernels on a separate /boot partition shouldn't be a problem at all, the lack of a / mount point in the output is. What you could do though is remove the default Btrfs subvolume (subvolid = 5) from fstab altogether as you don't really need it (it is, I believe, implicitly auto-mounted). That would be the last line in your fstab. I don't have it and everything works just fine.
Also, please post the output of (before and after modifying the fstab):
findmnt --mtab --real --nofsroot --output PARTUUID,PARTLABEL,UUID,SOURCE,FSTYPE,LABEL,TARGET,OPTIONS
Basically, lsblk is used to fetch block devices and identify the ESP while findmnt is used to figure out / and /boot (if it exists) because lsblk does not handle Btrfs mounts correctly.
Before
PARTUUID PARTLABEL UUID SOURCE FSTYPE LABEL TARGET OPTIONS
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch / rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=256,subvol=/@
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /.snapshots rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=261,subvol=/@snapshots
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /btrfs rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=5,subvol=/
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /srv rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=260,subvol=/@srv
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /home rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=257,subvol=/@home
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /var/abs rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=258,subvol=/@abs
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /var/cache rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=263,subvol=/@log
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /var/log rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=264,subvol=/@cache
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /var/tmp rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=259,subvol=/@tmp
632ce15f-1de8-484d-a1d4-eebbac6888c4 EE72-C5B0 /dev/nvme0n1p1 vfat EFI /boot rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
portal fuse.portal /run/user/1000/doc rw,nosuid,nodev,relatime,user_id=1000,group_id=985
After
PARTUUID PARTLABEL UUID SOURCE FSTYPE LABEL TARGET OPTIONS
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch / rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=256,subvol=/@
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /.snapshots rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=261,subvol=/@snapshots
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /home rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=257,subvol=/@home
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /srv rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=260,subvol=/@srv
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /var/abs rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=258,subvol=/@abs
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /var/cache rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=263,subvol=/@log
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /var/log rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=264,subvol=/@cache
a20b6dd5-3ba0-456a-9469-cad0a225a3ab /dev/mapper/crypt btrfs Arch /var/tmp rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=259,subvol=/@tmp
632ce15f-1de8-484d-a1d4-eebbac6888c4 EE72-C5B0 /dev/nvme0n1p1 vfat EFI /boot rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
portal fuse.portal /run/user/1000/doc rw,nosuid,nodev,relatime,user_id=1000,group_id=985
When running lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
zram0 253:0 0 483.9M 0 disk [SWAP]
zram1 253:1 0 483.9M 0 disk [SWAP]
zram2 253:2 0 483.9M 0 disk [SWAP]
zram3 253:3 0 483.9M 0 disk [SWAP]
zram4 253:4 0 483.9M 0 disk [SWAP]
zram5 253:5 0 483.9M 0 disk [SWAP]
zram6 253:6 0 483.9M 0 disk [SWAP]
zram7 253:7 0 483.9M 0 disk [SWAP]
nvme0n1 259:0 0 953.9G 0 disk
├─nvme0n1p1 259:1 0 2G 0 part /boot
└─nvme0n1p2 259:2 0 951.9G 0 part
└─crypt 254:0 0 951.9G 0 crypt /var/tmp
I think I see what the problem is now. The /dev/mapper/crypt device is ignored by the first lsblk command which is due to the "nodeps" option, I believe. This means that the relevant findmnt output is ignored as I use device paths for filtering out findmnt's output. Run this:
lsblk --merge --paths --output name,type,maj:min
and this:
lsblk /dev/nvme0n1 --paths --tree --output ptuuid,pttype,partuuid,parttype,partlabel,uuid,name,fstype,label,mountpoint
I use "nodeps" because lsblk then returns only the root devices which is what I've needed.
This stackoverflow post lead me to look for root in /proc/mount
.
I can reliably get /
using this shell command
cat /proc/mounts | awk '$2 == "/" {print $0}'
It checks the text of the seconds column and if it is equal to /
then it prints that line. I'm not sure if this is something that would be helpful or not.
This stackoverflow post lead me to look for root in
/proc/mount
.I can reliably get / using this shell command
cat /proc/mounts | awk '$2 == "/" {print $0}'
It checks the text of the seconds column and if it is equal to
/
then it prints that line. I'm not sure if this is something that would be helpful or not.
I think I have a potential solution in mind but I'm kind of working in the dark here, oh well. Please post the output of those last two commands so that I have something to work with.
You can get / by "findmnt /" which is what I might end up using, after all.
Do you mean these
I think I see what the problem is now. The /dev/mapper/crypt device is ignored by the first lsblk command which is due to the "nodeps" option, I believe. This means that the relevant findmnt output is ignored as I use device paths for filtering out findmnt's output. Run this:
lsblk --merge --paths --output name,type,maj:min
lsblk --merge --paths --output name,type,maj:min
NAME TYPE MAJ:MIN
/dev/zram0 disk 253:0
/dev/zram1 disk 253:1
/dev/zram2 disk 253:2
/dev/zram3 disk 253:3
/dev/zram4 disk 253:4
/dev/zram5 disk 253:5
/dev/zram6 disk 253:6
/dev/zram7 disk 253:7
/dev/nvme0n1 disk 259:0
├─/dev/nvme0n1p1 part 259:1
└─/dev/nvme0n1p2 part 259:2
└─/dev/mapper/crypt crypt 254:0
and this:
lsblk /dev/nvme0n1 --paths --tree --output ptuuid,pttype,partuuid,parttype,partlabel,uuid,name,fstype,label,mountpoint
PTUUID PTTYPE PARTUUID PARTTYPE PARTLABEL UUID NAME FSTYPE LABEL MOUNTPOINT bbc0d3f9-c8c8-9c46-b5f7-378e6585fbf3 gpt /dev/nvme0n1 bbc0d3f9-c8c8-9c46-b5f7-378e6585fbf3 gpt 632ce15f-1de8-484d-a1d4-eebbac6888c4 c12a7328-f81f-11d2-ba4b-00a0c93ec93b EE72-C5B0 ├─/dev/nvme0n1p1 vfat EFI /boot bbc0d3f9-c8c8-9c46-b5f7-378e6585fbf3 gpt 90538cbd-a12a-c44b-a294-b1a99a8e03f6 0fc63daf-8483-4772-8e79-3d69d8477de4 e4dca43a-21bd-4598-88fc-371dd20695a4 └─/dev/nvme0n1p2 crypto_LUKS a20b6dd5-3ba0-456a-9469-cad0a225a3ab └─/dev/mapper/crypt btrfs Arch /var/tmp
I use "nodeps" because lsblk then returns only the root devices which is what I've needed.
findmnt /
returns
TARGET SOURCE FSTYPE OPTIONS
/ /dev/mapper/crypt[/@] btrfs rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=256,subvol=/@
Do you mean these
No, these ones.
Sorry I don't know how I missed those.
Thanks, that's helpful. If you could just repeat those last two commands with the "--json" option (add it after the command name) so that I can see how the JSON output is structured in this case.
The alternative is "findmnt /" altough it isn't really compatible with the way I've modeled the device hierarchy on my end...
lsblk --merge --paths --output name,type,maj:min --json
returns
{
"blockdevices": [
{"name":"/dev/zram0", "type":"disk", "maj:min":"253:0"},
{"name":"/dev/zram1", "type":"disk", "maj:min":"253:1"},
{"name":"/dev/zram2", "type":"disk", "maj:min":"253:2"},
{"name":"/dev/zram3", "type":"disk", "maj:min":"253:3"},
{"name":"/dev/zram4", "type":"disk", "maj:min":"253:4"},
{"name":"/dev/zram5", "type":"disk", "maj:min":"253:5"},
{"name":"/dev/zram6", "type":"disk", "maj:min":"253:6"},
{"name":"/dev/zram7", "type":"disk", "maj:min":"253:7"},
{"name":"/dev/nvme0n1", "type":"disk", "maj:min":"259:0",
"children": [
{"name":"/dev/nvme0n1p1", "type":"part", "maj:min":"259:1"},
{"name":"/dev/nvme0n1p2", "type":"part", "maj:min":"259:2",
"children": [
{"name":"/dev/mapper/crypt", "type":"crypt", "maj:min":"254:0"}
]
}
]
}
]
}
lsblk /dev/nvme0n1 --paths --tree --output ptuuid,pttype,partuuid,parttype,partlabel,uuid,name,fstype,label,mountpoint --json
returns
{
"blockdevices": [
{"ptuuid":"bbc0d3f9-c8c8-9c46-b5f7-378e6585fbf3", "pttype":"gpt", "partuuid":null, "parttype":null, "partlabel":null, "uuid":null, "name":"/dev/nvme0n1", "fstype":null, "label":null, "mountpoint":null,
"children": [
{"ptuuid":"bbc0d3f9-c8c8-9c46-b5f7-378e6585fbf3", "pttype":"gpt", "partuuid":"632ce15f-1de8-484d-a1d4-eebbac6888c4", "parttype":"c12a7328-f81f-11d2-ba4b-00a0c93ec93b", "partlabel":null, "uuid":"EE72-C5B0", "name":"/dev/nvme0n1p1", "fstype":"vfat", "label":"EFI", "mountpoint":"/boot"},
{"ptuuid":"bbc0d3f9-c8c8-9c46-b5f7-378e6585fbf3", "pttype":"gpt", "partuuid":"90538cbd-a12a-c44b-a294-b1a99a8e03f6", "parttype":"0fc63daf-8483-4772-8e79-3d69d8477de4", "partlabel":null, "uuid":"e4dca43a-21bd-4598-88fc-371dd20695a4", "name":"/dev/nvme0n1p2", "fstype":"crypto_LUKS", "label":null, "mountpoint":null,
"children": [
{"ptuuid":null, "pttype":null, "partuuid":null, "parttype":null, "partlabel":null, "uuid":"a20b6dd5-3ba0-456a-9469-cad0a225a3ab", "name":"/dev/mapper/crypt", "fstype":"btrfs", "label":"Arch", "mountpoint":"/var/tmp"}
]
}
]
}
]
}
Ok, I have something to work with now (mock the output). One last command and that should be it:
findmnt --json --mtab --real --nofsroot --output PARTUUID,PARTLABEL,UUID,SOURCE,FSTYPE,LABEL,TARGET,OPTIONS
I'll try to come up with a solution as soon as I can and notify you here.
Ok, I have something to work with now (mock the output). One last command and that should be it:
findmnt --json --mtab --real --nofsroot --output PARTUUID,PARTLABEL,UUID,SOURCE,FSTYPE,LABEL,TARGET,OPTIONS
{
"filesystems": [
{"partuuid":null, "partlabel":null, "uuid":"a20b6dd5-3ba0-456a-9469-cad0a225a3ab", "source":"/dev/mapper/crypt", "fstype":"btrfs", "label":"Arch", "target":"/", "options":"rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=256,subvol=/@"},
{"partuuid":null, "partlabel":null, "uuid":"a20b6dd5-3ba0-456a-9469-cad0a225a3ab", "source":"/dev/mapper/crypt", "fstype":"btrfs", "label":"Arch", "target":"/.snapshots", "options":"rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=261,subvol=/@snapshots"},
{"partuuid":null, "partlabel":null, "uuid":"a20b6dd5-3ba0-456a-9469-cad0a225a3ab", "source":"/dev/mapper/crypt", "fstype":"btrfs", "label":"Arch", "target":"/home", "options":"rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=257,subvol=/@home"},
{"partuuid":null, "partlabel":null, "uuid":"a20b6dd5-3ba0-456a-9469-cad0a225a3ab", "source":"/dev/mapper/crypt", "fstype":"btrfs", "label":"Arch", "target":"/srv", "options":"rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=260,subvol=/@srv"},
{"partuuid":null, "partlabel":null, "uuid":"a20b6dd5-3ba0-456a-9469-cad0a225a3ab", "source":"/dev/mapper/crypt", "fstype":"btrfs", "label":"Arch", "target":"/var/abs", "options":"rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=258,subvol=/@abs"},
{"partuuid":null, "partlabel":null, "uuid":"a20b6dd5-3ba0-456a-9469-cad0a225a3ab", "source":"/dev/mapper/crypt", "fstype":"btrfs", "label":"Arch", "target":"/var/cache", "options":"rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=263,subvol=/@log"},
{"partuuid":null, "partlabel":null, "uuid":"a20b6dd5-3ba0-456a-9469-cad0a225a3ab", "source":"/dev/mapper/crypt", "fstype":"btrfs", "label":"Arch", "target":"/var/log", "options":"rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=264,subvol=/@cache"},
{"partuuid":null, "partlabel":null, "uuid":"a20b6dd5-3ba0-456a-9469-cad0a225a3ab", "source":"/dev/mapper/crypt", "fstype":"btrfs", "label":"Arch", "target":"/var/tmp", "options":"rw,noatime,compress-force=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=259,subvol=/@tmp"},
{"partuuid":"632ce15f-1de8-484d-a1d4-eebbac6888c4", "partlabel":null, "uuid":"EE72-C5B0", "source":"/dev/nvme0n1p1", "fstype":"vfat", "label":"EFI", "target":"/boot", "options":"rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro"},
{"partuuid":null, "partlabel":null, "uuid":null, "source":"portal", "fstype":"fuse.portal", "label":null, "target":"/run/user/1000/doc", "options":"rw,nosuid,nodev,relatime,user_id=1000,group_id=985"}
]
}
Ok then, I'll get it done today or tomorrow and report back here. In the meantime you could stop/disable the service because it will simply fail every time Snapper (which is what you're using, I think) takes a snapshot.
Also, are you sure the boot stanza you provided works? I don't think the volume "Arch Linux" is matched with anything on your system. Just put Arch (without the quotes - your filesystem label) there instead. Perhaps rEFInd is able to figure it out somehow as is although I'm not sure about that.
Ok then, I'll get it done today or tomorrow and report back here. In the meantime you could stop/disable the service because it will simply fail every time Snapper (which is what you're using, I think) takes a snapshot.
Will do, thanks for being so fast!
Also, are you sure the boot stanza you provided works? I don't think the volume "Arch Linux" is matched with anything on your system. Just put Arch (without the quotes - your filesystem label) there instead. Perhaps rEFInd is able to figure it out somehow as is although I'm not sure about that.
It does work and no it doesn't match anything. That volume name that is used in an example that arch ships. I'm pretty sure if refind can't find it just ignores it. It knows where EFIstub it launches from is and uses that disk.
It does work and no it doesn't match anything. That volume name that is used in an example that arch ships. I'm pretty sure if refind can't find it just ignores it. It knows where EFIstub it launches from is and uses that disk.
Well, once I've defined my own manual stanza I got duplicates because of rEFInd's auto-scanning feature and I've solved it with:
dont_scan_volumes "ARCH"
where "ARCH" is the filesystem label ("Arch" in your case).
I was asking this because my tool will fail to identify such a boot stanza as it's "volume" field does not match anything on the live system.
It does work and no it doesn't match anything. That volume name that is used in an example that arch ships. I'm pretty sure if refind can't find it just ignores it. It knows where EFIstub it launches from is and uses that disk.
Well, once I've defined my own manual stanza I got duplicates because of rEFInd's auto-scanning feature and I've solved it with:
dont_scan_volumes "ARCH"
where "ARCH" is the filesystem label ("Arch" in your case).
I was asking this because my tool will fail to identify such a boot stanza as it's "volume" field does not match anything on the live system.
Oh I see, I set
scanfor manual,external
Since I only have one OS on my laptop.
I'll correct it.
Ok, using your actual data as mock data on my machine I've managed to fix this issue and / should now be correctly identified on your system. Please upgrade the package and report back when it's convenient.
I expect further problems but make sure to open a new issue if/when these happen instead of posting in the current issue.
Initializing the block devices using lsblk.
Initializing the physical partition table for device '/dev/zram0' using lsblk.
Initializing the live partition table for device '/dev/zram0' using findmnt.
Initializing the physical partition table for device '/dev/zram1' using lsblk.
Initializing the live partition table for device '/dev/zram1' using findmnt.
Initializing the physical partition table for device '/dev/zram2' using lsblk.
Initializing the live partition table for device '/dev/zram2' using findmnt.
Initializing the physical partition table for device '/dev/zram3' using lsblk.
Initializing the live partition table for device '/dev/zram3' using findmnt.
Initializing the physical partition table for device '/dev/zram4' using lsblk.
Initializing the live partition table for device '/dev/zram4' using findmnt.
Initializing the physical partition table for device '/dev/zram5' using lsblk.
Initializing the live partition table for device '/dev/zram5' using findmnt.
Initializing the physical partition table for device '/dev/zram6' using lsblk.
Initializing the live partition table for device '/dev/zram6' using findmnt.
Initializing the physical partition table for device '/dev/zram7' using lsblk.
Initializing the live partition table for device '/dev/zram7' using findmnt.
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 '/boot' on '/dev/nvme0n1p1'.
Found the root partition on '/dev/mapper/crypt'.
Found a separate boot partition on '/dev/nvme0n1p1'.
Searching for snapshots of the '@' subvolume in the '/.snapshots' directory.
Found subvolume '@' mounted as the root partition.
Found 6 snapshots of the '@' subvolume.
Searching for the 'refind.conf' file on '/dev/nvme0n1p1'.
ERROR (refind_btrfs.state_management.model/model.py/check_refind_config): Could not find a boot stanza matched with the root partition!
menuentry "Arch Linux" {
icon /EFI/refind/themes/refind-dreary/icons/os_arch.png
volume "Arch"
loader /vmlinuz-linux
initrd /initramfs-linux.img
options "rd.luks.name=e4dca43a-21bd-4598-88fc-371dd20695a4=crypt root=/dev/mapper/crypt rootflags=subvol=@ rw quiet nmi_watchdog=0 kernel.unprivileged_userns_clone=0 net.core.bpf_jit_harden=2 apparmor=1 lsm=lockdown,yama,apparmor systemd.unified_cgroup_hierarchy=1 add_efi_memmap initrd=\amd-ucode.img"
submenuentry "Boot - terminal" {
add_options "systemd.unit=multi-user.target"
}
}
I expect further problems but make sure to open a new issue if/when these happen instead of posting in the current issue.
Sorry just read the last line, would you like me to close this issue before opening another one?
I expect further problems but make sure to open a new issue if/when these happen instead of posting in the current issue.
Sorry just read the last line, would you like me to close this issue before opening another one?
Sure, if / is identified then close it (it is, judging by the output) and open another one if it is unrelated to this issue. Actually, just remove the quotes from "Arch" (the "volume" field in the stanza) and try again. You don't need to reboot.
I'm not sure why it isn't working, I may have configured the
refind-btrfs.conf
but systemctl and journalctl seem to indicate its doing it's job.Here is my fstab
Here's my refind entry
Here's my
/etc/refind-btrfs.conf
Here is
systemctl status refind-btrfs
Here is
journalctl -u refind-btrfs -b
Nothing gets add to my refind.conf and
/root/.refind-btrfs/
does not exists.