Description of problem: While I do have a LUKS-encrypted partition within a LVM, I used to turn off auto-mount during the bootong process with just adding nofail,noauto options to the corresponding line in the /etc/crypttab file generated during installation: #luks-84961d73-0674-425d-b9c5-63c161c672a8 UUID=84961d73-0674-425d-b9c5-63c161c672a8 none discard luks-84961d73-0674-425d-b9c5-63c161c672a8 UUID=84961d73-0674-425d-b9c5-63c161c672a8 none luks,noauto,nofail It used to work F25 but no longer works in F27. Here is my lsblk: NAME TYPE FSTYPE MOUNTPOINT STATE sda disk running ├─sda1 part vfat /boot/efi ├─sda2 part ext4 /boot └─sda3 part LVM2_member ├─host14-root lvm ext4 / running ├─host14-swap lvm swap [SWAP] running ├─host14-var lvm ext4 /var running ├─host14-efs lvm crypto_LUKS running │ └─luks-84961d73-0674-425d-b9c5-63c161c672a8 crypt ext4 /efs running └─host14-home lvm ext4 /home running uname -r: 4.14.3-300.fc27.x86_64 The only journal entry related to systemd-cryptsetup during reboot is: systemd-cryptsetup[795]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/84961d73-0674-425d-b9c5-63c161c672a8. Version-Release number of selected component (if applicable): systemd-234-9.fc27.x86_64 How reproducible: always Steps to Reproduce: 1. create custom encrypted partition (lvm,ext4) during F27 installation on a "fresh" hdd 2. boot up (first time you will be asked for a passphrase) 3. replace "discard" with "luks,nofail,noauto" (any combination of these options does not work) in the /etc/crypttab file 4. any subsequent reboot (either hot or cold) will be with the passphrase asked Actual results: passphrase is requested during the (re)booting Expected results: booting process should bypass auto-mounting encrypted partition (that is how it used to work in F25) Additional info:
Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha256 Payload offset: 4096 MK bits: 256 MK digest: d3 d0 fc ad 8c 5c 0a f7 ac e3 4e 41 b2 83 a8 b1 bf 8c f6 87 MK salt: 0b 5f 43 7f 77 4d ff db ba 63 db 53 55 53 ea d4 36 b6 65 65 39 10 d7 57 00 0b b0 af 05 18 a2 a4 MK iterations: 348750 UUID: cc6e6d72-04ff-45df-9236-554b750246c1 Key Slot 0: ENABLED Iterations: 2790189 Salt: be b0 57 6e d3 06 1e 70 ea 78 5b 30 74 55 f4 81 d2 72 af 22 bd c4 65 7b d0 03 76 89 85 3b fa b5 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED
dmesg: audit: type=1130 audit(1513037418.787:77): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-cryptsetup@luks\x2d84961d73\x2d0674\x2d425d\x2db9c5\x2d63c161c672a8 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Hi, crypttab processing is not implemented within cryptsetup component. Lets ask systemd team on their opinion.
Hi Ondrej et all, How it used to falwlessly work in F25 then? BTW, when I do some cryptsetup manipulation on the encrypted partition (for instance, by changing the passphrase), the booting process completely stuck at the never ending step: dev-mapper-luks\x2d84961d73\x2d0674\x2d425d\x2db9c5\x2d63c161c672a8.device I haven't found any way to proceed/bypass this step yet. Thanks, -Andrew
noauto in crypttab means that that device will not be added to cryptsetup.target. But if you add a mount unit that is mounted during boot using that encrypted device, it'll be "pulled in" by that mount unit and unlocked automatically. To prevent that device from being unlocked automatically, you also need to disable the mount unit. Our documentation for that is not too good. I files a PR upstream to clarify this: https://github.com/systemd/systemd/pull/7620.