[Bug 1830110] Re: patch for finding zfs, solves: cryptsetup: WARNING: Couldn't determine root device
Heitor Alves de Siqueira
1830110 at bugs.launchpad.net
Tue Mar 11 13:21:11 UTC 2025
Hi Andreas,
sure thing, I've added both of these scenarios to the SRU template in
the description! Both of these are easily available from the installer,
so it should be fairly straightforward to validate. I've done it for the
versions in my PPA already, and everything is working as expected. The
only caveat for the non-LUKS scenario is that we need to manually
install cryptsetup, and the initramfs scripts won't run (as we have no
encrypted devices).
# ZFS only
halves at ubuntu20:~$ apt policy cryptsetup
cryptsetup:
Installed: 2:2.2.2-3ubuntu2.5
Candidate: 2:2.2.2-3ubuntu2.5
Version table:
*** 2:2.2.2-3ubuntu2.5 500
500 http://ppa.launchpad.net/halves/2054390-test/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
2:2.2.2-3ubuntu2.4 500
500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
2:2.2.2-3ubuntu2 500
500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages
halves at ubuntu20:~$ zpool status
pool: bpool
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
bpool ONLINE 0 0 0
8cda55e1-06 ONLINE 0 0 0
errors: No known data errors
pool: rpool
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
8cda55e1-07 ONLINE 0 0 0
errors: No known data errors
halves at ubuntu20:~$ lsblk /dev/vda
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 25G 0 disk
├─vda1 252:1 0 512M 0 part /boot/efi
├─vda2 252:2 0 1K 0 part
├─vda5 252:5 0 1.1G 0 part [SWAP]
├─vda6 252:6 0 1.2G 0 part
└─vda7 252:7 0 22.1G 0 part
# LUKS only
halves at ubuntu20:~$ lsblk /dev/vda
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 25G 0 disk
├─vda1 252:1 0 512M 0 part /boot/efi
├─vda2 252:2 0 1K 0 part
├─vda5 252:5 0 1.4G 0 part /boot
└─vda6 252:6 0 23.1G 0 part
└─vda6_crypt 253:0 0 23.1G 0 crypt
├─vgubuntu-root 253:1 0 22G 0 lvm /
└─vgubuntu-swap_1 253:2 0 976M 0 lvm [SWAP]
halves at ubuntu20:~$ apt policy cryptsetup
cryptsetup:
Installed: 2:2.2.2-3ubuntu2.5
Candidate: 2:2.2.2-3ubuntu2.5
Version table:
*** 2:2.2.2-3ubuntu2.5 500
500 http://ppa.launchpad.net/halves/2054390-test/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
2:2.2.2-3ubuntu2.4 500
500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
2:2.2.2-3ubuntu2 500
500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages
** Description changed:
[ Impact ]
When updating the initramfs, error messages will be displayed:
cryptsetup: ERROR: Couldn't resolve device rpool/ROOT/ubuntu_fvdajm
cryptsetup: WARNING: Couldn't determine root device
This is due to ZFS not having MAJ/MIN device numbers, which causes issues with
cryptsetup detecting the root FS.
[ Test Plan ]
The best way I've found to test this is to setup the LUKS devices from an
existing Ubuntu installation (or e.g. the Desktop Live ISO), and debootstrap a
focal system on it. This seems to replicate a new install very closely, and the
issue can be trivially reproduced by updating the initramfs:
root at ubuntu20.04:/# lsblk
vda 252:0 0 25G 0 disk
├─vda1 252:1 0 512M 0 part /boot/efi
├─vda2 252:2 0 500M 0 part
├─vda3 252:3 0 2G 0 part
└─vda4 252:4 0 22G 0 part
- └─luks1 253:0 0 22G 0 crypt
+ └─luks1 253:0 0 22G 0 crypt
root at ubuntu20.04:/# zpool status -P rpool
- pool: rpool
- state: ONLINE
+ pool: rpool
+ state: ONLINE
status: ...
action: ...
config:
- NAME STATE READ WRITE CKSUM
- rpool ONLINE 0 0 0
- /dev/mapper/luks1 ONLINE 0 0 0
+ NAME STATE READ WRITE CKSUM
+ rpool ONLINE 0 0 0
+ /dev/mapper/luks1 ONLINE 0 0 0
root at ubuntu20.04:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.4.0-205-generic
cryptsetup: ERROR: Couldn't resolve device rpool/ROOT/ubuntu_fvdajm
cryptsetup: WARNING: Couldn't determine root device
After backporting the ZFS patch for initramfs-tools/hooks/cryptroot from newer
Ubuntu releases:
root at ubuntu20.04:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.4.0-205-generic
root at ubuntu20.04:/#
+ In summary, the following scenarios should be covered by testing to ensure no regressions have been introduced:
+ - ZFS on top of LUKS (manual setup according to the instructions above)
+ - regular encrypted LUKS setup (i.e. LVM+luks from the installer)
+ - regular ZFS (available as advanced option in the installer)
+
[ Where Problems Could Occur ]
Potential issues would likely show up during initramfs creation for systems that
have LUKS devices, as that's where we have changes.
We now return an empty device number for ZFS, and ignore devices that don't have
a devno. This could cause issues with other filesystem types that also don't
have device number information, and potentially expose other issues with
LUKS-encrypted ZFS partitions.
-
[ Other Information ]
The fix has been cherry-picked from mwhudson's cryptsetup merge, to be aligned
with other Ubuntu releases (specifically, commit 8a583307a038 [0]). Focal is the
only release still missing this patch, so it's the only one we need to target.
[0]
https://git.launchpad.net/~mwhudson/ubuntu/+source/cryptsetup/commit/?id=8a583307a0386febc8d29c0c592d5d312b176e34
--
Hi there,
There is a missing functionality in the following file:
/usr/share/initramfs-tools/hooks/cryptroot
resulting in the following error message:
cryptsetup: ERROR: Couldn't resolve device <zfs-mountpoint>
cryptsetup: WARNING: Couldn't determine root device
under the following condition:
update-initramfs -c -k all
when:
trying to resolve for encrypted zfs devices
so here is a patch to solve it, based off
Package: cryptsetup-initramfs
Version: 2:2.1.0-1ubuntu1
diff -Naur a/usr/share/initramfs-tools/hooks/cryptroot b/usr/share/initramfs-tools/hooks/cryptroot
--- a/usr/share/initramfs-tools/hooks/cryptroot 2019-05-22 18:34:12.116097472 +0100
+++ b/usr/share/initramfs-tools/hooks/cryptroot 2019-05-22 20:13:02.159138688 +0100
@@ -72,19 +72,28 @@
# take the last mountpoint if used several times (shadowed)
unset -v devnos
spec="$(printf '%b' "$spec")"
- resolve_device "$spec" || continue # resolve_device() already warns on error
fstype="$(printf '%b' "$fstype")"
- if [ "$fstype" = "btrfs" ]; then
- # btrfs can span over multiple devices
- if uuid="$(device_uuid "$DEV")"; then
- for dev in "/sys/fs/$fstype/$uuid/devices"/*/dev; do
- devnos="${devnos:+$devnos }$(cat "$dev")"
- done
- else
- cryptsetup_message "ERROR: $spec: Couldn't determine UUID"
+ if [ "$fstype" = "zfs" ]; then
+ # zfs can span over multiple devices
+ for dev in $(zpool status -L -P | grep -o "/dev/[^ ]*"); do
+ MAJ="$(printf "%d\n" 0x$(stat -L -c"%t" -- "$dev"))"
+ MIN="$(printf "%d\n" 0x$(stat -L -c"%T" -- "$dev"))"
+ devnos="${devnos:+$devnos }$MAJ:$MIN"
+ done
+ else
+ resolve_device "$spec" || continue # resolve_device() already warns on error
+ if [ "$fstype" = "btrfs" ]; then
+ # btrfs can span over multiple devices
+ if uuid="$(device_uuid "$DEV")"; then
+ for dev in "/sys/fs/$fstype/$uuid/devices"/*/dev; do
+ devnos="${devnos:+$devnos }$(cat "$dev")"
+ done
+ else
+ cryptsetup_message "ERROR: $spec: Couldn't determine UUID"
+ fi
+ elif [ -n "$fstype" ]; then
+ devnos="$MAJ:$MIN"
fi
- elif [ -n "$fstype" ]; then
- devnos="$MAJ:$MIN"
fi
fi
done </proc/mounts
Which works, I have tested it. However by solving this error message,
the script can now continue further. And it then prints out some new
messages that should not be there either. Unfortunately I could not
track down the source of those subsequent warnings!
They say:
# update-initramfs -c -k all
update-initramfs: Generating /boot/initrd.img-5.0.0-15-generic
cryptsetup: WARNING: crypt_rpool1: ignoring unknown option 'nofail'
cryptsetup: WARNING: crypt_rpool1: ignoring unknown option
'x-systemd.device-timeout'
So clearly there is something which does not recognize the fstab
mounting options of:
'nofail'
and
'x-systemd.device-timeout'
However those options are indeed valid, and were found to have a working
effect. They were tested also. So the warning is something else,
somewhere else. And I cannot grep it. Cannot google it. Nothing
happening in strace. It is pretty mysterious, as to where it is come
from. Mysterious messages!
Anyhow please take the first patch if you can. Or use those lines to
make your own version to improve as you please.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cryptsetup in Ubuntu.
https://bugs.launchpad.net/bugs/1830110
Title:
patch for finding zfs, solves: cryptsetup: WARNING: Couldn't
determine root device
Status in cryptsetup package in Ubuntu:
Fix Released
Status in cryptsetup source package in Focal:
In Progress
Status in cryptsetup package in Debian:
New
Bug description:
[ Impact ]
When updating the initramfs, error messages will be displayed:
cryptsetup: ERROR: Couldn't resolve device rpool/ROOT/ubuntu_fvdajm
cryptsetup: WARNING: Couldn't determine root device
This is due to ZFS not having MAJ/MIN device numbers, which causes issues with
cryptsetup detecting the root FS.
[ Test Plan ]
The best way I've found to test this is to setup the LUKS devices from an
existing Ubuntu installation (or e.g. the Desktop Live ISO), and debootstrap a
focal system on it. This seems to replicate a new install very closely, and the
issue can be trivially reproduced by updating the initramfs:
root at ubuntu20.04:/# lsblk
vda 252:0 0 25G 0 disk
├─vda1 252:1 0 512M 0 part /boot/efi
├─vda2 252:2 0 500M 0 part
├─vda3 252:3 0 2G 0 part
└─vda4 252:4 0 22G 0 part
└─luks1 253:0 0 22G 0 crypt
root at ubuntu20.04:/# zpool status -P rpool
pool: rpool
state: ONLINE
status: ...
action: ...
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
/dev/mapper/luks1 ONLINE 0 0 0
root at ubuntu20.04:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.4.0-205-generic
cryptsetup: ERROR: Couldn't resolve device rpool/ROOT/ubuntu_fvdajm
cryptsetup: WARNING: Couldn't determine root device
After backporting the ZFS patch for initramfs-tools/hooks/cryptroot from newer
Ubuntu releases:
root at ubuntu20.04:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.4.0-205-generic
root at ubuntu20.04:/#
In summary, the following scenarios should be covered by testing to ensure no regressions have been introduced:
- ZFS on top of LUKS (manual setup according to the instructions above)
- regular encrypted LUKS setup (i.e. LVM+luks from the installer)
- regular ZFS (available as advanced option in the installer)
[ Where Problems Could Occur ]
Potential issues would likely show up during initramfs creation for systems that
have LUKS devices, as that's where we have changes.
We now return an empty device number for ZFS, and ignore devices that don't have
a devno. This could cause issues with other filesystem types that also don't
have device number information, and potentially expose other issues with
LUKS-encrypted ZFS partitions.
[ Other Information ]
The fix has been cherry-picked from mwhudson's cryptsetup merge, to be aligned
with other Ubuntu releases (specifically, commit 8a583307a038 [0]). Focal is the
only release still missing this patch, so it's the only one we need to target.
[0]
https://git.launchpad.net/~mwhudson/ubuntu/+source/cryptsetup/commit/?id=8a583307a0386febc8d29c0c592d5d312b176e34
--
Hi there,
There is a missing functionality in the following file:
/usr/share/initramfs-tools/hooks/cryptroot
resulting in the following error message:
cryptsetup: ERROR: Couldn't resolve device <zfs-mountpoint>
cryptsetup: WARNING: Couldn't determine root device
under the following condition:
update-initramfs -c -k all
when:
trying to resolve for encrypted zfs devices
so here is a patch to solve it, based off
Package: cryptsetup-initramfs
Version: 2:2.1.0-1ubuntu1
diff -Naur a/usr/share/initramfs-tools/hooks/cryptroot b/usr/share/initramfs-tools/hooks/cryptroot
--- a/usr/share/initramfs-tools/hooks/cryptroot 2019-05-22 18:34:12.116097472 +0100
+++ b/usr/share/initramfs-tools/hooks/cryptroot 2019-05-22 20:13:02.159138688 +0100
@@ -72,19 +72,28 @@
# take the last mountpoint if used several times (shadowed)
unset -v devnos
spec="$(printf '%b' "$spec")"
- resolve_device "$spec" || continue # resolve_device() already warns on error
fstype="$(printf '%b' "$fstype")"
- if [ "$fstype" = "btrfs" ]; then
- # btrfs can span over multiple devices
- if uuid="$(device_uuid "$DEV")"; then
- for dev in "/sys/fs/$fstype/$uuid/devices"/*/dev; do
- devnos="${devnos:+$devnos }$(cat "$dev")"
- done
- else
- cryptsetup_message "ERROR: $spec: Couldn't determine UUID"
+ if [ "$fstype" = "zfs" ]; then
+ # zfs can span over multiple devices
+ for dev in $(zpool status -L -P | grep -o "/dev/[^ ]*"); do
+ MAJ="$(printf "%d\n" 0x$(stat -L -c"%t" -- "$dev"))"
+ MIN="$(printf "%d\n" 0x$(stat -L -c"%T" -- "$dev"))"
+ devnos="${devnos:+$devnos }$MAJ:$MIN"
+ done
+ else
+ resolve_device "$spec" || continue # resolve_device() already warns on error
+ if [ "$fstype" = "btrfs" ]; then
+ # btrfs can span over multiple devices
+ if uuid="$(device_uuid "$DEV")"; then
+ for dev in "/sys/fs/$fstype/$uuid/devices"/*/dev; do
+ devnos="${devnos:+$devnos }$(cat "$dev")"
+ done
+ else
+ cryptsetup_message "ERROR: $spec: Couldn't determine UUID"
+ fi
+ elif [ -n "$fstype" ]; then
+ devnos="$MAJ:$MIN"
fi
- elif [ -n "$fstype" ]; then
- devnos="$MAJ:$MIN"
fi
fi
done </proc/mounts
Which works, I have tested it. However by solving this error message,
the script can now continue further. And it then prints out some new
messages that should not be there either. Unfortunately I could not
track down the source of those subsequent warnings!
They say:
# update-initramfs -c -k all
update-initramfs: Generating /boot/initrd.img-5.0.0-15-generic
cryptsetup: WARNING: crypt_rpool1: ignoring unknown option 'nofail'
cryptsetup: WARNING: crypt_rpool1: ignoring unknown option
'x-systemd.device-timeout'
So clearly there is something which does not recognize the fstab
mounting options of:
'nofail'
and
'x-systemd.device-timeout'
However those options are indeed valid, and were found to have a
working effect. They were tested also. So the warning is something
else, somewhere else. And I cannot grep it. Cannot google it. Nothing
happening in strace. It is pretty mysterious, as to where it is come
from. Mysterious messages!
Anyhow please take the first patch if you can. Or use those lines to
make your own version to improve as you please.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1830110/+subscriptions
More information about the foundations-bugs
mailing list