Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1810332 - clevis-luks-askpass do not automatically unlocks the encrypted partition
Summary: clevis-luks-askpass do not automatically unlocks the encrypted partition
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: clevis
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Sergio Correia
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: IoT
TreeView+ depends on / blocked
 
Reported: 2020-03-05 00:50 UTC by nicolasoliver03
Modified: 2020-09-25 16:40 UTC (History)
7 users (show)

Fixed In Version: clevis-14-1.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-07 17:13:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description nicolasoliver03 2020-03-05 00:50:58 UTC
Description of problem:
clevis-luks-askpass do not automaticall unlocks the encrypted partition.
The encrypted partition is a volume in a LVM Group.

Disk state is the following

[root@fedora-iot-2 ~]# fdisk -l /dev/sda
Disk /dev/sda: 29.51 GiB, 31675383808 bytes, 61865984 sectors
Disk model: M2SCF-6M 32GB   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: C7CB9DDE-6A4D-4722-A8E5-7C80E858AB0D

Device       Start      End  Sectors  Size Type
/dev/sda1     2048   411647   409600  200M EFI System
/dev/sda2   411648  2508799  2097152    1G Linux filesystem
/dev/sda3  2508800 61863935 59355136 28.3G Linux LVM

The LVM in /dev/sda3 has 3 volumes

[root@fedora-iot-2 ~]# lvdisplay -v /dev/fedora-iot
  --- Logical volume ---
  LV Path                /dev/fedora-iot/swap
  LV Name                swap
  VG Name                fedora-iot
  LV UUID                cbbvbj-rdch-2FWh-dqzH-O2zt-4m0Q-dDewvD
  LV Write Access        read/write
  LV Creation host, time fedora-iot-2, 2019-09-25 10:03:58 -0700
  LV Status              available
  # open                 2
  LV Size                2.95 GiB
  Current LE             756
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1
   
  --- Logical volume ---
  LV Path                /dev/fedora-iot/root
  LV Name                root
  VG Name                fedora-iot
  LV UUID                7HEKE1-T4W4-MVmR-fud2-nxaz-xTNt-0qY1ms
  LV Write Access        read/write
  LV Creation host, time fedora-iot-2, 2019-09-25 10:03:59 -0700
  LV Status              available
  # open                 1
  LV Size                <20.35 GiB
  Current LE             5209
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0
   
  --- Logical volume ---
  LV Path                /dev/fedora-iot/home
  LV Name                home
  VG Name                fedora-iot
  LV UUID                Rzc8Uk-Navh-Wm2g-Bz5Z-eemN-2EHY-RASHYD
  LV Write Access        read/write
  LV Creation host, time fedora-iot-2, 2020-03-04 11:14:43 -0800
  LV Status              available
  # open                 1
  LV Size                5.00 GiB
  Current LE             1280
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

The home volume has a LUKS container in it 

[root@fedora-iot-2 ~]# cryptsetup luksDump /dev/fedora-iot/home 
LUKS header information
Version:        2
Epoch:          6
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           b295efc0-8a61-4fd1-bdf7-40b1994f509f
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
        offset: 16777216 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 512 [bytes]

Keyslots:
  0: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2i
        Time cost:  4
        Memory:     611865
        Threads:    4
        Salt:       de 89 81 b6 7f ea b6 a5 58 76 87 9a f4 47 fd c5 
                    e1 81 5c 8f 92 11 0a c7 6f 8f 99 8b 8d 9a 13 91 
        AF stripes: 4000
        AF hash:    sha256
        Area offset:32768 [bytes]
        Area length:258048 [bytes]
        Digest ID:  0
  1: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2i
        Time cost:  4
        Memory:     603466
        Threads:    4
        Salt:       32 d0 8a 1f a9 e4 a0 2d a6 d7 10 76 91 3d d8 4c 
                    42 93 d3 30 55 c6 fb 66 92 d6 2d 48 63 b3 6f 0e 
        AF stripes: 4000
        AF hash:    sha256
        Area offset:290816 [bytes]
        Area length:258048 [bytes]
        Digest ID:  0
  2: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2i
        Time cost:  4
        Memory:     623402
        Threads:    4
        Salt:       7d 82 ee 58 ef e8 6a 4a 95 eb 4b 1c 00 fe 09 5b 
                    42 00 78 6c b0 1d 0a 09 e9 fc 69 57 cd 7c 50 2b 
        AF stripes: 4000
        AF hash:    sha256
        Area offset:548864 [bytes]
        Area length:258048 [bytes]
        Digest ID:  0
Tokens:
  0: clevis
        Keyslot:  1
Digests:
  0: pbkdf2
        Hash:       sha256
        Iterations: 76116
        Salt:       6d 14 a7 a4 d6 3c f2 83 0e 2a ea ad 7c 18 e0 a4 
                    8c a2 ff df 6d 6b dd 55 d0 33 94 2d f5 d6 cf fb 
        Digest:     d5 31 60 41 b4 62 a2 79 71 b7 3f e1 8c ad 1e fe 
                    2f f9 17 d5 68 72 12 0b ab e3 87 3b 3a 90 43 9d

There is a clevis token on keyslot 1.

Given that it is not a rootfs, I need to use the "late boot unlock" process described here https://github.com/latchset/clevis/blob/3375b081f04f5105dfa654c15ac5c8c98756dd1b/src/luks/clevis-luks-unlockers.7.adoc#late-boot-unlocking

The service state is enabled

[root@fedora-iot-2 ~]# systemctl status clevis-luks-askpass.path
● clevis-luks-askpass.path - Clevis systemd-ask-password Watcher
   Loaded: loaded (/usr/lib/systemd/system/clevis-luks-askpass.path; enabled; vendor preset: disabled)
   Active: active (waiting) since Wed 2020-03-04 16:35:52 PST; 9min ago

Mar 04 16:35:52 fedora-iot-2 systemd[1]: Started Clevis systemd-ask-password Watcher.

I have added the entry in /etc/crypttab 

[root@fedora-iot-2 ~]# cat /etc/crypttab 
encryptedhome /dev/mapper/fedora--iot-home none _netdev

And the entry in /etc/fstab

[root@fedora-iot-2 ~]# cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Wed Sep 25 13:06:52 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
/dev/mapper/fedora--iot-root /                       ext4    defaults        1 1
UUID=32e96389-4eb8-4a8d-8f39-383d1fe3b13b /boot                   ext4    defaults        1 2
UUID=E058-A35D          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/fedora--iot-swap none                    swap    defaults        0 0
/dev/mapper/encryptedhome /var/lib/docker ext4 defaults  0 2

The versions are:

[root@fedora-iot-2 ~]# rpm-ostree status 
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora-iot:fedora/stable/x86_64/iot
                   Version: 31.20200209.0 (2020-02-09T09:57:02Z)
                BaseCommit: 4beac0ca768cf3d1d0eb90963ed0ac3a0c88af2f2bff958fa84935ec3ff01ec4
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
           LayeredPackages: bzip2 cockpit cockpit-ostree containerd.io docker-ce docker-ce-cli docker-compose expect git nano openvpn udisks2

[root@fedora-iot-2 ~]# rpm -qa clevis*
clevis-12-1.fc31.x86_64
clevis-dracut-12-1.fc31.x86_64
clevis-luks-12-1.fc31.x86_64
clevis-systemd-12-1.fc31.x86_64

With this configuration, the system does not complete the boot and goes into an emergency console. No password prompt shown.

If I remove the _netdev parameter in cryptab, I get the password prompt on late boot, input the correct password, and my system boots with the correct mapper and mount point.

Version-Release number of selected component (if applicable):

Fedora IoT 31.20200209.0
clevis-*-12.1

How reproducible:
Apply the same configuration to a system, and get it unable to boot

Steps to Reproduce:
1. Apply configurations
2. reboot

Actual results:

System halt boot because it is unable to mount the encryptedhome mapper.
encryptedhome mapper never created.

Expected results:

System boots as if I had input the correct password, and everything is mounted correctly.

Additional info:

Comment 1 nicolasoliver03 2020-03-10 16:19:53 UTC
This is also reproducible in Fedora Server 31.

With the same configuration, I get a broken device when I set the _netdev property in crypttab. And if I remove it, I get the password prompt as expected.

Comment 2 Javier Martinez Canillas 2020-03-10 17:08:08 UTC
(In reply to nicolasoliver03 from comment #0)

[snip]

> 
> I have added the entry in /etc/crypttab 
> 
> [root@fedora-iot-2 ~]# cat /etc/crypttab 
> encryptedhome /dev/mapper/fedora--iot-home none _netdev
> 
> And the entry in /etc/fstab
> 
> [root@fedora-iot-2 ~]# cat /etc/fstab 
> 
> #
> # /etc/fstab
> # Created by anaconda on Wed Sep 25 13:06:52 2019
> #
> # Accessible filesystems, by reference, are maintained under '/dev/disk/'.
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
> #
> # After editing this file, run 'systemctl daemon-reload' to update systemd
> # units generated from this file.
> #
> /dev/mapper/fedora--iot-root /                       ext4    defaults       
> 1 1
> UUID=32e96389-4eb8-4a8d-8f39-383d1fe3b13b /boot                   ext4   
> defaults        1 2
> UUID=E058-A35D          /boot/efi               vfat   
> umask=0077,shortname=winnt 0 2
> /dev/mapper/fedora--iot-swap none                    swap    defaults       
> 0 0
> /dev/mapper/encryptedhome /var/lib/docker ext4 defaults  0 2
> 

My understanding is that this is expected.

Because clevis-luks-askpass is executed after the network-online.target, which means that the /dev/mapper/fedora--iot-home LUKS volume will only be unlocked after the network has been brought up. But the network is started after the local file systems have been mounted (in local-fs.target) but local-fs.target is waiting for /dev/mapper/encryptedhome to be mounted and so the network is never brought up.

The crypttab(5) man page explains this situation much better than me:

"Hint: if this device is used for a mount point that is specified in fstab(5), the _netdev option should also be used for the mount point. Otherwise, a dependency loop might be created where the mount point will be pulled in by local-fs.target, while the service to configure the network is usually only started after the local file system has been mounted."

So if you want to use the _netdev option in your /etc/crypttab entry, then you need to do something like the following in /etc/fstab:

/dev/mapper/encryptedhome /var/lib/docker ext4 defaults,_netdev  0 2

> 
> If I remove the _netdev parameter in cryptab, I get the password prompt on
> late boot, input the correct password, and my system boots with the correct
> mapper and mount point.
> 

Yes, that's also expected because in that case systemd-ask-password doesn't have to wait for the network to be brought up to ask for a password, so you can enter the password for /dev/mapper/fedora--iot-home to be unlocked, and after that /dev/mapper/encryptedhome is present so the partition can be mounted and the local-fs.target complete.

So this is not really a bug but I agree that at least the clevis documentation should be improved to mention this. I also got confused by this and had to dig in the different man pages and clevis source to understand what was happening.

Now I've two questions about this behaviour in clevis though:

1- Why the clevis systemd-ask-password responder has to be executed after the network-online.target? (which makes the /etc/crypttab entries to require a _netdev option).

2- Could the clevis-luks-askpass.path watcher be more flexible to not require this for some cases?

I think (1) is just because tang was the only pin supported and that of course required the network. But if you are only using the clevis tpm2 pin then something like After=dev-tpm0.device should be enough.

I don't know enough about systemd unit files to figure out how to accomplish (2) but that's something that we should discuss with clevis upstream.

Comment 3 nicolasoliver03 2020-03-10 17:37:24 UTC
Thank you Javier!

I updated my /etc/fstab with _netdev, and my Fedora Server 31 automatically unlocked and mounted the disk :)
Same happened in my Fedora IoT 31. So it was a configuration issue on my side.

I actually had to guess how all this after reading clevis, and crypttab documentation, and I missed the _netdev in fstab.
The script I used to reproduce this is below, in case that somebody see this comment in the future:


pvcreate /dev/sda
vgcreate lvmvolume /dev/sda
lvcreate -y -L 5G -n root lvmvolume
lvcreate -y -L 512M -n swap lvmvolume
lvcreate -y -L 2G -n encryptedhome lvmvolume
openssl rand -hex 8 > key
cryptsetup -q luksFormat /dev/lvmvolume/encryptedhome key
clevis luks bind -f -k key -d /dev/lvmvolume/encryptedhome tpm2 '{}'
clevis luks unlock -d /dev/lvmvolume/encryptedhome -n c1
mkfs.ext4 /dev/mapper/c1
sleep 1
cryptsetup luksClose c1

echo "encryptedhome /dev/mapper/fedora--iot-home none _netdev" >> /etc/crypttab
echo "/dev/mapper/encryptedhome /var/home ext4 defaults,_netdev  0 2" >> /etc/fstab


Apparently, _netdev causes to wait for the network-online.target. Does this means that my disk will not get unlocked if I have no network interface enabled? Will test that!

Comment 4 nicolasoliver03 2020-03-10 17:52:08 UTC
I disabled wifi, gsm, and unplugged the ethernet cable. Apparently this works as long as I get a loopback address configured. 
This is good for the TPM case, but could that cause problems in the TANG scenario?

Comment 5 fwang#1@ilts.com 2020-07-21 01:01:30 UTC
Hello Javier and  Nicolas,

I have the same issue but I still can not resolve it. Right now I have encrypted my 2 partitions, like /dev/sda2 and /dev/sda4. I created these 2 partitions and format them as LUKS and created 2 different CRYPT mapper, 
I encrypted like this:
for sda2:
cryptsetup  luksFormat /dev/sda2
cryptsetup luksOpen /dev/sda2 Enc
mkfs.xfs /dev/mapper/Enc 

for sda4:
cryptsetup  luksFormat /dev/sda4 
cryptsetup luksOpen /dev/sda4 system 
mkfs.xfs /dev/mapper/system 

then bindto tpm:

clevis luks bind -f -k- -d /dev/sda2 tpm2 '{"pcr_ids":"7,11"}'
clevis luks bind -f -k- -d /dev/sda4 tpm2 '{"pcr_ids":"7,11"}'

After that I follow: https://bugzilla.redhat.com/show_bug.cgi?id=1784084 setup:
# cat > /etc/systemd/system/clevis-luks-askpass.path << EOF
[Unit]
Description=Clevis systemd-ask-password Watcher
DefaultDependencies=no
Conflicts=shutdown.target
Before=cryptsetup.target

[Path]
PathChanged=/run/systemd/ask-password

[Install]
WantedBy=cryptsetup.target
EOF
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# cat > /etc/systemd/system/clevis-luks-askpass.service << EOF
[Unit]
Description=Clevis LUKS systemd-ask-password Responder
DefaultDependencies=no
Conflicts=shutdown.target

[Service]
Type=oneshot
ExecStart=/usr/libexec/clevis-luks-askpass -l
EOF

Inorder to not prompt password input I follow: https://discussion.fedoraproject.org/t/automatic-decrypt-with-tpm2-on-silverblue/8424
sudo systemctl edit systemd-ask-password-plymouth.service

[Service]
ExecStartPre=/bin/sleep 120
and

sudoedit /etc/dracut.conf.d/systemd-ask-password-plymouth.conf

install_items+=" /etc/systemd/system/systemd-ask-password-plymouth.service.d/override.conf "

then : dracut -fv --regenerate-all 
reboot, I found it automatically boot up system and unlock the encrypted partions but sometimes it does not. I am not sure what is going on my system. But it is look like what you said.
these 2 partitions are not my root partitions, under production requirement we can not connect with network, if using dracut -fv --regenerate-all to rebuild initramfs then system can not bring up without network. I have to pass rd.neednet=0 from command line in /etc/default/grub and rebuild initramfs. 

Question:  
1. Nicolas, how come you can bring up without network disabled in such situation? how do you configure your loopback ip? your rd.neednet=1?
2. Do you know what my issue is? I am using tpm2, in your comment you said: After=dev-tpm0.device should be enough, how to do that?

Thank you! Please help and appreciate.

Comment 6 nicolasoliver03 2020-07-21 23:06:23 UTC
Hello!

I have this setup automated, and for me it is consistently working. 

The first step is to enable the clevis-luks-askpass.path service. The service is installed by default, at least in Fedora IoT 31.

Then, I create my encrypted partitions with the following commands:

# Encrypted Partition: /var/opt
lvcreate -y -l 20%VG -n opt system
printf "PASSWORD" | cryptsetup -q luksFormat /dev/system/opt -d -
printf "PASSWORD" | clevis luks bind -f -k- -d /dev/system/opt tpm2 '{}'
printf "PASSWORD" | cryptsetup luksOpen /dev/system/opt c1 -d -
mkfs.ext4 /dev/mapper/c1
sleep 1
cryptsetup luksClose c1
echo "luks-system-opt /dev/system/opt none _netdev" >> /etc/crypttab
echo "/dev/mapper/luks-system-opt /var/opt ext4 defaults,_netdev  0 2" >> /etc/fstab

In my case, I am using LVM for my partitions, but should work with standard partitions as well. 

In the boot process, I see the Clevis Luks Askpass service sometimes failing as well, but it immediately retries the unlock process and succeed. 
The only mayor difference I see from my setup and yours is the usage of PCR 7 and 11 as the integrity policy.
In PCR 7, I can inspect the measurements from the TPM Event Log, which can be seen below. So, if something measured there changes, you will get a locked partition, my guess is the DBX (which gets periodically updated)
I have never seen any software using the PCR 11. Is that something custom? My guess is that those measurements will not be included  in the event log.

$ sudo tsseventextend -sim -if /sys/kernel/security/tpm0/binary_bios_measurements -v | grep 'PCR index 7' --context=2

eventextend: line 3
TSS_EVENT2_Line_Trace: PCR index 7
TSS_EVENT_EventType_Trace: 80000001 EV_EFI_VARIABLE_DRIVER_CONFIG
TSS_EVENT2_Line_Trace: digest count 2
--

eventextend: line 4
TSS_EVENT2_Line_Trace: PCR index 7
TSS_EVENT_EventType_Trace: 80000001 EV_EFI_VARIABLE_DRIVER_CONFIG
TSS_EVENT2_Line_Trace: digest count 2
--

eventextend: line 5
TSS_EVENT2_Line_Trace: PCR index 7
TSS_EVENT_EventType_Trace: 80000001 EV_EFI_VARIABLE_DRIVER_CONFIG
TSS_EVENT2_Line_Trace: digest count 2
--

eventextend: line 6
TSS_EVENT2_Line_Trace: PCR index 7
TSS_EVENT_EventType_Trace: 80000001 EV_EFI_VARIABLE_DRIVER_CONFIG
TSS_EVENT2_Line_Trace: digest count 2
--

eventextend: line 7
TSS_EVENT2_Line_Trace: PCR index 7
TSS_EVENT_EventType_Trace: 80000001 EV_EFI_VARIABLE_DRIVER_CONFIG
TSS_EVENT2_Line_Trace: digest count 2
--

eventextend: line 8
TSS_EVENT2_Line_Trace: PCR index 7
TSS_EVENT_EventType_Trace: 00000004 EV_SEPARATOR
TSS_EVENT2_Line_Trace: digest count 2
--

eventextend: line 21
TSS_EVENT2_Line_Trace: PCR index 7
TSS_EVENT_EventType_Trace: 800000e0 EV_EFI_VARIABLE_AUTHORITY
TSS_EVENT2_Line_Trace: digest count 2
--

eventextend: line 24
TSS_EVENT2_Line_Trace: PCR index 7
TSS_EVENT_EventType_Trace: 800000e0 EV_EFI_VARIABLE_AUTHORITY
TSS_EVENT2_Line_Trace: digest count 2
--

eventextend: line 81
TSS_EVENT2_Line_Trace: PCR index 7
TSS_EVENT_EventType_Trace: 800000e0 EV_EFI_VARIABLE_AUTHORITY
TSS_EVENT2_Line_Trace: digest count 2

Comment 7 fwang#1@ilts.com 2020-07-22 15:48:00 UTC
Thank you Nicolas for prompt reply. 

Yes It looks like our setting are very similar. From boot console I always have boot issue like 2-3 out of 10 when Clevis Luks askpass service failed to run and then hang. Actually I am the newbie of this TPM stuff and I will test your way without specify to bind PCR 7 and 11. 

Right now based on my setup I add following 2 line in clevis-luks-askpass.service Unit section, then it boots and automatically unlock consistently, but I can not tell the reason. Why I add this 2 lines because every time it boots successfully, I see network online service started before Clevis Luks askpass service, I am afraid there is race condition? So I add 2 line to tell Clevis Luks askpass service to run after network online service. 

Wants=metwork-online.target
After=network-online.target

I will also try your encryption way and let you know my status. Thank you again.

Regards

Comment 8 nicolasoliver03 2020-07-22 19:37:49 UTC
In my case, I have those dependencies declared by default with the installed service. The network-online.target is reached when the loopback interface is ready, you don't actually need external network access.

[root@first ~]# rpm -qa clevis*
clevis-12-1.fc31.x86_64
clevis-luks-12-1.fc31.x86_64
clevis-systemd-12-1.fc31.x86_64
clevis-dracut-12-1.fc31.x86_64

[root@first ~]# systemctl cat clevis-luks-askpass.service
# /usr/lib/systemd/system/clevis-luks-askpass.service
[Unit]
Description=Clevis LUKS systemd-ask-password Responder
Requires=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/libexec/clevis-luks-askpass -l

[root@first ~]# systemctl cat clevis-luks-askpass.path 
# /usr/lib/systemd/system/clevis-luks-askpass.path
[Unit]
Description=Clevis systemd-ask-password Watcher
Before=remote-fs-pre.target
Wants=remote-fs-pre.target

[Path]
PathChanged=/run/systemd/ask-password

[Install]
WantedBy=remote-fs.target

I noticed that there is a typo in your "Wants=metwork-online.target" (should be network)

In the case that there is a service that needs to wait until your encrypted partitions are ready, you need to add a configuration for that.
Otherwise, your service may start (and fail) before your partition is mounted.
In my case, I have a partition for the Docker stuff mounted in /var/lib/docker.
To make the Docker service wait until that partition is unlocked and ready, I added this override configuration to the docker service

mkdir -p /etc/systemd/system/docker.service.d/
cat > /etc/systemd/system/docker.service.d/override.conf << EOF
[Unit]
After=var-lib-docker.mount
EOF

So then, docker.service start after the var-lib-docker.mount service.
var-lib-docker.mount is auto generated, and I actually don't know if it is clevis or the OS that generated them.
You can check your generated mount service name with 

$ systemctl list-units | grep '\.mount '

Comment 9 fwang#1@ilts.com 2020-07-23 00:04:18 UTC
Thank you so much Nicola. For point pout my typo helpful information you posted. You are very helpful and you are my life saver. :) Appreciated!

Right now I determine to encrypt SWAP or root (/) partition, I am wondering swap and / partition are all belongs to early boot. I am not sure if it will work in such a way. Have you ever tried encrypt Swap & root ( / )?

Comment 10 nicolasoliver03 2020-07-23 14:35:12 UTC
For the swap encryption, it is very simple:

I have my swap partition created as a LVM volume:

$ logvol swap --vgname system --percent=5 --name=swap

And then, the encryption configuration is done with the following line

$ echo "system-swap /dev/system/swap /dev/urandom swap,cipher=aes-xts-plain64,size=256" >> /etc/crypttab

For the root partition encryption, I got it working on Fedora Server, but Fedora IoT have some problems.
You can check the details in this bug https://bugzilla.redhat.com/show_bug.cgi?id=1688283

Hope it helps!

Comment 11 fwang#1@ilts.com 2020-07-23 16:27:01 UTC
I did encrypt my standard partition /dev/sda3 which is a swap when partition in installation.

swapoff -a ;
echo "YES" | cryptsetup open --type plain /dev/sda3 cswap
mkswap /dev/mapper/cswap ;

echo ""cswap /dev/sda3 /dev/urandom swap,cipher=aes-xts-plain64" >> /etc/crypttab

Then it works! Before I always failed. Probably since this race condition has been resolved. 

in case same issue happen, I took your suggestion to configure  to wait until my encrypted partitions are ready, everything works consistently so far! Thanks a lot!

Question: ever try encrypt swap via TPM?


Next I will try root ( / ) partition and let you know after.

Regards

Comment 12 fwang#1@ilts.com 2020-08-11 19:24:25 UTC
Hi Nicolas,

We are not deciding to encrypt root partition so far. But since I have added swap partition to be encrypted like:

echo "cswap /dev/sda3 /dev/urandom swap,cipher=aes-xts-plain64,size=256" > /etc/crypttab ;

echo "/dev/mapper/cswap swap swap defaults        0 0" >> /etc/fstab

It sometime boot still hang but very less. like 1 out of 50 hang. When it hang I could see my following 3 encrypted device in turn keep flashing..

A start job is running for dev-mapper-scwap.device   
A start job is running for dev-mapper-system.device  
A start job is running for dev-mapper-Enc.device

It looks like still has race condition in there.

Do you have any idea?

Regards,

Comment 13 Fedora Update System 2020-08-31 12:39:50 UTC
FEDORA-2020-b35219394f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b35219394f

Comment 14 Fedora Update System 2020-08-31 13:18:36 UTC
FEDORA-2020-d42f4e90f9 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d42f4e90f9

Comment 15 Fedora Update System 2020-08-31 15:55:53 UTC
FEDORA-2020-d42f4e90f9 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d42f4e90f9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d42f4e90f9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 16 Fedora Update System 2020-08-31 18:58:05 UTC
FEDORA-2020-b35219394f has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-b35219394f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b35219394f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 17 Fedora Update System 2020-09-07 17:13:49 UTC
FEDORA-2020-d42f4e90f9 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 18 Fedora Update System 2020-09-25 16:40:17 UTC
FEDORA-2020-b35219394f has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.