[Bug 1830110] Re: patch for finding zfs, solves: cryptsetup: WARNING: Couldn't determine root device

Heitor Alves de Siqueira 1830110 at bugs.launchpad.net
Fri Apr 4 16:05:32 UTC 2025


I've tested and validated this on the scenarios mentioned in the bug description. The summary is below:
- ZFS only setup ✅
- LUKS only ✅
- ZFS on LUKS ✅

The first two scenarios are easily accessible from the default Ubuntu
Desktop Installer for Focal. For ZFS on LUKS, I followed the upstream
ZFS documentation [0] and deboostrapped focal on top of the disks from
the live installer.

I found no regressions, and the warning messages about resolving the ZFS
devices are gone. Below are full test logs for verification.

[0] https://openzfs.github.io/openzfs-docs/Getting%20Started/Ubuntu/Ubuntu%2020.04%20Root%20on%20ZFS.html
--

*** 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://us.archive.ubuntu.com/ubuntu focal-proposed/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
ubuntu 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://us.archive.ubuntu.com/ubuntu focal-proposed/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
ubuntu 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]

root at ubuntu20:/home/ubuntu# update-initramfs -c -k all
update-initramfs: Generating /boot/initrd.img-5.15.0-136-generic
I: The initramfs will attempt to resume from /dev/dm-2
I: (/dev/mapper/vgubuntu-swap_1)
I: Set the RESUME variable to override this.
update-initramfs: Generating /boot/initrd.img-5.15.0-138-generic
I: The initramfs will attempt to resume from /dev/dm-2
I: (/dev/mapper/vgubuntu-swap_1)
I: Set the RESUME variable to override this.
update-initramfs: Generating /boot/initrd.img-5.15.0-67-generic
I: The initramfs will attempt to resume from /dev/dm-2
I: (/dev/mapper/vgubuntu-swap_1)
I: Set the RESUME variable to override this.
root at ubuntu20:/home/ubuntu#


*** ZFS on LUKS
root 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  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:/# zpool status -P rpool
  pool: rpool
 state: ONLINE
status: Mismatch between pool hostid and system hostid on imported pool.
               This pool was previously imported into a system with a different hostid,
               and then was verbatim imported into this system.
action: Export this pool on all systems on which it is imported.
               Then import it to correct the mismatch.
   see: http://zfsonlinux.org/msg/ZFS-8000-EY
  scan: none requested
config:

               NAME                 STATE     READ WRITE CKSUM
               rpool                ONLINE       0     0     0
                 /dev/mapper/luks1  ONLINE       0     0     0

errors: No known data errors
root at ubuntu20:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.4.0-214-generic
root 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://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2:2.2.2-3ubuntu2.4 500
        500 http://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://archive.ubuntu.com/ubuntu focal/main amd64 Packages
root at ubuntu20:/# 

** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal

-- 
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:
  Fix Committed
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