I’m running the latest stable release of Manjaro on a Dell Latitude E7470.
After the most recent update, I was prompted to restart my system, and did so. Upon reboot, I got a text-based prompt for my LUKS encryption password, as usual. I entered it, but instead of continuing to boot, the system presented a graphical prompt to enter the password again.
The real problem is that I cannot actually enter the password – nothing happens when I type.
I try typing the password and hitting Enter anyway, despite the lack of visual feedback, but still no response. Mouse and touchpad seem to be inactive at this point too. So I am effectively locked out.
Have you tried turning it off and on again?
With the kind of full disk encryption the Manjaro installer creates, you have but one chance to enter the password correctly, you don’t get a second try.
If yes - what is the version of plymouth on your system?
pamac -Qi plymouth
Plymout exist in two versions - one with stable and testing - and a newer in unstable and upstream
$ mbn info plymouth -q
Branch : archlinux
Name : plymouth
Version : 24.004.60-8
Repository : extra
Build Date : Sun 07 Jul 2024 19:11:32
Packager : Balló György <bgyorgy@archlinux.org>
Branch : unstable
Name : plymouth
Version : 24.004.60-10
Repository : extra
Build Date : Sun 07 Jul 2024 20:12:55
Packager : Mark Wagie <mark@manjaro.org>
Branch : testing
Name : plymouth
Version : 22.02.122-18
Repository : extra
Build Date : Tue 07 May 2024 16:47:12
Packager : Philip Mueller <philm@manjaro.org>
Branch : stable
Name : plymouth
Version : 22.02.122-18
Repository : extra
Build Date : Tue 07 May 2024 16:47:12
Packager : Philip Mueller <philm@manjaro.org>
Did you attempt to disable plymouth and remove it from your system ?
Thx for the suggestion. But yes, I have turned it off and on again several times. I am confident I’m entering the password correctly for two reasons:
it’s the same password I’ve had all along (since I began using Manjaro several months ago), and prior to this latest update I had no problem with it
after entering the password at the initial text-based prompt, I see “Slot 0 opened” which has always been the indicator that decryption worked and boot-up may proceed
It’s only at the 2nd prompt that it doesn’t seem to respond to anything I type.
I have no idea why you would be prompted for a password for a second time after the initial decryption was successful.
That is abnormal.
Why? I could only speculate.
If I was in your place, I’d boot from USB, chroot and run a possibly unfinished system update
as well as check some configuration files
namely: /etc/default/grub /etc/mkinitcpio.conf /etc/fstab
and recreate the initrd’s
mkinitcpio -P update-grub
chroot is easy, but not as easy as if your system was not encrypted
automatic mode of the tool manjaro-chroot won’t work
and you need the open the container first and assemble the file system at a mount point yourself
This isn’t may a solution for you (it depends), but may i ask you… why you using Luks boot encryption at all?
I mean on a mobile Laptop, which can be physically stolen… it could make sense, but only if your system is powered down.
In most use cases i see mainly people NOT thinking enough about it, what to archive when encrypting the root partition!
You gain alot more data protection, when you encrypt a secondary partition in your system, which doesn’t required to be always unencrypted while the system is powered ON 24/7.
Like i do with veracrypt for example… which gives you different option to encrypt a folder or just a full partition (just don’t use it on Root or Home) and your stuff is much better protected, specially when you using program’s like discord,steam and their game launcher (tencent for example) or other Telemetry stuff which snooping around.
Root encryption mostly just sucks, when you change your folder’s and files to other locations, its just working better.
You never know whether or when or why you get unwillingly separated from your property.
It has been some time that I booted my encrypted system (Arch/EOS with unencrypted /boot).
I’m not sure anymore how it behaved after when I put it to sleep and woke it up.
But with suspend to disk it would not unlock without the decryption password.
A plus for me is:
I can, for example, just sell the whole thing as it is, and no one would be able to get to anything on that disk (except the contents of /boot).
Or I can take out and sell and replace the HDD - as it is.
No chance of anyone getting access to any important data on it.
They can use it - put their own stuff on it.
But no one will be able to get to what was on there before.
There was recently (yesterday?) a question of someone who wanted to sell his system
and wanted to know how to securely erase the data on the drive.
No need to do that with an encrypted system …
Brain connection, i had exactly this thoughts in my mind as i was reading this article.
But i was thinking this isn’t a good solution (i was not sure if deleting several times a HDD or encrypt it in retrospectively is more effective) and let this topic untouched.
… whenever I carry my Laptop (which is my only computer) outside my home
I’ll never carry it in sleep state.
Reason being:
I never know how long it will take - the battery may run low and the sleep state might be lost due to that.
As I said:
I can’t remember how it behaved when it was put to sleep and woken up.
I think I still got the decryption prompt - not sure though.
I’d need to check.
For suspend to disk - my swap is a swap file - and it is inside the encrypted /
I can’t imagine a way to just wake up and run without unlocking access to that.
@Nachlese and @Kobold, thank you both for the insights in this thread!
My reasons for using LUKS in the first place are pretty much like @Nachlese said – just wanting protection for my entire hard drive should the laptop be lost or stolen. That plus the fact that it’s an option during the Manjaro installer, so was very easy to set up. (And yes, I do either shut down all the way or suspend to disk when I’m on the go.)
I’ve had it this way for years (albeit not always with Manjaro) and had no problem… until now. So with all that being said, I really like @Kobold’s suggestion of encrypting a secondary partition and putting anything I care to protect there, so I’m not stuck when something goes wrong with root.
For now… I have the earlier suggestions from @Nachlese and linux-aarhus to try, but these of course will require booting from USB, then decrypting, mounting, and chroot-ing into my hard drive so I can poke around. I will update here if/when I find the answer…
Thank you for the response! The prompt I’m getting looks very similar to the one you linked. Input field is outlined as if it has focus (though nothing happens when I type), and has the same lock icon on the left. Text below the input is different, but no doubt that could vary based on version, etc.
So I’ll guess it is plymouth. But for any further info I’ll have to boot from USB, etc as mentioned elsewhere in the topic. Will post again when I’ve had a chance to do so.
do not mount anything (no file manager action trying to access the encrypted partition)
lsblk -f will tell you about the layout and names
open the encrypted container: cryptsetup open /dev/sdxY encr (the “encr” is just a name you can freely choose)
you’ll be asked for the password
there will now be a device called /dev/mapper/encr which is your decrypted volume
mount that to /mnt (for example): mount /dev/mapper/encr /mnt
then chroot, using the manjaro-chroot tool, this would look like: manjaro-chroot /mnt /bin/bash
Then you should be inside your system and can look around, run updates etc.
Having a file manager in this TTY (text) mode can be very helpful.
I use mc for that - but there are others, like ranger. mc is small and easily installed - try it if you haven’t yet pacman -S mc
usually works even on the live system, even without refreshing mirrors or syncing
@grundyunderhill I think I recognise what’s happening; you’ve got two partitions encrypted with different passwords. You decrypt the boot partition with your password (the text based part), getting you into Plymouth, but then the second partition apparently can’t be unlocked with the same password so you get a second prompt - although this one is graphical, because the boot partition is unlocked.
To fix, you’ll want to boot off a USB and check the encryption on all partitions - including the swap partition. You should be able to do this via any of the standard GUI tools. I imagine at least one partition won’t open with your password. If you can’t unlock it then you could either delete it from /fstab (i.e. stop it from auto mounting so you can boot), or if it’s swap, just recreate the partition (making sure to put in the correct password).
Although if you have a non-ANSI keyboard, also note that special characters might be mapped a bit differently within the text based password entry compared to Plymouth / booted into Linux.
Source: I accidentally did this to myself, when trying to set an ANSI keymapped version of my password.
