Reboot after udate-initramfs prompts user twice for disk encryption password
Closed, ResolvedPublic

Description

On a VM installed from the live installer, I ran update-initramfs -u after the install and initial reboot. Then I rebooted again, whereupon I was prompted for my disk encryption password a second time (for the other luks partition) after I had already entered it successfully.

As you can see from the screenshot, it even says that cryptsetup says it was set up successfully for one partition but yet I need to enter the password again for the second partition. I believe the password should only be applied to one partition, thus being prompted only once to unencrypt.

Additional reboots have the same behavior, being prompted to unencrypt both partitions.

Behavior seen with https://downloads.puri.sm/live/gnome/2018-08-26/pureos-8.0-gnome-live_20180826-amd64.hybrid.iso

After the update-initramfs and reboot, I always get prompted to decrypt the / partition first and then prompted to decrypt the swap partition second (checked the uuid's against lsblk to determine this). This order is always preserved.

mak added a comment.Aug 27 2018, 5:25 PM

Hmm, swap should not even be password-encrypted...
What's the content of your /etc/crypttab?

The non-comments in /etc/crypttab are:

luks-5bdc5cfe-a86a-469c-812f-92b36f70113e UUID=5bdc5cfe-a86a-469c-812f-92b36f70113e     none luks
luks-6c7421c7-77e9-49eb-b902-16439cc1366b UUID=6c7421c7-77e9-49eb-b902-16439cc1366b     none luks
This comment was removed by heather.ellsworth.
mak triaged this task as "High" priority.Aug 29 2018, 3:36 PM

This /etc/crypttab is wrong, one line should have been set to auto-format swap.
Did you do manual partitioning, or did you select the default option?

I selected the default partitioning option.

mak added a comment.Aug 29 2018, 3:40 PM

You can fix this by changing the parameters of whetever is your swap partition to /dev/urandom swap,cipher=aes-xts-plain64,size=256,
e.g.:
luks-aaaaaaaa-a86a-469c-812f-92b36f70113e UUID=aaaaaaaa-a86a-469c-812f-92b36f70113e /dev/urandom swap,cipher=aes-xts-plain64,size=256

mak added a comment.Sep 2 2018, 5:23 PM

What should actually happen here is / being decrypted with a password, and swapfs being decrypted with a keyfile on /.
Or, as a second option, swapfs being reformatted at boot time.

mak added a comment.Sep 2 2018, 8:05 PM

@mladen.pejakovic That's a different issue that was already fixed a while ago.
The one in this bug is actually even older and has been in PureOS forever (we just didn't see it because initramfs updates aren't triggered that often, and it is not that severe in its impact).

mak added a comment.Sep 2 2018, 10:14 PM

I fixed this bug, which unfortunately brought us another (already known) bug of the swap partition not unlocking properly.

mak closed this task as "Resolved".Sep 4 2018, 9:59 PM

This issue, as well as all reboot failures related to missing swap partitions are now addressed in the latest PureOS images.
In total, this issue and issues related to it consisted of 5 completely separate issues affecting various aspects:

  1. cryptsetup update changing behavior (initial OEM failure, was resolved quickly)
  2. live installer using UUID to identify swap partition, while the UUID is constantly changing due to reformatting of the swap partitions on PureOS
  3. not enough entropy at early boot
  4. installer not setting device mapping correctly for the initial OEM boot, hence some crypttab lines were missing on first boot after initial setup, but subsequent boots after an initramfs update failed
  5. OEM crypto setup not writing /etc/crypttab to disk before update-initramfs was called. This was no changed, so no buffered writes to crypttab are made and we ensure all changes are flushed to disk.

Please test the new images!
GNOME Live: https://downloads.puri.sm/live/gnome/2018-09-04/
GNOME OEM: https://downloads.puri.sm/oem/gnome/2018-09-04/

jsbret added a subscriber: jsbret.Sep 6 2018, 3:31 AM

@mak

I have reported a problem
3-steps-needed-to-start-using-laptop-instead-of-2-steps-before
which Mladen linked to this tracker.

I have updated to the latest pureOS image today but I still have the problem. Let me describe it.

After the OS update from 3 weeks ago this is the message I see on my screen just after pressing the power button to start up my laptop:

first screen

I don't have to input my encryption password for this first screen. After pressing Enter and after the system takes around 10 seconds to move on, I get to the usual encryption password screen. This second screen requires the proper password to be input. If a wrong password is input then the system stays on this screen.

second screen

Before I started having this issue 3 weeks ago, after pressing the power button to start my laptop, I would directly get the second screen asking for the encryption password.

This is not ideal to now have a third step inserted that requires to press Enter + waste an additional 10 seconds durint the startup process.

I don't know if the problem I am describing here is related to the issues you have resolved in this tracker.

Appreciate any help to solve my issue.

Thanks.

mak added a comment.Sep 17 2018, 12:22 AM

@jsbret This very much sounds like a different issue that was solved a while ago. Check your /etc/default/grub for GRUB_ENABLE_CRYPTODISK, that option and associated settings should not be enabled (otherwise GRUB tries to decrypt /, which it shouldn't attempt to).

@mak Thanks for the advice. I commented the line

#GRUB_ENABLE_CRYPTODISK=y

and restarted the laptop twice. But that did not solve my issue.

According to recent posts on my initial thread
3-steps-needed-to-start-using-laptop-instead-of-2-steps-before
other users have had the same issue.

Would be good to find a solution.

My /etc/default/grub file currently looks like this after the change you proposed:

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=‘PureOS’
GRUB_CMDLINE_LINUX_DEFAULT=“quiet cryptdevice=UUID=708e0d88-4db9-4713-a5ac-aea1abe6e832:luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 root=/dev/mapper/luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 resume=/dev/mapper/luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 splash”
GRUB_CMDLINE_LINUX=""
mak added a comment.Sep 17 2018, 12:44 PM

@jsbret Replace the
GRUB_CMDLINE_LINUX_DEFAULT=“quiet cryptdevice=UUID=708e0d88-4db9-4713-a5ac-aea1abe6e832:luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 root=/dev/mapper/luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 resume=/dev/mapper/luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 splash”
line with
GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash”
ensure GRUB_ENABLE_CRYPTODISK is commented out and then run sudo update-grub and you should be fine.

Problem solved! Thank you so much @mak

Add Comment