Early KMS - Screen refresh botches up dm_crypt prompt

snarch · 2024-01-15 23:05:20

Hi,

I think I have early kms correctly configured. I use full encryption with dm_crypt and get a key prompt during boot. Now early kms seems to refresh my screen during the boot process, which causes a one second long black screen. After the picture comes back, the prompt for the dm_crypt key gets all scrambled and suddenly my input is in the middle of the screen.

Here is a video of it. You can see the key cursor in the middle. https://streamable.com/b1b03c

If I remove kms from mkinitcpio.conf, this does not happen. But I'd like to use early kms anyway. Is there anything I can do about it?

It's an integrated GPU from a Ryze 5xxx CPU.

Thanks

Last edited by snarch (2024-01-15 23:11:22)

seth · 2024-01-16 09:18:05

Post your /etc/mkinitcpio.conf - afaict the hook order somewhat matters.

snarch · 2024-01-16 12:08:09

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(usbhid xhci_hcd)
MODULES=()

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=()

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=()

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No RAID, lvm2, or encrypted root is needed.
#    HOOKS=(base)
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS=(base udev autodetect modconf block filesystems fsck)
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS=(base udev modconf block filesystems fsck)
#
##   This setup assembles a mdadm array with an encrypted root file system.
##   Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices.
#    HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
#
##   This setup loads an lvm2 volume group.
#    HOOKS=(base udev modconf block lvm2 filesystems fsck)
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)

# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="zstd"
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()

# MODULES_DECOMPRESS
# Decompress kernel modules during initramfs creation.
# Enable to speedup boot process, disable to save RAM
# during early userspace. Switch (yes/no).
#MODULES_DECOMPRESS="yes"

I did try to put kms right after the systemd hook once, but that did not change anything.

Martinsos · 2025-11-18 11:57:59

Exact same issue here, also on AMD cpu+gpu (integrated).

My HOOKS are the same, only keyboard was moved before autodetect.

HOOKS=(base systemd keyboard autodetect microcode modconf kms sd-vconsole sd-encrypt block filesystems fsck)

Disk decyrption prompt (which is quite long) would get printed, then flash caused by KMS kicking in happens, and prompt is messed up after that, with cursor for typing the password being moved too much to the left, in the middle of the prompt.

I experimented somewhat and found following:
1. If I set password-echo=no instead of password-echo=masked (in my case via etc/crypttab.initramfs, but I believe it can also be passed as kernel parameter), then the problem is gone. I guess becuase there is no cursor really, so prompt doesn't get messed up. There is still that KMS flashing happening right after the disk decryption prompt, which doesn't look nice, but at least prompt is not broken. Yeah, there are no dots/asterisks being written when I type the password, instead nothing happens, which is too bad, but I prefer that over the whole thing looking broken.
2. If I add amgpu to MODULES in /etc/mkinitcpio.conf, then the KMS kicks in sooner (the flash happens sooner): right before disk decryption prompt, instead of right after it. I like this better than flash being after it, it is much less intrusive. As for the messed up prompt: now the prompt actually isn't messed up and it all looks ok. However, it is wrapped into two lines, and once I do start typing the password, the cursor jumps at the start of the second line instead of continuing from where it was (e.g. 20 chars into the second line, after the prompt), again overwriting the prompt, which looks broken/weird.

At the end, I went for both: password-echo=no, to avoid the broken prompt once I start typing, and for amdgpu in MODULES, to get the earlier KMS flash, which I found looks better.
I wish I knew how to solve this without giving up on password-echo=masked.
I guess I could turn off the KMS, but somehow that felt like giving up on "goodies" hah.
I am also considerning plymouth for generally nicer experience, will maybe look into that.

One thing I don't fully understand is why does KMS kick in sooner when I add amdgpu to MODULES? Because the amdgpu driver gets loaded sooner so KMS can start sooner, something like that?

EDIT: I tried removing kms from MODULES, but nothing changed (I did rebuild the initramfs, so it is not that). Am I understanding something wrong, why that had no effect?

Last edited by Martinsos (2025-11-18 12:00:52)

seth · 2025-11-18 15:12:49

One thing I don't fully understand is why does KMS kick in sooner when I add amdgpu to MODULES? Because the amdgpu driver gets loaded sooner so KMS can start sooner, something like that?
EDIT: I tried removing kms from MODULES, but nothing changed (I did rebuild the initramfs, so it is not that). Am I understanding something wrong, why that had no effect?

modules in the MODULES array get explicitly and unconditionally loaded. Fwwi, there's no "kms" module, but if you removed the hook that will be idempotent if amdgpu is still in the MODULES array.

Arch Linux

#1 2024-01-15 23:05:20

Early KMS - Screen refresh botches up dm_crypt prompt

#2 2024-01-16 09:18:05

Re: Early KMS - Screen refresh botches up dm_crypt prompt

#3 2024-01-16 12:08:09

Re: Early KMS - Screen refresh botches up dm_crypt prompt

#4 2025-11-18 11:57:59

Re: Early KMS - Screen refresh botches up dm_crypt prompt

#5 2025-11-18 15:12:49

Re: Early KMS - Screen refresh botches up dm_crypt prompt

Board footer