Plymouth LUKS password prompt does not show typing feedback on systems with RDNA3 AMD GPU (kernel 6.12)

Support
1

Bug Report: Plymouth LUKS password prompt does not show typing feedback on systems with RDNA3 AMD GPU (kernel 6.12)

Summary

On AlmaLinux 10.1 with LUKS full disk encryption and an AMD RDNA3 GPU (Navi 33 / RX 7600), the graphical LUKS password prompt (plymouth) is displayed but does not show any typing feedback. When the user types their passphrase, there is no visual indication that keystrokes are being registered (no dots, asterisks, or cursor movement). The user cannot tell whether their input is being accepted, making it appear as if the keyboard is not working.

Environment

  • OS: AlmaLinux 10.1 (Heliotrope Lion)
  • Kernel: 6.12.0-124.35.1.el10_1.x86_64_v2
  • GPU (dGPU): AMD Radeon RX 7600 (Navi 33, RDNA3) [1002:7480] at PCI 03:00.0
  • GPU (iGPU): AMD Radeon 680M (Rembrandt, RDNA2) [1002:1681] at PCI 77:00.0
  • CPU: AMD Ryzen 7 7735HS
  • Laptop: ASUS (hybrid graphics via ATPX)
  • Filesystem: btrfs on LUKS2 encryption
  • Plymouth theme: bgrt
  • Firmware package: linux-firmware-20260107-19.2.el10_1.noarch

Steps to Reproduce

  1. Install AlmaLinux 10.1 with LUKS full disk encryption and btrfs filesystem
  2. Use a system with an AMD RDNA3 discrete GPU (e.g., RX 7600)
  3. Boot the system with the stock kernel (6.12.0-124.35.1.el10_1.x86_64_v2)
  4. Observe the LUKS password prompt

Expected Behavior

The graphical plymouth LUKS password prompt should display typing feedback (dots/asterisks) as the user types their passphrase.

Actual Behavior

The graphical plymouth LUKS password prompt is displayed, but when the user types their passphrase, no visual feedback is shown – no dots, no asterisks, no cursor movement. It appears as if the keyboard is not responding. However, keystrokes are actually being registered – typing the passphrase blindly and pressing Enter does unlock the drive.

Pressing Escape to fall back to text mode shows a working text prompt with proper typing feedback as a workaround.

Root Cause Analysis

The boot sequence during initramfs is:

  1. simpledrm initializes and provides a working framebuffer (fb0)
  2. Plymouth starts and renders the LUKS password prompt on simpledrm – this works
  3. amdgpu module loads from initramfs for the dGPU (03:00.0, Navi 33)
  4. amdgpu takes over the display from simpledrm
  5. Plymouth’s password input field loses its rendering/refresh – the prompt is visible but typing feedback is not drawn
  6. The iGPU (77:00.0) also initializes but reports: [drm] Cannot find any crtc or sizes (the laptop display is connected to the dGPU, not iGPU)

The amdgpu driver in kernel 6.12 does not properly handle the DRM handoff from simpledrm during early boot on RDNA3 hardware, causing plymouth to lose the ability to update/refresh its password input display. The same hardware works flawlessly with kernel 6.18 (CachyOS kernel), where the amdgpu driver (v3.64.0 vs v3.63.0 in 6.12) handles the simpledrm-to-amdgpu transition correctly and plymouth remains fully functional throughout.

Additional observations

  • SMU driver if version not matched is logged for the dGPU (smu driver if version 0x35 vs firmware 0x40), indicating the kernel 6.12 amdgpu driver is behind the GPU firmware
  • The stock kernel has CONFIG_FB_EFI disabled (# CONFIG_FB_EFI is not set), while the working CachyOS 6.18 kernel has CONFIG_FB_EFI=y, removing one potential fallback framebuffer path
  • Both kernels have CONFIG_DRM_SIMPLEDRM=y (built-in)
  • Both initramfs images include the amdgpu module and all firmware files
  • The stock kernel builds btrfs as a module (CONFIG_BTRFS_FS=m), while CachyOS builds it in (CONFIG_BTRFS_FS=y), though both include it in initramfs

Workaround

Rebuild the stock kernel’s initramfs without the amdgpu module, so plymouth uses simpledrm (which works) for the LUKS prompt. The amdgpu driver loads normally from the root filesystem after LUKS is unlocked:

dracut --force --omit-drivers "amdgpu" \
  /boot/initramfs-6.12.0-124.35.1.el10_1.x86_64_v2.img \
  6.12.0-124.35.1.el10_1.x86_64_v2

This has no impact on GPU functionality after boot – amdgpu loads from /lib/modules/ on the real root filesystem as normal.

Suggested Fix

Consider one or more of:

  1. Backport amdgpu DRM handoff fixes from kernel 6.13-6.18 that properly handle the simpledrm-to-amdgpu transition during early boot
  2. Enable CONFIG_FB_EFI=y in the stock kernel config to provide an additional framebuffer fallback path
  3. Exclude amdgpu from initramfs by default when LUKS is configured, since simpledrm is sufficient for the password prompt and avoids the handoff issue entirely
  4. Update the SMU driver interface to match current AMD firmware versions (smu if version 0x35 is behind firmware’s 0x40)
2

Just a quick note: I am posting this bug report here in the Support forum because I was unable to log in to the official bug tracker. If a moderator can move this to the appropriate place, or if someone is able to reproduce it and file it there on my behalf, I would really appreciate it!

Update: Confirmed on other builds and upstream

To help narrow down the scope of the issue, I performed some additional testing:

  1. I tested the AlmaLinux 10.1 x86_64_v3 build, and the exact same issue occurs.
  2. I also installed and tested CentOS Stream 10, and the behavior is identical there as well.

This confirms that the bug is not specific to the x86_64_v2 build or unique to AlmaLinux, but rather an upstream issue present in CentOS Stream 10 (and likely RHEL 10 beta).

3

Hi, thanks for the detailed report.

Since this reproduces on CentOS Stream 10 as well, it looks upstream. The right place to report it is the CentOS Stream / RHEL issue tracker, and it should be filed by the original reporter (I can’t file bugs on someone else’s behalf).

If you can, please open an upstream ticket and include your hardware details, kernel version, and the dracut workaround (--omit-drivers "amdgpu").