When LUKS is in use, I need to enter a password at boot. However, the prompt solely appears in the TTY when I begin to type:
Knowing when to enter it can be difficult because logs continue to appear, even when it’s visible. [1]
That sounds like a bug.
I use LUKS, it comes up with a grey screen and I have to unlock it before I can get to a TTY.
How did you install LUKS?
Did you install it at the same time as installing your OS from Anaconda?
@theprogram, during boot, press Escape before, or at, that prompt. Alternatively, before reboot, remove rhgb quiet from GRUB_CMDLINE_LINUX in /etc/default/grub:
@@ -1 +1 @@
-GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-$UUID rhgb quiet"
+GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-$UUID"
It does. However, would it be with Plymouth, DMesg, or LUKS?
Does it make any difference if you add quiet back?
1 Like
Plymouth.
Are you using theming for plymouth or some other customization?
1 Like
@yuntaz, yes, and slightly for the better. However, it now appears truncated, with the cursor misplaced, which I doubt is intended:
Additionally, the full prompt solely appears on type, as before:
@Augenauf, I’ve no custom style for Plymouth. Currently, my /etc/default/grub is:
GRUB_TIMEOUT="15"
# Original: GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
# Original: Identical
GRUB_DEFAULT="saved"
# Original: Identical
GRUB_DISABLE_SUBMENU="true"
# Original: GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="gfxterm"
# Original: GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-31b94f4a-915c-47ee-af7a-a7c948b23cf4 quiet"
# Original: GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-31b94f4a-915c-47ee-af7a-a7c948b23cf4 rhgb quiet"
GRUB_DISABLE_RECOVERY="false"
# Original: GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG="true"
# Original: GRUB_ENABLE_BLSCFG=true
# Reason: https://discussion.fedoraproject.org/t/missing-boot-entries-with-grub-enable-blscfg-true/70805/3
GRUB_GFXMODE="2560x1600,auto"
# Original: None
GRUB_DISABLE_OS_PROBER="true"
# Original: None
# Reason: https://github.com/MaddieM4/os-prober/issues/5#issue-777438588
Originally, I believe that it was:
GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT="saved" GRUB_DISABLE_SUBMENU="true" GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-31b94f4a-915c-47ee-af7a-a7c948b23cf4 rhgb quiet" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true
Therefore, I’ve solely modified some trivial content:
@@ -1,8 +1,22 @@ -GRUB_TIMEOUT=5 +GRUB_TIMEOUT="15" + # Original: GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" + # Original: Identical GRUB_DEFAULT="saved" + # Original: Identical GRUB_DISABLE_SUBMENU="true" -GRUB_TERMINAL_OUTPUT="console" -GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-31b94f4a-915c-47ee-af7a-a7c948b23cf4 rhgb quiet" -GRUB_DISABLE_RECOVERY="true" -GRUB_ENABLE_BLSCFG=true + # Original: GRUB_DISABLE_SUBMENU=true +GRUB_TERMINAL_OUTPUT="gfxterm" + # Original: GRUB_TERMINAL_OUTPUT="console" +GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-31b94f4a-915c-47ee-af7a-a7c948b23cf4 quiet" + # Original: GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-31b94f4a-915c-47ee-af7a-a7c948b23cf4 rhgb quiet" +GRUB_DISABLE_RECOVERY="false" + # Original: GRUB_DISABLE_RECOVERY="true" +GRUB_ENABLE_BLSCFG="true" + # Original: GRUB_ENABLE_BLSCFG=true + # Reason: https://discussion.fedoraproject.org/t/missing-boot-entries-with-grub-enable-blscfg-true/70805/3 +GRUB_GFXMODE="2560x1600,auto" + # Original: None +GRUB_DISABLE_OS_PROBER="true" + # Original: None
I’ve submitted it to:
I hope that doing so wasn’t premature.
I’ve tested this on a new Fedora 43 WS install, and it’s behaving the same.
Just wondering, tty being here a sequential prompt of everything logged, could it be that this is working as expected, even if not user-friendly enough? That is, even though the user is prompted for entering the LUKS password, there are other events recorded right afterwards and, hence, prompted? And this behavior is elegantly worked around with Plymouth, as the logs are not displayed?
EDIT: I wrote Fedora 42 above, but meant 43. Now corrected.
1 Like
I looked at the boot in this more verbose way today, and it works the same as Roke, except I do not have those blue error lines.
Which makes me think that as you say Mike, something keeps running while the LUKS prompt is up, and that there is a cable? error on Roke’s system.
1 Like
I don’t think this is an error only specific to @rokejulianlockhart 's system. As mentioned, I see some similar warning messages as well, even on a fresh F43WS install with encryption.
The messages as such should not be an issue either, they are part of logging and prompting the boot process. My understanding of the issue raised here is that those messages are displayed while the user is supposed to enter the passphrase, in which case the logged messages are expected to be withhold until the passphrase was entered.
@rokejulianlockhart , I wonder if Plymouth is the right component for the issue to be filed. Is it Plymouth in charge of prompts even when skipping the graphical boot?
1 Like
cryptsetup
??
1 Like
I was confused initially by Plymouth’s description:
In either text or graphics mode, the boot messages are completely occluded.
But then it says:
Also, the user can see the messages at any time during boot up by hitting the escape key.
So apparently it’s Plymouth in charge even in text mode.
(Source)
1 Like
@tqcharm, indeed, it’s not:
However, these kinds of extraneous circumstances default to vendor laptop configurations are exactly what we should be coping with as an OS, considering that they’re the most significant UX hurdles. I’ve already needed to remove rhgb boot due to a black-screen-on-boot bug that would catch most non-developer users (although I would have removed it anyway, because logs at boot are a phenomenal feature). Thereafter, not being able to see whether, or even when, one must enter logs, is an even worse UX failure.
2 Likes
It’s not even limited to Framework laptops. This is what I see in a VM installed on a Mac via UTM with Apple Virtualization:
1 Like
I believe this is working as intended.
Once the kernell knows that a LUKS passphrase is required it prompts for it.
But the kernel does not freeze waiting for you to type the passphrase.
It keeps running and as devices become ready messages are logged.
The UX that is clean depends on plymouth doing the prompting and hiding the logs.
1 Like
@barryascott, it can keep the LUKS log at the bottom, until the user begins typing.
That would mean that you must assume that the tty supports ESC sequences. And not all consoles do.
Also that the kernel adds the code to do split zone scrolling.
I doubt the kernel folks would approved such a patch.
@barryascott, considering that it outputs coloured text, it appears to.
Are you able to cite documentation on that? Searching for the term via Google yields no relevant results.
True!
However the code to split the screen into scrolling zones may not be implemented, it’s an advance vt200 feature and often a bugggy implementation.
You mean that there is a feature that sets the scrolling zones?
Absolutely, I’d have to dig out my VT400 programmers guide for the definitive docs. I use the feature in my Barry’s Emacs for its tty mode.
I’d have to look up the exact name of the feature for yout web search to find a hit.
2 Likes
@barryascott, thanks. If the Plymouth developers consider that to be a blocker after initial triage, I suppose that I can try taking it to kernel Bugzilla. At least there’ll be a record of the request when it’s inevitably rejected…
2 Likes