[MacbookPro 14,1] dm crypt unlock prompt doesn't respond to key presses in kernel 6.5 (but 6.2 works)

[Andrew]

After upgrading my MacbookPro 14,1 from 23.04 to 23.10 dm-crypt unlock prompt doesn't respond to key presses and I'm not able to type in my password to unlock the disk.
The only option that works now is to boot with the kernel left from 23.04 (6.2.0-35-generic).
Any tips to troubleshoot the issue would be much appreciated.

% lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 23.10
Release: 23.10
Codename: mantic

ProblemType: Bug
DistroRelease: Ubuntu 23.10
Package: plymouth 22.02.122-3ubuntu2
ProcVersionSignature: Ubuntu 6.2.0-35.35-generic 6.2.16
Uname: Linux 6.2.0-35-generic x86_64
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Sun Oct 29 10:25:26 2023
DefaultPlymouth: /usr/share/plymouth/themes/bgrt/bgrt.plymouth
InstallationDate: Installed on 2023-04-22 (190 days ago)
InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Release amd64 (20230418)
Lsusb:
 Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Lsusb-t:
 /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
 /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
 /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
 /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
ProcCmdLine: BOOT_IMAGE=/vmlinuz-6.2.0-35-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash vt.handoff=7
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.2.0-35-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash vt.handoff=7
SourcePackage: plymouth
TextPlymouth: /usr/share/plymouth/themes/ubuntu-text/ubuntu-text.plymouth
UpgradeStatus: Upgraded to mantic on 2023-10-27 (2 days ago)
dmi.bios.date: 08/22/2022
dmi.bios.release: 0.1
dmi.bios.vendor: Apple Inc.
dmi.bios.version: 499.40.2.0.0
dmi.board.name: Mac-B4831CEBD52A0C4C
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookPro14,1
dmi.chassis.type: 9
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-B4831CEBD52A0C4C
dmi.modalias: dmi:bvnAppleInc.:bvr499.40.2.0.0:bd08/22/2022:br0.1:svnAppleInc.:pnMacBookPro14,1:pvr1.0:rvnAppleInc.:rnMac-B4831CEBD52A0C4C:rvrMacBookPro14,1:cvnAppleInc.:ct9:cvrMac-B4831CEBD52A0C4C:sku:
dmi.product.family: MacBook Pro
dmi.product.name: MacBookPro14,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

[Mike Ferreira (mafoelffen)]

RE : https://ubuntuforums.org/showthread.php?t=2492034

Just my thoughts to add to this... I asked him to file his bug report.

He originally though it had something to do with cryptsetup. I felt it wasn't a dm-cript or LUKS problem.

He filed this bug against Plymouth, because I guess he thought it happened during Plymouth boot. Lunar & Mantic use the same plymouth package version... So I do not think that would not affect it in the release upgrade.

I asked this user to file his bug against package console-setup, as that is what controls the keyboard mapping files during that process period, and Lunar & Mantic have different versions of that package between them. That is what I suspect. But filing it against plymouth did not collect that information for you.

Sidenote: apport-collect failed for this user here with a permissions problem, and failed to collect boot.log
...
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
...
Permission for that log is now:
-rw------- 1 root root 0 Oct 16 00:00 /var/log/boot.log
...which you cannot open it without explicitly being the root user. Does that need to be reported to fix apport-collect? Should I open a bug on that? --> Filed: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2041737

[Andrew (pid0)]

% cat /etc/default/keyboard
# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="gb"
XKBVARIANT=""
XKBOPTIONS=""

BACKSPACE="guess"

[Andrew (pid0)]

% cat /etc/default/console-setup
# CONFIGURATION FILE FOR SETUPCON

# Consult the console-setup(5) manual page.

ACTIVE_CONSOLES="/dev/tty[1-6]"

CHARMAP="UTF-8"

CODESET="guess"
FONTFACE="Fixed"
FONTSIZE="8x16"

VIDEOMODE=

# The following is an example how to use a braille font
# FONT='lat9w-08.psf.gz brl-8x8.psf'

[Sebastien Bacher (seb128)]

The description suggests that booting an old kernel workaround the issue? If it's specific to a kernel update then it would probably make it a kernel issue?

[Benjamin Drung (bdrung)]

Can we exclude that a missing kernel module in the initramfs might be the culprit? Please collect following information:

1. Can you attach the output of the command 'lsmod' on a booted system?
2. Can you attach the kernel modules in the faulty initramfs from mantic (/tmp/faulty-initramfs-modules.log):

lsinitramfs /boot/initrd.img-6.5.*-generic | grep '\.ko\.zst' | sed 's@.*/\(.*\).ko.zst@\1@' > /tmp/faulty-initramfs-modules.log

3. Filter the modules on a running system compared to the faulty initramfs:

for module in $(lsmod | cut -f1 -d' '); do if ! grep -q "^${module}$" /tmp/faulty-initramfs-modules.log; then echo $module; fi; done | sort

[Steve Langasek (vorlon)]

On Mon, Oct 30, 2023 at 07:35:54AM -0000, Sebastien Bacher wrote:
> The description suggests that booting an old kernel workaround the
> issue? If it's specific to a kernel update then it would probably make
> it a kernel issue?

This is not proof that it's a kernel issue. The new kernel will have a new
initrd generated with userspace from the new release, the old kernel will
have an initrd generated with userspace from the old release.

The one thing I can say is that it's NOT a console-setup bug, that has
nothing to do with WHETHER the keyboard works, only with what keymap is
used.

Has anyone independently reproduced this on different hardware? (Or in a
VM)

[Andrew (pid0)]

Attaching output of lsmod

[Andrew (pid0)]

lsinitramfs /boot/initrd.img-6.5.*-generic | grep '\.ko\.zst' | sed 's@.*/\(.*\).ko.zst@\1@' > /tmp/faulty-initramfs-modules.log

[Andrew (pid0)]

for module in $(lsmod | cut -f1 -d' '); do if ! grep -q "^${module}$" /tmp/faulty-initramfs-modules.log; then echo $module; fi; done | sort > running-vs-faulty-modules.txt

[Andrew (pid0)]

Today I installed 6.5.0-14 kernel and it resolves the issue.
It would be interesting to know what has changed.