You are not logged in.
I just did the usual routinely "apt update && apt upgrade" on my Lenovo Thinkpad t460p.
Normal setup is: TP under the desk in a dock, USB switch for keyboard/mouse, 2 external monitors, TP shut, internal LCD switched of.
Usually no problem. Now after the upgrade, this behavior:
System is tarting, keyboard working,
Linuy startscreen, still working,
Boot messages starting, power for keyboard and mouse of.
-PW for HDD encryption input (no keyboard)
(after fiddeling the Dock and TP from under the desk including messing up all neatly placed cables,)
HDD PW typed in with the internal keyboard, after which the external keyboard is usable immediately.
Any idea how to fix that?
Offline
What are we talking about? Chimaera, Daedalus, Excalibur? Anything else?
Online
Mea culpa.
daedalus.
(Reminder to myself: do not post while having migrane)
Offline
Was a new kernel installed?
Boot the previous one again (grub menue: advanced options ... -> ). Does the problem remain?
Or anything suspicious in apt's log?
/var/log/apt/term.log or /var/log/apt/history.log
Offline
term.log has a bunch of lines like this
W: Possible missing firmware /lib/firmware/i915/..
But that should result in either working or not working hardware and not in sometimes not working hardware?
(Plus those were there before)
kernel changed form 6.1.0-18-amd64 to 6.1.0-27-amd64. (give me some minutes to test that)
Previous kernel doesn't has the problem.
Last edited by mclien (2024-11-23 11:29:00)
Offline
i915 firmware is graphics. Nothing to do with the keyboard. To get rid of the message, enable non-free-firmware in the sources.list and install firmware-misc-nonfree (if not already present).
Sounds like a possible problem with the initramfs. No idea how to fix that.
You could try a backports kernel.
Online
Since the whole USB sub-system seems to be unavailable at that point, I think it might be related to:
https://lists.debian.org/debian-kernel/ … 00231.html
Offline
It may be worth to consider that the software used for entering a decryption password prior to boot has nothing to do with the kernel or with anything on the encrypted part of the disk.
Offline
To clarify things. We are talking LUKS encryption, so that is first thing after boot, if I'm not mistaken.
Also kernel 6.1.0-18-amd64, 6.1.0-27-amd64 does not.
Offline
Right. Yes, I mistook it for full-disk encryption.
WIth only the root filesystem encrypted the kernel and initramfs would be involved. And it needs the initial udev run to handle USB; you've tried unplug + plug in while it's waiting for input?
Upgrade of kernel should not in itself have effects on the initrd except for possible differences in the module setup. Though there may be interesting effects in process handling, and especially in this case there is an inherent race between udevd handling USB and cryptsetup reading password.
You can investigate the race option by locating the cryptsetup invocation in the scripting, either "/etc/initramfs-tools/..." or "/usr/share/initramfs-tools/...", and introduce a "sleep 5" before it (then update-initramfs and reboot).
Offline
I did plug and unplug the USB input devices (several time, several USB ports, at the docking station as well, as notebook ports directly). Seems all USB ports aren't even powered at that time (using my optical mouse as an indicator: LED on/off?).
What I found is this: (in usr/share/initramfs-tools/)
scripts/local-block/cryptroot
scripts/local-top/cryptroot
But my skills aren't that high on this area to understand what to do in which script (can't pinpoint which is the invocation or if these are the right scripts in the first place).
So I guess I'm stock with using my previous kernel, till there might be a change in the initramfs tools.
What further information should I gather to do a bug report for this?
Offline
Well, I'd say those scripts are the right ones so adding "sleep 5" early on but not at the very top in them would be the test.
1. add a new line with "sleep 5"
2. run "update-initramfs -u -k all"
3. reboot
If a process race is happening and the cause for the issue, then those "sleep" should delay the decryption handshake enough to allow udev to do its thing beforehand.
Offline