[systemd-devel] Cryptsetup on FakeRAID fails with timeout

[Ali Lown]

I responded too early, mdadm has caused its own set of problems:

- During the boot process, the mdXpX.device don't get marked as active
automatically causing X.mount based on those devices to fail.
Once I get to the emergency shell, simply calling 'systemctl
daemon-reload' reloads the mdXpX.device items which are now marked as
active (why?).
I have worked around this problem by building a new oneshot service
which calls 'systemctl daemon-reload' before attempting to use the
X.mount items. I also had to move the offending partitions to
'noauto,comment=systemd.automount' so that a suitable delay was put in
between the mdadm setup and reloading the modules otherwise
systemd-remount-fs.service wouldn't get started (for some reason)!

- Cryptsetup on the mdXpX device still fails when it is called, though
this time I get a more useful response other than 'timeout':
Sep 23 18:06:29 alipc-desktop-ex sudo[3636]: ali : TTY=pts/4 ;
PWD=/home/ali ; USER=root ; COMMAND=/usr/bin/systemctl start
home-ali-m
Sep 23 18:06:29 alipc-desktop-ex sudo[3636]: pam_unix(sudo:session):
session opened for user root by (uid=0)
Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Starting Cryptography
Setup for cryptmedia...
Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Expecting device
dev-mapper-cryptmedia.device...
Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Starting Forward Password
Requests to Wall...
Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Starting Dispatch
Password Requests to Console...
Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Started Dispatch Password
Requests to Console.
Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Stopping Dispatch
Password Requests to Console Directory Watch.
Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Stopped Dispatch Password
Requests to Console Directory Watch.
Sep 23 18:06:29 alipc-desktop-ex systemd[1]: Stopping Dispatch
Password Requests to Console...
Sep 23 18:06:29 alipc-desktop-ex systemctl[3641]: Failed to issue
method call: Unit systemd-ask-password-plymouth.path not loaded.
Sep 23 18:06:29 alipc-desktop-ex systemctl[3641]: Failed to issue
method call: Unit systemd-ask-password-plymouth.service not loaded.
Sep 23 18:06:38 alipc-desktop-ex systemd-cryptsetup[3640]: Set cipher
aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/md
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Started Cryptography
Setup for cryptmedia.
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Dependency failed for
/home/ali/media.
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Job
home-ali-media.mount/start failed with result 'dependency'.
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Unmounted /home/ali/media.
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Stopped
dev-mapper-cryptmedia.device.
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Stopping Cryptography
Setup for cryptmedia...
Sep 23 18:06:39 alipc-desktop-ex sudo[3636]: pam_unix(sudo:session):
session closed for user root
Sep 23 18:06:39 alipc-desktop-ex systemd-udevd[3644]: conflicting
device node '/dev/mapper/cryptmedia' found, link to '/dev/dm-0' will
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Found device
/dev/disk/by-uuid/df808cdc-73c2-4bd0-8fdc-53a5251a8030.
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Found device
/dev/disk/by-id/dm-uuid-CRYPT-LUKS1-1aca68ec78a8433081cfc1c3510fe8df-cryptme
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Found device
/dev/disk/by-id/dm-name-cryptmedia.
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Found device /dev/dm-0.
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Found device
/sys/devices/virtual/block/dm-0.
Sep 23 18:06:39 alipc-desktop-ex systemd[1]: Expecting device /dev/md1p5...

The 'conflicting device node' is an interesting message, since I don't
see how it can be conflicting with anything...

Thanks.
Ali

On 22 September 2012 12:43, Ali Lown <ali at lown.me.uk> wrote:
> I waited until the weekend so I could take down the devices briefly.
> After converting to use md instead, I can confirm that systemd is
> working fine with automounting the luks partition and correctly asking
> for a passphrase.
>
> The migration I used was:
> dmraid -an #disable dmraid devices
> mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=0.90
> /dev/sdb /dev/sdc
> I chose to use v0.9 since I wanted kernel autodetect with needing to
> maintain an initramfs as well.
>
> Currently the disks are resyncing (and will be for the next few hours).
>
> Shall I take this as a sign that dmraid is being deprecated in the linux world?
>
> On 17 September 2012 13:57, Alexander E. Patrakov <patrakov at gmail.com> wrote:
>> 2012/9/17 Ali Lown <ali at lown.me.uk>:
>>> I am unable to get systemd to mount a LUKS partition on boot. This
>>> LUKS partition (pdc_bhjchdjgaep5) sits on top of a fakeraid mirror set
>>> (pdc_bhjchdjgae) of 2TB disks (sdd,sde).
>>
>> Disclaimer: what I am proposing below is not a solution, just a workaround.
>>
>> Now that a normal "md" raid is able to assemble fake RAIDs perviously
>> handled by dmraid, could you please try to migrate? Just try to
>> assemble md raid as usual, obviously without having run dmraid. You'll
>> get devices like md126_p1 and md126_p2.
>>
>> --
>> Alexander E. Patrakov