Help with grub video issue during luks password prompt


I have an older Dell laptop (Latitude E6500, std bios). I recently replaced my old (vga) KVM with an HDMI one and I had to buy a vga-to-hdmi adapter for this laptop. The adapter works fine except that when grub prompts for my luks password the video goes blank. (Note that my hdd encryption was setup automatically by the manjaro installer – I believe /boot is a subdir on the root partition and is therefore encrypted – my understanding is that this requires grub to get the password before it can access /boot)

The laptop is in a docking station and so I boot it without opening the lid. The bios boot screens appear on my monitor. It only goes blank when grub runs and prompts for the password. I can type the password blindly and then the grub menu appears (on the monitor). The display continues to work correctly after this.

So, the display only blanks when the grub luks password prompt is shown.

The password prompt worked fine before introduction of the vga-to-hdmi adapter and it still works on the laptop panel (when I open the lid).

I can’t seem to find any reports with this same issue anywhere (most similar posts seem to be about the grub menu or the kernel, but, in my case, this issue occurs before the grub menu (and kernel, of course)).

Hoping someone can help with this…




I forgot to mention one other issue that might be applicable. I have not fully researched this one but it is similar in that it only happens during the grub luks password prompt.

I also recently got a new keyboard – a corsair gaming board. It is usb (like my old one) but it fails to work during the password prompt (it works at all other times).

I’ve had to keep the old kb on the side of my desk to use it to type my luks password (blindly, as mentioned above :frowning:

IDK if this is actually related but I thought I should mention it here in case it is.

Thanks again!


PS: I maybe should replace this laptop (although it is otherwise working fine) but it’s my work laptop and (unfortunately) not easily replaced at this time…

Hello @codemonkey :wink:

I assume the KVM is a switch with VGA and USB to switch between 2 systems with one screen?

Hi @megavolt,

It is a KVM (1-4 systems, one screen) with HDMI and USB (and audio).

My old KVM had VGA and grub worked fine with it. For the new KVM I had to use a vga-to-hdmi adapter with this machine (all my other machines already had HDMI video).

have you tried to configure GRUB with an explicit resolution? Perhaps its default autoconfiguration fails due to the vga-hdmi adapter. See:

For the USB keyboard to work, add keyboard to the HOOKS in /etc/mkinitcpio.conf before the next initramfs generation.

Hi @ion,

I did try setting the resolution (made no difference) and the ‘keyboard’ hook is already present.

The thing with the video setting (and anything in grub.cfg FTM), is this: I think this issue is happening before grub.cfg is even read. (I would love to confirm this.) My understanding is that – since /boot is encrypted – the first stage of grub (I’m not sure the correct name for it) must unlock /boot before it can even read grub.cfg. After I unlock, video & keyboard both come on and then the grub menu is displayed (if my understanding is correct, this is after loading grub.cfg).

The only thing that makes me wonder about this understanding/assumption is that it implies that grub first stage needs to somehow access cryptsetup (or an equivalent). But I’m not sure it could do that given the limited storage that grub first stage has.

But, if this understanding is correct, I am also wondering if grub is the one displaying that password prompt – could it actually be cryptsetup? IDK.

Thanks for your input!


Ah, my bad about forgetting your encrypted boot while replying.
No, GRUB first stage loads its own mods for decryption. If you regenerate GRUB’s 1st stage image with the keyboard attached, jt may even detect it, unlikely for the adapter though. You are right that grub.cfg is not yet processed at that point. However, the modules it loads may give you the info what you need to add to 1st stage. see here:

Hi @ion

Just wanted to reply quickly and say thanks, although I haven’t been able to pursue it yet because I got side-tracked by another problem (seems all https sites are failing with my vpn connected… :frowning:

Your suggestion seems promising, although I have to translate it to non-UEFI.

Hopefully I can get back to this soon (and I will follow-up)…


Hi @codemonkey,
no worry; thanks for the info. btw The wiki contains a link to debian at the end, where a non-UEFI example is included.