No early boot console in 6.3.x kernels

[3hhh]

How to file a helpful issue

Qubes OS release

4.1
Xen 4.14.5

Brief summary

Booting kernel 6.3.2-1 on a T530 leads to a black screen.

Steps to reproduce

Boot.

Expected behavior

Some output is shown, e.g. boot console output or the luks passphrase prompt.

Actual behavior

A black screen is shown. The kernel seems to react to keyboard input though, e.g. Ctrl-Alt-Del.

[marmarek]

Can you provide any logs? Since the kernel reacts, maybe you can type the luks passphrase blindly and hope logs will be saved?

[3hhh]

Can you provide any logs? Since the kernel reacts, maybe you can type the luks passphrase blindly and hope logs will be saved?

Here you go: https://hackingthe.net/downloads/kernel_broken.txt

Actually it even boots after typing in the luks passphrase blindly. Xorg also makes the graphics work, i.e. the system is usable.
Did maybe plymouth.enable=0 change with that kernel?

[marmarek]

Did maybe plymouth.enable=0 change with that kernel?

Why you add it? It surely disables graphical LUKS prompt.

[marmarek]

honestly, I have no idea why you have blank screen, I don't see any obvious errors and there is also:

[    7.376146] fbcon: i915drmfb (fb0) is primary device
[    7.376513] Console: switching to colour frame buffer device 240x67
[    7.383795] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

so, it did initialized GPU. I don't see any other GPU there, so it seems to be the correct (the only) one. Maybe you can compare the log with the one from working version?

[3hhh]

Maybe you can compare the log with the one from working version?

The only diff I see (broken vs good): ``` [ 5.364345] memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=1 'systemd' ``` A bit weird, but in both: ``` [ 7.193107] tmpfs: Unsupported parameter 'huge' [ 7.193121] i915 0000:00:02.0: [drm] Transparent Hugepage support is recommended for optimal performance when IOMMU is enabled! [ 7.193135] i915 0000:00:02.0: [drm] DMAR active, disabling use of stolen memory [ 7.237410] i915 0000:00:02.0: [drm] Skipping intel_backlight registration ```

[vzvva]

I am experiencing the same issue with this kernel on my T530, where the discrete graphics card is enabled:
NVIDIA Corporation GF108M [NVS 5400M] [10de:0def] (rev a1) (prog-if 00 [VGA controller]).
After running multiple AppVMs for a few minutes, the system freezes and then automatically reboots.

[3hhh]

On 5/27/23 14:58, Marek Marczykowski-Górecki wrote: > Did maybe `plymouth.enable=0` change with that kernel? Why you add it? It surely disables graphical LUKS prompt.

Yes, I don't like that graphical prompt as it makes the console output invisible. Anyway I just re-enabled plymouth and could see it and press F1 to see the console output as well, i.e. everything works as expected with plymouth enabled. So this issue is only related to disabled plymouth (`plymouth.enable=0`). Probably someone forgot about that option upstream.

[vzvva]

There are no logs after the crash and automatic reboot. I checked the lines before the'--reboot--'line in the command 'journalctl --since yesterday' in dom0, but the logs after the crash are missing. What should I do?

[vzvva]

By the way, I can't use another kernel with the discrete graphics* card enabled: . The system locks before entering the disk password.

• NVIDIA Corporation GF108M [NVS 5400M] [10de:0def] (rev a1) (prog-if 00 [VGA controller])

[vzvva]

https://forum.qubes-os.org/t/kernel-latest-6-3-2-1-not-stable/18936

[3hhh]

Still an issue in 6.3.9.

[3hhh]

Was fixed by upgrading heads.

[tlaurion]

@3hhh yes. Was fixed by linuxboot/heads#1398, more specifically linuxboot/heads#1381 hacking around kernel 4.20+ not exposing fb address (Cause is that i915drmfb on next kernel after kexec call can only own the console once it is loaded). With linuxboot/heads#1381, Heads kernel is now tainted to expose fb address on kexec load of next kernel and kexec was hacked to expose fb address when loading next kernel.

Please keep an eye on linuxboot/heads#1403 which will replace all this drm+fb nonsense under Heads with efifb in the short term, providing a common base for all coreboot+linuxboot and give 500kb back from liberated space from kernel size reduction and 2s shorter bootime.