cryptsetup waits for zvol /dev/zvol/rpool/swap with no zpool imported during boot. Timing problem?

Bug #1802481 reported by Lars
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
zfs-linux (Ubuntu)
New
Undecided
Unassigned

Bug Description

Hi,
first of all: I don't know if it is a bug in cryptsetup-initramfs or zfs-initramfs or another one.

The problem is that since my upgrade from bionic to cosmic the cryptsetup tries too early to setup my cryptswap device which is on a zvol.

  cryptsetup: Waiting for encrypted source device /dev/zvol/rpool/swap...
       ALERT! encrypted source device /dev/zvol/rpool/swap does not exist, can't unlock cryptswap1.
  ...

After timeout I find myself in a initramfs-shell (initramfs).
When I do zpool list there is no zpool importet.
After

  zpool import -N rpool
  ^D

the cryptsetup succeeds.
Greetings,

   Lars

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: cryptsetup-initramfs 2:2.0.4-2ubuntu2
ProcVersionSignature: Ubuntu 4.18.0-11.12-generic 4.18.12
Uname: Linux 4.18.0-11-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.10-0ubuntu13.1
Architecture: amd64
CurrentDesktop: GNOME
Date: Fri Nov 9 10:01:19 2018
EcryptfsInUse: Yes
PackageArchitecture: all
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.default.apport: [modified]
modified.conffile..etc.logrotate.d.apport: [modified]
mtime.conffile..etc.default.apport: 2015-03-15T20:01:19.851334
mtime.conffile..etc.logrotate.d.apport: 2018-05-18T08:58:12.902005

Revision history for this message
Lars (lollypop) wrote :
Lars (lollypop)
summary: - cryptsetup waits for zvol with no zpool imported
+ cryptsetup waits for zvol with no zpool imported during boot
Revision history for this message
Lars (lollypop) wrote : Re: cryptsetup waits for zvol with no zpool imported during boot

Hi,

is there anything else you need?

Greetings,

   Lars

Revision history for this message
Lars (lollypop) wrote :

BTW... my /etc/crypttab contains:
cryptswap1 /dev/zvol/rpool/swap /dev/urandom swap,cipher=aes-xts-plain64:sha256,size=256

summary: - cryptsetup waits for zvol with no zpool imported during boot
+ cryptsetup waits for zvol /dev/zvol/rpool/swap with no zpool imported
+ during boot
summary: cryptsetup waits for zvol /dev/zvol/rpool/swap with no zpool imported
- during boot
+ during boot. Timing problem?
Lars (lollypop)
affects: cryptsetup (Ubuntu) → zfs-linux (Ubuntu)
Revision history for this message
Richard Laager (rlaager) wrote :

Try adding initramfs as an option in /etc/crypttab. That's the approach I use when putting the whole pool on a LUKS device, and is necessary due to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1612906

Revision history for this message
Lars (lollypop) wrote :

Hi Richard,
thank you for your reply, but that didn't fix the problem.

It is more that at the moment when cryptsetup tries to configure the cryptdevice on /dev/zvol/rpool/swap, the zpool is not imported. So cryptsetup runs in timeout and drops me in a initramfs shell.

When I import the pool without mounting anything (zpool import -N rpool) the device is there and I can exit the initramfs shell and cryptsetup succeeds.

I had this bug in the cryptsetup bug list for a while and nothing happened. So I thought the ZFS people might be more interested ;-). In my opinion it is just the wrong order during boot.
The zpool has to be imported at the time when cryptsetup starts. Is there any reason it is other way round?

Greetings,

   Lars

Revision history for this message
Richard Laager (rlaager) wrote :

If the pool is on top of LUKS (a relatively common configuration when ZFS and cryptsetup are both being used), then you'd need cryptsetup first. My advice is that you should either stop encrypting swap or start encrypting the whole pool. Hopefully in another (Ubuntu) release or two, we'll have native ZFS encryption and this whole things Just Works.

Revision history for this message
Lars (lollypop) wrote :

Hey Richard,
OK I understand why this order has to be kept dunring boot amd I understand it is a personal problem and this bug can be closed.

It would be nice if you could point me to a workaround for my installation as I would love to only encrypt swap and home as we have no native zfs encryption right now.

Greetings,

   Lars

Revision history for this message
Richard Laager (rlaager) wrote :

I really don’t know what to suggest here. As you mentioned, this used to work. If you are only using LUKS for swap, maybe you could just remove it from crypttab and run the appropriate commands manually in rc.local or a custom systemd unit.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.