[opensuse] 13.2 LUKS boot problem (new, circa 16th December 2015)
Howdy... I have a system that mounts at boot two LUKS-encrypted partitions. Both swap and home are encrypted, with different passwords. Ordinarily, I am asked at boot for the passwords, one at a time, each time in an unlabeled graphical box consisting of a data-entry field and a padlock icon. Though the box is completely unlabeled as to which password it is asking for, I know from long experience that it is swap first wanted, then the box cleared and redrawn, then home password wanted. There has always been a quite sufficient wait-time while the machine waits for the data entry. Sometime around 16th December this changed. The process still works fine for the swap password, box is drawn and machine pauses awaiting the password entry, but the graphical box is never drawn for the second (home) password and the machine thus boots without mounting home. If I F12 the boot, I can see the request for the 2nd password scroll by in the text console, but it doesn't pause for data entry, immediately times out, and again boots without the second encrypted drive. If I immediately and quickly type the 2nd password as soon as I see it scroll by, it's accepted and home is mounted. If I'm a bit slow, it doesn't mount and reports an incorrect password in the log. I've looked at the logs after failed mounts and I see systemd messages reporting the failures, but the messages seem to be different each time. And I see no messages in there at all from the graphical boot thing (plymouth?) Any ideas what I should be looking at here? Thanks. Ralph My desktop is lxde (gtk) and the 13.2 os is: 3.16.7-29-desktop #1 SMP PREEMPT Fri Oct 23 00:46:04 UTC 2015 (6be6a97) x86_64 x86_64 x86_64 GNU/Linux -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/26/2015 12:17 PM, listreader wrote:
If I F12 the boot, I can see the request for the 2nd password scroll by in the text console, but it doesn't pause for data entry, immediately times out, and again boots without the second encrypted drive.
If I immediately and quickly type the 2nd password as soon as I see it scroll by, it's accepted and home is mounted. If I'm a bit slow, it doesn't mount and reports an incorrect password in the log.
I had the same problem. I had to turn on the THEMED KDE login screen back on in order to get a reliable pup-up box into which I could key in the password. I had been using the non-themed login, but it simply would not wait (or never showed up) since about the same time as you mentioned. Using themed I as able to get adequate time to enter a password. I too mount two luks partitions, but I have the passwords set the same and only have to enter it once. Apparently it tries to reuse the password before asking for the second password. I simply couldn't be bothered having two different passwords, and quite frankly can't see any point in it. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 26 Dec 2015 13:13:04 -0800
John Andersen
On 12/26/2015 12:17 PM, listreader wrote:
If I F12 the boot, I can see the request for the 2nd password scroll by in the text console, but it doesn't pause for data entry, immediately times out, and again boots without the second encrypted drive.
If I immediately and quickly type the 2nd password as soon as I see it scroll by, it's accepted and home is mounted. If I'm a bit slow, it doesn't mount and reports an incorrect password in the log.
I had the same problem.
I had to turn on the THEMED KDE login screen back on in order to get a reliable pup-up box into which I could key in the password. I had been using the non-themed login, but it simply would not wait (or never showed up) since about the same time as you mentioned.
Using themed I as able to get adequate time to enter a password.
I too mount two luks partitions, but I have the passwords set the same and only have to enter it once. Apparently it tries to reuse the password before asking for the second password. I simply couldn't be bothered having two different passwords, and quite frankly can't see any point in it.
Thanks John. I think the term is "hiding in plain sight". There is another unencrypted /home that mounts when the encrypted one isn't mounted on top of it. The two are almost identical except certain data is not available in the unencrypted version. No, it is not intended to fool professionals, but most problems encountered in life aren't caused by professionals, fortunately. Thanks for the confirm on the problem. If no one else responds to the post with ideas (hello! Carlos, are you there?) then I think I will do a bugzilla for this, though I'm not sure whether this is a systemd problem, a plymouth problem, or something completely else... Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
The bug filed for this is... https://bugzilla.opensuse.org/show_bug.cgi?id=960258 ...though I don't really expect anybody to even look at it till the holidays and the hangovers are all long gone. I have btrfs on the system partition and I think I have tracked the issue down to the multiple system changes of 12/16 (systemd, grub2, etc). But, I don't know enough about btrfs to attempt a rollback of so much simultaneously-changed and interlinked system stuff. Something I planned to learn back on 13.1 when I first tried btrfs but didn't ever get to. A *new* New Years resolution for 2016. Or 2017. ;-) SO... here's a workaround I found if anyone encounters the same problem: When asked for the password for the 1st encrypted partition, give it instead the password for the 2nd encrypted partition. It will immediately come back and again ask for the password of the 1st partition, which you can now enter correctly, but it will still remember the other password and will grab it from its' cache when needed and mount the 2nd partition properly in its time. Ok. At least I think that is what it is doing... Whatever. I can boot again! Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/26/2015 02:17 PM, listreader wrote:
If I F12 the boot, I can see the request for the 2nd password scroll by in the text console, but it doesn't pause for data entry, immediately times out, and again boots without the second encrypted drive.
Sounds like there was some update to the password input package and the developer changed from e.g. fgets to scanf and has forgotten to empty the input buffer after reading the first password, leaving the '\n' in the input buffer that is taken as your input for the second password call. It would be worth following up with whatever package handles the non-themed password input to insure there isn't a generic issue there. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
David C. Rankin -
John Andersen -
listreader