Bug 679842
| Summary: | Systemd udev rule prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Miroslav Grepl <mgrepl> |
| Component: | systemd | Assignee: | Lennart Poettering <lpoetter> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | bruno, dwalsh, hvtaifwkbgefbaei, jlaska, lpoetter, mbroz, mcepl, mcepl, metherid, mgrepl, mschmidt, notting, plautrba, prajnoha |
| Target Milestone: | --- | Keywords: | Reopened, SELinux |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | AcceptedBlocker RejectedNTH | ||
| Fixed In Version: | systemd-20-1.fc15 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 678927 | Environment: | |
| Last Closed: | 2011-03-12 04:42:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 678927 | ||
| Bug Blocks: | 657618 | ||
|
Description
Miroslav Grepl
2011-02-23 17:06:01 UTC
Hmm, why did this get duplicated against systemd? This needs a policy change, no change in systemd. Or am I missing something? The problem is it does not work in permissive mode as Matej wrote.
> And yes, this happens even though I have SELinux in a permissive mode.
Uh, if the boot stays stuck my guess this is due to LVM borkage and has nothing to do with selinux. https://bugzilla.redhat.com/show_bug.cgi?id=679321 Matej, are you using LVM? Does "udevadm -qall -p /sys/class/block/dm..." show those flags mentioned in the bug report? jakoubek:mapper# /bin/ls -l celkem 0 crw-------. 1 root root 10, 236 24. úno 09.01 control lrwxrwxrwx. 1 root root 7 24. úno 16.19 home -> ../dm-8 lrwxrwxrwx. 1 root root 7 24. úno 09.01 vg_bradford-lv_home -> ../dm-0 lrwxrwxrwx. 1 root root 7 24. úno 09.01 vg_bradford-lv_swap -> ../dm-2 jakoubek:mapper# udevadm -p /sys/class/block/dm-8 -q all udevadm: invalid option -- 'p' jakoubek:mapper# udevadm info -p /sys/class/block/dm-8 -q all P: /devices/virtual/block/dm-8 N: dm-8 S: mapper/home S: disk/by-id/dm-name-home S: disk/by-id/dm-uuid-CRYPT-LUKS1-4fc6bff38bc541b897b382631d58665a-home S: disk/by-uuid/ace27985-bead-409c-9165-86881ba7a101 E: UDEV_LOG=3 E: DEVPATH=/devices/virtual/block/dm-8 E: MAJOR=253 E: MINOR=8 E: DEVNAME=/dev/dm-8 E: DEVTYPE=disk E: SUBSYSTEM=block E: DM_SBIN_PATH=/sbin E: DM_UDEV_PRIMARY_SOURCE_FLAG=1 E: DM_UDEV_RULES_VSN=2 E: DM_NAME=home E: DM_UUID=CRYPT-LUKS1-4fc6bff38bc541b897b382631d58665a-home E: DM_SUSPENDED=0 E: ID_FS_UUID=ace27985-bead-409c-9165-86881ba7a101 E: ID_FS_UUID_ENC=ace27985-bead-409c-9165-86881ba7a101 E: ID_FS_VERSION=1.0 E: ID_FS_TYPE=ext4 E: ID_FS_USAGE=filesystem E: FSTAB_NAME=/dev/mapper/home E: FSTAB_DIR=/home E: FSTAB_TYPE=ext4 E: FSTAB_OPTS=defaults E: FSTAB_FREQ=1 E: FSTAB_PASSNO=2 E: UDISKS_PRESENTATION_NOPOLICY=1 E: UDISKS_DM_TARGETS_COUNT=1 E: UDISKS_DM_TARGETS_TYPE=crypt E: UDISKS_DM_TARGETS_START=0 E: UDISKS_DM_TARGETS_LENGTH=204795960 E: DEVLINKS=/dev/mapper/home /dev/disk/by-id/dm-name-home /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-4fc6bff38bc541b897b382631d58665a-home /dev/disk/by-uuid/ace27985-bead-409c-9165-86881ba7a101 E: TAGS=:systemd: jakoubek:mapper# udevadm info -p /sys/class/block/dm-0 -q all P: /devices/virtual/block/dm-0 N: dm-0 S: mapper/vg_bradford-lv_home S: vg_bradford/lv_home S: disk/by-id/dm-name-vg_bradford-lv_home S: disk/by-id/dm-uuid-LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkVVqafrkB2QU9fbcc1qIaORtn82kGJcJ9L S: disk/by-uuid/4fc6bff3-8bc5-41b8-97b3-82631d58665a E: UDEV_LOG=3 E: DEVPATH=/devices/virtual/block/dm-0 E: MAJOR=253 E: MINOR=0 E: DEVNAME=/dev/dm-0 E: DEVTYPE=disk E: SUBSYSTEM=block E: DM_SBIN_PATH=/sbin E: DM_UDEV_PRIMARY_SOURCE_FLAG=1 E: DM_UDEV_RULES_VSN=2 E: DM_NAME=vg_bradford-lv_home E: DM_UUID=LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkVVqafrkB2QU9fbcc1qIaORtn82kGJcJ9L E: DM_SUSPENDED=0 E: DM_VG_NAME=vg_bradford E: DM_LV_NAME=lv_home E: DEVLINKS=/dev/mapper/vg_bradford-lv_home /dev/vg_bradford/lv_home /dev/disk/by-id/dm-name-vg_bradford-lv_home /dev/disk/by-id/dm-uuid-LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkVVqafrkB2QU9fbcc1qIaORtn82kGJcJ9L /dev/disk/by-uuid/4fc6bff3-8bc5-41b8-97b3-82631d58665a E: ID_FS_UUID=4fc6bff3-8bc5-41b8-97b3-82631d58665a E: ID_FS_UUID_ENC=4fc6bff3-8bc5-41b8-97b3-82631d58665a E: ID_FS_VERSION=1 E: ID_FS_TYPE=crypto_LUKS E: ID_FS_USAGE=crypto E: UDISKS_PRESENTATION_NOPOLICY=1 E: TAGS=:systemd: jakoubek:mapper# udevadm info -p /sys/class/block/dm-2 -q all P: /devices/virtual/block/dm-2 N: dm-2 S: mapper/vg_bradford-lv_swap S: vg_bradford/lv_swap S: disk/by-id/dm-name-vg_bradford-lv_swap S: disk/by-id/dm-uuid-LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkV23nCXk2egJm8ul7Z2xC9xIsdB9x0DG89 E: UDEV_LOG=3 E: DEVPATH=/devices/virtual/block/dm-2 E: MAJOR=253 E: MINOR=2 E: DEVNAME=/dev/dm-2 E: DEVTYPE=disk E: SUBSYSTEM=block E: DM_SBIN_PATH=/sbin E: DM_UDEV_PRIMARY_SOURCE_FLAG=1 E: DM_UDEV_RULES_VSN=2 E: DM_NAME=vg_bradford-lv_swap E: DM_UUID=LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkV23nCXk2egJm8ul7Z2xC9xIsdB9x0DG89 E: DM_SUSPENDED=0 E: DM_VG_NAME=vg_bradford E: DM_LV_NAME=lv_swap E: DEVLINKS=/dev/mapper/vg_bradford-lv_swap /dev/vg_bradford/lv_swap /dev/disk/by-id/dm-name-vg_bradford-lv_swap /dev/disk/by-id/dm-uuid-LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkV23nCXk2egJm8ul7Z2xC9xIsdB9x0DG89 E: UDISKS_PRESENTATION_NOPOLICY=1 E: SYSTEMD_READY=0 E: TAGS=:systemd: Matej, yupp, this is the LVm problem: E: UDISKS_PRESENTATION_NOPOLICY=1 E: SYSTEMD_READY=0. *** This bug has been marked as a duplicate of bug 679321 *** (In reply to comment #5) > Matej, yupp, this is the LVm problem: > > E: UDISKS_PRESENTATION_NOPOLICY=1 > E: SYSTEMD_READY=0. After discussing it with LVM folks, it seems that more like udev problem which hits LVM first, but whatever. I agree, it is duplicate of the bug you closed it against. This is somehing different.
UDISKS_PRESENTATION_NOPOLICY is apparently correct, see udisks rule:
ENV{UDISKS_PRESENTATION_NOPOLICY}="1"
KERNEL=="sd*|hd*|sr*|mmcblk*|mspblk*", ENV{UDISKS_PRESENTATION_NOPOLICY}="0"
Now, why is SYSTEM_READY=0 ? only for swap LV!
but in udev db is NOT DM_UDEV_DISABLE_OTHER_RULES_FLAG set... strange
SUBSYSTEM=="block", KERNEL!="ram*|loop*", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}="0"
This systemd udev rule is wrong:
SUBSYSTEM=="block", KERNEL!="ram*|loop*", ENV{ID_PART_TABLE_TYPE}=="", ENV{ID_FS_USAGE}=="", ENV{SYSTEMD_READY}="0"
if ID_PART_TABLE_TYPE and D_FS_USAGE is empty, it sets SYSTEMD_READY=0.
And it is for swap LV (no LUKS header).
From alpha blocker meeting: #agreed no data changes the impact of 679842, it remains not an alpha blocker. agreed by all that it is a beta blocker. voted not alpha NTH by 5 to 2. Fixed in systemd git, upload will follow shortly. If the fix is http://cgit.freedesktop.org/systemd/commit/?id=90e6abaea0cfd25093aae1ad862c5c909ae55829 I must admit that I do not understand this patch. I thought the fix should be opposite (ENV{DM_UUID}!="CRYPT-*") - why systemd is marking crypt device SYSTEMD_READY=0? In /etc/crypttab you can mark a device with the "tmp" or "swap" options. If that is done the crypto device is set up (usually with a key from /dev/urandom) and then mke2fs resp. mkswap is called on it. Now, systemd will notice the device as soon as it is set up via cryptsetup, and before this udev rule existed it would then immediately go and invoke depending units right-away (without waiting for mke2fs/mkswap), which would then very likely call swapon or mount. However, since that would run in parallel with the mke2fs/mkswap this would of course fail. To protect us from that we then added the original rule and set SYSTEMD_READY=0 as long as no superblock could be found on a block device, under the assumption that nothing is lost this way, because what can you do with a block device with no superblock of any kind that would be relevant to systemd dependencies? Well, turns out that it actually can contain a raw encrypted device which is not detected as superblock. This change now limits the additional check the effect of the superblock checking: we will do so only if this is actually on an encrypted device, because only then we might end up call mke2fs/mkswap on it which we need to wait for. This should fix the problem, except of course of folks who stack encrypted device on top of each other... Package systemd-19-1.fc15: * should fix your issue, * was pushed to the Fedora 15 updates-testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-19-1.fc15' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/systemd-19-1.fc15 then log in and leave karma (feedback). systemd-19-1.fc15 has been pushed to the Fedora 15 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-19-1.fc15 Yes, this really have been fixed. Thank you systemd-20-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/systemd-20-1.fc15 systemd-20-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. systemd 30 does not enable encryption for swap. 28 or something did, 29 did not manage to boot my system. This setup worked OK for nine years,... and then systemd came :( # grep swap /etc/fstab LABEL=wd1swap swap swap pri=10,encryption=AES128,loop=/dev/loop6 LABEL=wd2swap swap swap pri=10,encryption=AES128,loop=/dev/loop4 # swapon -s Filename Type Size Used Priority /dev/sda1 partition 4200960 277680 0 /dev/sdb5 partition 4194300 278724 0 # losetup -a /dev/loop3: [0005]:158 (/dev/sda6) encryption=eme256 /dev/loop5: [0005]:157 (/dev/sda5) encryption=eme256 |