I installed Manjaro with the option encrypted installation.
When I boot Manjaro the password prompt shows up but disappears within I guess 3 seconds and I get a black screen. Afterwards I’m not able to complete the password because even if I type in blindly nothing happens.
I’m aware of US keyboard layout at boot time.
It’s not Manjaro related, I know, the same happens when using clonezilla with “luksOpen” to unlock a partition.
Is it possible to adjust the timeout for password inputs?
Does it stay the same when you hold lets say F1 while booting, to show the menu?
If the prompt doesn’t disappear in that case, you should adjust your timeout setting in /etc/default/grub and re-generate your grub-config…
I changed the topic title to better reflect your problem
yes, I am using Grub. I configured the Grub menu to be hidden at startup (a checkbox somewhere in grub-editor). I could test enabling the menu itself and see if it causes any changes in boot behaviour.
I actually have an unencrypted installation but some more luks partitions and disks. They behave the same way.
If I can’t reproduce my issue with just unlocking other partitions than /root then I will reinstall encrypted and test again. Could take some time but I’ll report back .
If I choose “unlock at startup” for my 2nd internal disk and reboot the following sequence is performed:
Grub menu comes up
I choose my installed Manjaro
Password prompt shows for approx. 2 secs
Proceeds to login screen
The disk remains locked and when I restart or shutdown my machine the password prompt is again visible for a second. Then reboots/shuts down.
to fstab doesn’t change the behaviour. Adding to crypttab also doesn’t change it. The password prompt is visible for about 1 sec and then proceeds to login screen.
The x-systemd.device-timeout only changes the time systemd waits for the device to appear in the system, eg the device gets connected to your machine…
So it won’t make a difference in this case…
I guess the issue here is that by default the password for the 1st drive is tried automatically for your 2nd drive and fails, but this failure is not handled correctly inside the code that is responsible for unlocking your drives inside the initrd…
Do you happen to have a graphical animation at boot and/or have splash included in your kernel command line options?
If so try to disable one or both of those to see if it makes a diff…
You could also check the kernel logs starting from the moment the kernel gets booted to see if any possible errors are shown related to your drive and unlocking of it…
One of these might be used to inspect the kernel logs:
sudo dmesg --human
This will only show kernel messages from current boot.
journalctl --boot x
This can show kernel messages from current and previous boots.
Where x should be 0 for current and a negative number for previous boots, eg -1 is last boot before current, -2 one boot before the one shown with -1 etc…
I hope other people can be more of assistance here, because im not quite able to assist much in this topic, both because of lack of info and real life (Earthquakes in Turkey).
I will look into this, thanks. I still have some errors at shutdown which I wanted to investigate and remove. So thanks for the hints with kernel messages (I am completely new to debugging that stuff).
For my problem I found a hint in the arch wiki which I will try first:
Warning:
If the nofail option is specified, the password entry screen may disappear while typing the password. nofail should therefore only be used together with keyfiles.
As I used keyfiles before it’s possible that the “nofail” option is still there…
My fault. I’ll try…
Still not working. A full encrypted installation always shows password prompt for about 2-3sec and then I get a black screen. Sometimes the password can be entered even when the black screen is present and sometimes nothing happens. Even when Manjaro proceeds after entering the password the boot screen (three dots and Manjaro logo) keeps hanging sometimes. I don’t get Manjaro running without boot issues when it’s fully encrypted.
I also can’t use my Nitrokey to unlock the encrypted root partition because grub needs luks1 and luks1 can’t be unlocked by FIDO keys…
I’m back on unencrypted setup with /home encrypted by eCryptFs for now.
There where threads and opinions and messages (in the past) strongly discouraging the use of such tool(s).
It often lead to problems that didn’t need to be there when a simple editor was used instead to just … edit /etc/default/grub
I don’t understand what that means - perhaps I have not looked intently enough …
With a fully encrypted system, I have never had any sort of timeout of the prompt to unlock the system.
It just keeps sitting there until one does … something.
Wrong password leads to the need to power down and start again - there is only one try.
I was usually pretty fast to input the password because the fan starts screaming really quickly while just waiting for input … but there was never a timeout.
That is a very, very strange statement (to me).
Because, what that would mean is, that once you booted a live system
and then attempted to open the encrypted container,
to get access to the file system within,
there would be a timeout as well.
That makes absolutely NO sense to me.
FWIW and in my opinion:
there is no way that that can even happen.
… no “mechanism” that could even do that
Maybe you should drop grub and use systemd-boot
For a password-less full disk encrypted work flow, you could check my tutorial i have linked in my profile as “Featured article”
Maybe you can adjust that to use your FIDO key instead of a fixed password inside the initrd…
(I used that approach to boot from an external USB-Stick in the past, which holded my ESP plus kernel+initrd…)
I’m aware of that. I’m relatively new to Manjaro and don’t perform the most tasks by editing just the conf-files. I know it’s the easier way, I’m still Windows sick and just have to change my behavior on getting things done the straight and easy way. Be patient with me
I mixed things up a bit. That means that I have a second hdd (an extra data-hdd, not the boot hdd) that I have encrypted and used to unlock with a keyfile. I also tried to unlock this data-hdd on startup by entering a passphrase and not with the keyfile (by removing option “nofail” and removing the keyfile) but it resulted in the same startup behavior as before what means: while booting the password prompt showed up and a black screen after 2-3sec then proceeded to login screen. When I shutdown my PC the password prompt shows again for a sec (on the screen where normally some pre-shutdown output is shown) even if the disk has been unlocked meanwhile .
For me it’s the other way round. I never had a password prompt waiting for me to input a passphrase…unfortunately.
That’s what I actually experience. If you like I can try to share a video to demonstrate that.
Maybe all this behavior has to do with a BIOS setting or sth.? Is that possible? Some kind of watchdog killing the boot sequence?
It would be a good start if you tell us facts about your system: inxi --admin --verbosity=7
for instance.
And, re your mention of having used some “grub-editor”:
what software was/is that?
Also the contents of /etc/default/grub
could help others help you: grep -v ^# /etc/default/grub
lists only the uncommented lines - not everything in the file
/etc/fstab as well would be potentially helpful
IMO: what you see happens after grub has decrypted the container your base system is in - the system is already booting at that point
Package: grub-editor (AUR). Was only used when trying to unencrypt an external hdd at startup.
I’m currently running an unencrypted Manjaro because encrypted doesn’ t work for me. I can’t unlock at boot.
The video was recorded while rebooting after initial installation of Manjaro Sikaris 22.0.4. Encrypted ext4 setup with swap (also encrypted when encrypted installation is chosen). Not logged in once, everything default configuration.
