On 16/11/2018 14:43, Rich Freeman wrote:
> On Fri, Nov 16, 2018 at 12:15 PM Andrew Udvare <audvare@gmail.com> wrote:
>>
>> I am not sure if there is a way to move the systemd-cryptsetup@home.service up the dependency tree once it's working, which would then remove the mnt-chuan.mount dependency.
>>
> 
> Ok, I did a bit more reading.  You're using the cryptsetup generator
> most likely.  It sets up units to be oneshot+remainafterexit, which
> means they're "active" whenever the LUKS device is mounted (without
> any processes - but they show as active so that you can stop them and
> unmount the device).  It sets the RequiresMountsFor parameter for the
> device the key file is contained on, which makes that mount service a
> Required dependency.  That means that it can't be unmounted while the
> cryptsetup device is in use, and in theory attempting to unmount the
> key file should make systemd attempt to unmount the cryptsetup device
> (though busy filesystems could interfere with that).

So it is a bit strange that /mnt/chuan was considered a dependency just
because of mention in /etc/crypttab. However I found out that the reason
has something to do with the /mnt/chuan entry in /etc/fstab in my real
root, and this is not a necessary line (it is the only entry in the
initrd fstab). I removed the line and now the dependency is still show
with list-dependencies, but it is white instead of red. My system is
still shown as running rather than degraded.

Removing the line from /etc/fstab only partially solves the problem, as
it's not explained what happens with the USB drive once the root is
switched because after that it's not shown to be mounted. I am pretty
sure it's not safely unmounted before the switch, which leaves it in a
strange state requiring fsck. Don't know the best way around this other
than wait till systemd supports the keyscript option in /etc/crypttab.

-- 
Andrew