Page MenuHomePureOS Tracker

Decrypt prompt disappeared after update
Closed, DuplicatePublic

Description

I have a Librem 13v3 with Gnome 3.28 on PureOS (all updates, including now 5/11).

After doing a full-upgrade on 5/9, on powering on, the password prompt for decrypting the disk disappeared. I feared that I bricked my system. What I see instead appears to be the PureOS progress bar--not animated--only about 2mm x 30mm in area. (A picture of the screen is shown below, but its size is deceiving.) The system just sits at that point.

After waiting several minutes, I cycled the power a few times. Nothing changed. I finally just started typing the decryption password when I saw this bar. After getting about half-way through, the prompt appeared, with the characters I had typed filled in. The disk was decrypted, and I could boot.

The system also appears to be slower getting to what should be the prompt. It behaves almost as if it were timing out and then catching up, but too late to update the screen properly. (To reiterate, if I do not type anything, the prompt never appears.) I am not certain of this, however; it is subjective.

I did count characters typed on different iterations. The prompt appears with different numbers of typed characters, so that is not fixed. If I enter the password incorrectly, I get the proper prompt. If I blow it 3 times, I get the 60 second time-out and the proper prompt. So, this missing prompt appears only the first time through.

In this instance, I was alerted to the updates on 5/9 by the Apt Update Indicator extenson (v. 20), and I used it to do the update. It is customized to 'sudo apt full-upgrade' with 'xterm -e'.

I subsequently ran 'sudo apt remove' and I purged the remaining config file for the old linux-image-4.15.0-2.

In trying to fix this, I ran 'sudo apt update' and 'sudo apt full-upgrade' in a terminal. (I have also done another update.) I also tried the "upgrade fix": dpkg --config -a.

I am providing the boot.log and dpkg.log. I am also providing the system log output, but it is current. If others are needed, please let me know; I am uncertain which others are appropriate. (A file with just the 5/9 messages is also attached.)




I did not see any anomalies during the update or in the dpkg.log. I am uncertain if the messages in boot.log--lvmetab and crypt--are new or if they have been there all along.

I have done customizations to my environment, but I have not done a lot of additions. I had the extensions apt-update, disconnect-wifi, and dash-to-panel. Other software include meld and opencpn. (The latter is a nautical chart application. It is actually one thing I have marked 'hold' on upgrades due to a library requirement on the new version.)

This is not a show stopper; I seem to be completely functional. Unfortunately, I have no idea how to fix it or where to look. Thanks.

Event Timeline

Wayne created this task.May 11 2018, 05:32
wellton added a subscriber: wellton.May 12 2018, 03:52

Same problem here. My kernel is 4.16.8-gnu

Wayne added a comment.EditedMay 12 2018, 05:31

wellton reminded me....The 5/9 update was the upgrade to linux-image-4.16.0-1 pkg. I failed to explicitly mention that.

Update: I compared the output in 'messages' before and after the kernel update. I do not see a significant difference, but I have an untrained eye. This information needs sanitizing and "noise reduction". If someone knowledgeable can offer guidance on which components are important, I would post the 'message' contents too.

Wayne added a comment.May 14 2018, 05:10

Going back, I did notice something that might be interesting. On the first reboot after the update, vt.handoff=7 is missing.

Before,

Command line: BOOT_IMAGE=/vmlinuz-4.15.0-3-amd64 root=/dev/mapper/crypt-root ro quiet splash vt.handoff=7

After,

Command line: BOOT_IMAGE=/vmlinuz-4.16.0-1-amd64 root=/dev/mapper/crypt-root ro quiet splash

Please note that the vt.handoff=7 reappears on later reboots, but, because this parameter is display related, I thought it might be worth noting. Perhaps some related setting was changed in grub as a result.

Wayne added a comment.May 15 2018, 04:58

There are now two threads in the Purism forum regarding these issues. In this post:

https://forums.puri.sm/t/new-librem-13v3-won-t-boot-to-disk-login/3064/10?u=wayne

Kris posted a link to a discussion on the Debian blog:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572

It appears to be part of the same issue. (I am uncertain how this relates to the lvmetad and crypt messages.)

mak triaged this task as High priority.May 15 2018, 12:09
chris.lamb added a subscriber: chris.lamb.

Thanks for reporting - this is an (older) duplicate of T433; see there for the current status.

In T422#7589, @Wayne wrote:

There are now two threads in the Purism forum regarding these issues. In this post:
https://forums.puri.sm/t/new-librem-13v3-won-t-boot-to-disk-login/3064/10?u=wayne

What was the other one? :)