Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
On Sun, 23.09.12 18:20, Ali Lown (a...@lown.me.uk) wrote: 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?). Hmm, might be related to 44b5651f19b60a84dbfdbb0ea13196b784080c8b? Are you running a version with this, or without? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
On Mon, Sep 24, 2012 at 11:54:17AM +0200, Lennart Poettering wrote: On Sun, 23.09.12 18:20, Ali Lown (a...@lown.me.uk) wrote: 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?). Hmm, might be related to 44b5651f19b60a84dbfdbb0ea13196b784080c8b? Are you running a version with this, or without? OP said that he tested with f6c2e2 and v189. Both are later. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Cryptsetup on FakeRAID fails with timeout
FW back onto the mailing list: As the devices report ATM (after a manual mounting following systemd failure): /dev/md0: P: /devices/virtual/block/md0 N: md0 L: 100 S: disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb E: DEVLINKS=/dev/disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb E: DEVNAME=/dev/md0 E: DEVPATH=/devices/virtual/block/md0 E: DEVTYPE=disk E: ID_PART_TABLE_TYPE=dos E: MAJOR=9 E: MD_DEVICES=2 E: MD_LEVEL=raid1 E: MD_METADATA=0.90 E: MD_UUID=ee87365a:bf0826c6:0825cc4b:d1c49ecb E: MINOR=0 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=19557 /dev/md0p1: P: /devices/virtual/block/md0/md0p1 N: md0p1 L: 100 S: disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb-part1 E: DEVLINKS=/dev/disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb-part1 E: DEVNAME=/dev/md0p1 E: DEVPATH=/devices/virtual/block/md0/md0p1 E: DEVTYPE=partition E: ID_PART_ENTRY_DISK=9:0 E: ID_PART_ENTRY_NUMBER=1 E: ID_PART_ENTRY_OFFSET=2048 E: ID_PART_ENTRY_SCHEME=dos E: ID_PART_ENTRY_SIZE=1953122304 E: ID_PART_ENTRY_TYPE=0x5 E: ID_PART_TABLE_TYPE=dos E: MAJOR=259 E: MD_DEVICES=2 E: MD_LEVEL=raid1 E: MD_METADATA=0.90 E: MD_UUID=ee87365a:bf0826c6:0825cc4b:d1c49ecb E: MINOR=2 E: SUBSYSTEM=block E: SYSTEMD_READY=0 E: TAGS=:systemd: E: USEC_INITIALIZED=40061 /dev/md0p5 and /dev/md0p6 also report SYSTEMD_READY=0 So, the tag isn't being set correctly? Ali On 24 September 2012 11:11, Lennart Poettering lenn...@poettering.net wrote: On Mon, 24.09.12 10:59, Ali Lown (a...@lown.me.uk) wrote: As described in OP, I am running f6c2e28b07a0d24c68f7780fc986ac3619fdcbdb, so I am running with 44b5651f19b60a84dbfdbb0ea13196b784080c8b. I confirmed that the line added in 44b exists in /usr/lib64/udev/rules.d/99-systemd.rules. Hmm, please try to debug this by checking for the systemd tag and the SYSTEMD_READY field for the md device. systemd will pick up block devices only if the tag is set and the field is 1. Use udevadm info /dev/md0 (or suchlike) for this. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
On Mon, 24.09.12 12:22, Ali Lown (a...@lown.me.uk) wrote: FW back onto the mailing list: As the devices report ATM (after a manual mounting following systemd failure): /dev/md0: P: /devices/virtual/block/md0 N: md0 L: 100 S: disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb E: DEVLINKS=/dev/disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb E: DEVNAME=/dev/md0 E: DEVPATH=/devices/virtual/block/md0 E: DEVTYPE=disk E: ID_PART_TABLE_TYPE=dos E: MAJOR=9 E: MD_DEVICES=2 E: MD_LEVEL=raid1 E: MD_METADATA=0.90 E: MD_UUID=ee87365a:bf0826c6:0825cc4b:d1c49ecb E: MINOR=0 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=19557 /dev/md0p1: P: /devices/virtual/block/md0/md0p1 N: md0p1 L: 100 S: disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb-part1 E: DEVLINKS=/dev/disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb-part1 E: DEVNAME=/dev/md0p1 E: DEVPATH=/devices/virtual/block/md0/md0p1 E: DEVTYPE=partition E: ID_PART_ENTRY_DISK=9:0 E: ID_PART_ENTRY_NUMBER=1 E: ID_PART_ENTRY_OFFSET=2048 E: ID_PART_ENTRY_SCHEME=dos E: ID_PART_ENTRY_SIZE=1953122304 E: ID_PART_ENTRY_TYPE=0x5 E: ID_PART_TABLE_TYPE=dos E: MAJOR=259 E: MD_DEVICES=2 E: MD_LEVEL=raid1 E: MD_METADATA=0.90 E: MD_UUID=ee87365a:bf0826c6:0825cc4b:d1c49ecb E: MINOR=2 E: SUBSYSTEM=block E: SYSTEMD_READY=0 E: TAGS=:systemd: E: USEC_INITIALIZED=40061 /dev/md0p5 and /dev/md0p6 also report SYSTEMD_READY=0 So, the tag isn't being set correctly? The tag is there correctly (i.e. as you ca see in the TAGS= field, which includes systemd for both cases). My edcuated guess is that this is a result of you having a partition table on top of md, which causes the md rules in 99-systemd.rules not have ay effect on the partition block devices. Kay, Harald, could you please have a look into this? The current udev rule probably needs some updating to deal with setups like these. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
On Mon, Sep 24, 2012 at 2:32 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 24.09.12 12:22, Ali Lown (a...@lown.me.uk) wrote: /dev/md0p1: P: /devices/virtual/block/md0/md0p1 E: DEVTYPE=partition E: SUBSYSTEM=block E: SYSTEMD_READY=0 E: TAGS=:systemd: /dev/md0p5 and /dev/md0p6 also report SYSTEMD_READY=0 So, the tag isn't being set correctly? The tag is there correctly (i.e. as you ca see in the TAGS= field, which includes systemd for both cases). My edcuated guess is that this is a result of you having a partition table on top of md, which causes the md rules in 99-systemd.rules not have ay effect on the partition block devices. Not sure, if that's the whole story: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d2fff1ced447c09c6601a6617300467ccd81660b The current rules always marked all MD partitions as inactive, which does not sound right. We are not even sure if the partitions would ever get a change event later. Please try if that makes things better, as said, there might be more needed than that. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
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 a...@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 patra...@gmail.com wrote: 2012/9/17 Ali Lown a...@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
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
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 patra...@gmail.com wrote: 2012/9/17 Ali Lown a...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Cryptsetup on FakeRAID fails with timeout
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). I am using systemd from scm (f6c2e28b07a0d24c68f7780fc986ac3619fdcbdb). I have also tried systemd 189, and have the same problem there. The relevant line in fstab is: /dev/mapper/cryptmedia /home/ali/media auto defaults,noatime 0 0 and from crypttab: cryptmedia /dev/mapper/pdc_bhjchdjgaep5 - luks,verify Currently, this results in the boot process stalling for 90 seconds (default timeout) without ever displaying a password prompt. (No entries appear in /run/systemd/ask-password/) The relevant lines from syslog simply show the timeout 2012-09-17T12:28:45.441746+01:00 alipc-desktop-ex systemd[1]: Expecting device dev-mapper-pdc_bhjchdjgaep5.device... 2012-09-17T12:28:45.441750+01:00 alipc-desktop-ex systemd[1]: Expecting device dev-mapper-cryptmedia.device... 2012-09-17T12:30:15.439580+01:00 alipc-desktop-ex systemd[1]: Job dev-mapper-cryptmedia.device/start timed out. 2012-09-17T12:30:15.441039+01:00 alipc-desktop-ex systemd[1]: Timed out waiting for device dev-mapper-cryptmedia.device. 2012-09-17T12:30:15.442428+01:00 alipc-desktop-ex systemd[1]: Dependency failed for Cryptography Setup for cryptmedia. 2012-09-17T12:30:15.443037+01:00 alipc-desktop-ex systemd[1]: Job systemd-cryptsetup@cryptmedia.service/start failed with result 'dependency'. 2012-09-17T12:30:15.444311+01:00 alipc-desktop-ex systemd[1]: Dependency failed for /home/ali/media. 2012-09-17T12:30:15.445105+01:00 alipc-desktop-ex systemd[1]: Job home-ali-media.mount/start failed with result 'dependency'. 2012-09-17T12:30:15.445750+01:00 alipc-desktop-ex systemd[1]: Job dev-mapper-cryptmedia.device/start failed with result 'timeout'. 2012-09-17T12:30:15.446486+01:00 alipc-desktop-ex systemd[1]: Job dev-mapper-pdc_bhjchdjgaep5.device/start timed out. Notably, running the commands in systemd-cryptsetup@cryptmedia.service manually works correctly, so this seems to be a problem with how systemd is trying to run the commands. Do you have any ideas how I can debug this 'timeout'? Is it a problem due to the FakeRAID device not being a 'real' drive, so udev not reporting something correctly? Thanks in advance. Ali ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
2012/9/17 Ali Lown a...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
