Headless system slow trying to mount encrypted pool

[asfernandes]

I'm creating an Ubuntu raspberry pi machine which following characteristics:

• Headless
• It boots from unnencrypted SD card with fat/ext4 partitions
• There is attached USB disk which ZFS encrypted pool
• Password will not be present in the system, so when it turns on, one must connect to it via SSH to mount the encrypted disk. Only basic services for that will be started
• One encrypted disk is mounted, other services starts

All of this is based in this (non-ZFS) tutorial: https://blog.iwakd.de/headless-luks-decryption-via-ssh

But I had a problem. Boot is slow.

I have discovered the it's due that zfd-mount-generator generates service depending on local-fs.target so it asks 3 times with systemd-ask-password on the headless boot, each with 90 seconds timeout.

A way to make things better was to edit the generator using systemd-ask-password --timeout=5. It still looses 15 seconds, but when I manually start my decrypt.target service I had the time to insert the password.

Another way (which I preferred) was to comment the dependencies on local-fs.target generated.

But anyway I has to edit the generator code, which I want to avoid.

Could you create some way to make that setup easier?

Maybe if I just remove automount from the dataset and manually mount it before start decrypt.target would also resolve the problem, but I'm not sure it would be the best way to do it.

[asfernandes]

The generator use the canmount property, but if I set canmount=off I can not mount manually.

If we could in some manner declare in the manifest file that it's not for automatic mount and the generator does not put local-fs dependency in this case, would be very good.

[rincebrain]

canmount=noauto is a setting.

[asfernandes]

canmount=noauto is a setting.

That's good, it allow me to manually mount before call my service (target) to start all services.

But it makes my service somewhat weak, depending on things done before it's started.

It also makes things different from noauto mounts from /etc/stab.

Would a patch that in the case of canmount=noauto will work as canmount=on except without that lns?

  # Finally, create the appropriate dependency
  ln -s "../${mountfile}" "${req_dir}"

Then local-fs will not trigger the zfs mount but the <name>.mount will be generated so other services can depend on it.

[rincebrain]

Well, the mount generator has been rewritten as a C program in the interim, so you might want to check if it has the behavior you desire (I think it might), and propose a patch to that (or, if you really want it in 2.0 and prior, two separate patches).

I'm not familiar with the innards and expectations of either incarnation of the generator, though, so I have no idea whether such a change would seem unreasonable.

[asfernandes]

Is this version with the C program used in some stable Ubuntu version already?

[rincebrain]

It would be in the 2.1 release, which is currently on rc7, so no, I wouldn't think so.

[gdevenyi]

@asfernandes #10333

[asfernandes]

Well, the mount generator has been rewritten as a C program in the interim, so you might want to check if it has the behavior you desire (I think it might), and propose a patch to that (or, if you really want it in 2.0 and prior, two separate patches).

I'm not familiar with the innards and expectations of either incarnation of the generator, though, so I have no idea whether such a change would seem unreasonable.

It looks like the behavior I want is done there https://github.com/openzfs/zfs/blob/master/etc/systemd/system-generators/zfs-mount-generator.c#L534

I'll close that issue and maintain myself the custom version for now.