On Wed, 07.12.11 21:39, Ken Bass (kb...@kenbass.com) wrote: > I just upgraded from F14 to F16 so this is my first attempt at > systemd and I think I found a bug/issue. (I'm running > systemd-37-3.fc16.x86_64) > > My /dev/md0 (not a bootable disk thank goodness) is encrypted with luks. > > My crypttab contains: > encrypt_storage /dev/md0 /mnt/usbkey/storage.key > cipher=aes-cbc-essiv:sha256,size=256,hash=sha1 > > systemd would fail with: > [ 26.576425] systemd-cryptsetup[951]: crypt_init() failed: Block > device required > > That tells me that systemd is trying to access /dev/md0 before it > actually created the device. So, > after much documentation reading I created a local cryptsetup.target file: > > [Unit] > Description=Encrypted Volumes Wait > Requires=mnt-usbkey.mount dev-md0.device > After=mnt-usbkey.mount dev-md0.device > > The mnt-usbkey.mount ensures that the USB flash key is loaded early. > (Before cryptsetup.target). That is not germane to this discussion. > > The problem is the most of the time my changes fail. Occasionally it > would work, but mostly not. So after examining the logs and some > debug, I think the problem is a race with systemd or something. > > The problem is dev-md0.device becomes 'plugged' before the /dev/md0 > is actually created/ready. From the log: > > [ 26.136607] systemd[1]: dev-md0.device changed dead -> plugged > [ 26.136614] systemd[1]: Job dev-md0.device/start finished, result=done > [ 26.136634] systemd[1]: sys-devices-virtual-block-md0.device > changed dead -> plugged > [ 26.136691] systemd[1]: About to execute: > /lib/systemd/systemd-cryptsetup attach encrypt_storage /dev/md0 > /mnt/usbkey/storage.key > cipher=aes-cbc-essiv:sha256,size=256,hash=sha1 > ... > [ 26.576425] systemd-cryptsetup[951]: crypt_init() failed: Block > device required > > However, the md0 is not really up. Because the above command only > fails with /dev/md0 is missing. AND 500 milliseconds later...
Hmm, normally /dev/md0 should have been created by udev before systemd gets the device plug event. > If this means dev-md0.device is not accurate as an indicator of > /dev/md0 being present, then I guess every other reference such as > in my cryptsetup.target would need to be changed too. Normally, the device names should be equivalent. It's highly recommended though to use the /dev/by-xxx names, since they are stable, while /dev/md0, /dev/md1 and so on might be enumerated in a different order on different boots. > > This whole issue seems odd and certainly not intuitive. I thought I > was instructing systemd correcty, telling it to have the depending > on dev-md0.device. I would have thought any 'uuid' /dev/disk would > simply be an alias, but that does not appear to be the case. Normally /dev/md0 should be a device node, while /dev/by-xxx sjould be symlinks. Kay, do you know anything about device node creation of md in context with udev? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
