Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Initramfs has some graphics issue with Coreboot libgfxinit
-
- Posts: 7
- Joined: 2022-06-19 19:11
Initramfs has some graphics issue with Coreboot libgfxinit
I use Coreboot with Seabios and native graphics initialization (libgfxinit) and have tested this on a few machines. Right now I have Debian installed on a Thinkpad T60 with intel graphics and a W520 with an Nvidia dgpu (similar coreboot setup) and both of them manifest this issue identically with bone-stock Debian 11 installations (base with no DE installed, encrypted with LVM via the regular installer). It does not manifest if I compile coreboot to use VGA textmode.
The display freezes at loading initial ramdisk - however, it is still running in the background, and I can type in my encryption key and it will boot and, at some time during init, it will fix the framebuffer and give me a terminal so I can see the login prompt. Normally I would be fine to leave it be but if my machine won't boot properly for any reason (e.g. I'm trying to troubleshoot the switch to OpenRC), it essentially renders troubleshooting impossible. I have tried:
Setting GRUB to gfxmode=console. The setting works but the graphics still freeze.
Setting GRUB to gfxpayload_linux=text. No change.
Setting GRUB to gfxmode=console and gfxpayload_linux=keep. No change.
Adding nomodeset to the CLI (normally and with above console,keep) No change.
Deleting quiet from GRUB, and adding loglevel 7. No change.
Booting to runlevel 3 make it stay frozen on loading initial ramdisk forever.
I'm about at the end of my ability to troubleshoot this and I'm not terribly well informed about this part of the boot process and it's not a common issue. Does anybody have any ideas as to what I can throw at it that might make a change? I can post configs as needed but they're going to be whatever Debian generates by default.
The display freezes at loading initial ramdisk - however, it is still running in the background, and I can type in my encryption key and it will boot and, at some time during init, it will fix the framebuffer and give me a terminal so I can see the login prompt. Normally I would be fine to leave it be but if my machine won't boot properly for any reason (e.g. I'm trying to troubleshoot the switch to OpenRC), it essentially renders troubleshooting impossible. I have tried:
Setting GRUB to gfxmode=console. The setting works but the graphics still freeze.
Setting GRUB to gfxpayload_linux=text. No change.
Setting GRUB to gfxmode=console and gfxpayload_linux=keep. No change.
Adding nomodeset to the CLI (normally and with above console,keep) No change.
Deleting quiet from GRUB, and adding loglevel 7. No change.
Booting to runlevel 3 make it stay frozen on loading initial ramdisk forever.
I'm about at the end of my ability to troubleshoot this and I'm not terribly well informed about this part of the boot process and it's not a common issue. Does anybody have any ideas as to what I can throw at it that might make a change? I can post configs as needed but they're going to be whatever Debian generates by default.
-
- Global Moderator
- Posts: 3016
- Joined: 2014-07-20 18:12
- Location: Europe
- Has thanked: 75 times
- Been thanked: 411 times
Re: Initramfs has some graphics issue with Coreboot libgfxinit
Hello,
If the laptop panel blanks after initramfs is loaded, it could mean that the screen blanks when the kernel loads video modules and setup the video mode of the graphic card.
Since the operating system works fine even if the laptop panel is blank, then It could be possible to collect the system log after the boot of Debian is completed. These log could contain some clues about why the laptop panel blanks: in this regard, it would be better to configure the linux "debug" kernel parameter in grub before booting Debian.
You can collect/analyse/share at least the following system logs:
/var/log/system
/var/log/kern
If the laptop panel blanks after initramfs is loaded, it could mean that the screen blanks when the kernel loads video modules and setup the video mode of the graphic card.
Since the operating system works fine even if the laptop panel is blank, then It could be possible to collect the system log after the boot of Debian is completed. These log could contain some clues about why the laptop panel blanks: in this regard, it would be better to configure the linux "debug" kernel parameter in grub before booting Debian.
You can collect/analyse/share at least the following system logs:
/var/log/system
/var/log/kern
-
- Posts: 7
- Joined: 2022-06-19 19:11
Re: Initramfs has some graphics issue with Coreboot libgfxinit
Thank you for your response. To clarify: it doesn't blank, it just freezes.
Here are some relevant logs, uploaded to pastebin:
dmesg: https://pastebin.com/vEDWQdgg
kern.log: https://pastebin.com/t9kPRL77
syslog: https://pastebin.com/nLqMePb5
messages: https://pastebin.com/25T3FHB6
Here are some relevant logs, uploaded to pastebin:
dmesg: https://pastebin.com/vEDWQdgg
kern.log: https://pastebin.com/t9kPRL77
syslog: https://pastebin.com/nLqMePb5
messages: https://pastebin.com/25T3FHB6
-
- Global Moderator
- Posts: 3016
- Joined: 2014-07-20 18:12
- Location: Europe
- Has thanked: 75 times
- Been thanked: 411 times
Re: Initramfs has some graphics issue with Coreboot libgfxinit
Hello,
This is an excerpt of the log you sent:
It looks like that, as you can see, the i915 kernel module fails to find VBIOS tables (VBT) (in which are defined the timings for video modes of the default display) and the Linux kernel's i915drmfb (drm framebuffer) locks. I cannot say for sure that the two errors are related and I'm not an expert of the subject. But, according to libgfxinit documention in coreboot documentation [1], you have to setup a "GMA: Per Board Configuration" in libgfxinit/coreboot:
It seems the log came from the "ThinkPad W520 (4282C37)" with an integrated intel GMA graphic card and an NVIDIA discrete graphic card:
---
[1] https://doc.coreboot.org/gfx/libgfxinit.html
[2] https://doc.coreboot.org/gfx/display-panel.html
This is an excerpt of the log you sent:
Code: Select all
$ grep -e "i915\|vga\|vesa\|GFX\|0000\:00\:02\.0:\|drmfb" libgfxinit.log
Aug 19 15:48:16 navi kernel: [ 0.309992] pci 0000:00:02.0: [8086:0166] type 00 class 0x030000
Aug 19 15:48:16 navi kernel: [ 0.310000] pci 0000:00:02.0: reg 0x10: [mem 0x82c00000-0x82ffffff 64bit]
Aug 19 15:48:16 navi kernel: [ 0.310006] pci 0000:00:02.0: reg 0x18: [mem 0x90000000-0x9fffffff 64bit pref]
Aug 19 15:48:16 navi kernel: [ 0.310009] pci 0000:00:02.0: reg 0x20: [io 0x1000-0x103f]
Aug 19 15:48:16 navi kernel: [ 0.317416] pci 0000:00:02.0: vgaarb: setting as boot VGA device
Aug 19 15:48:16 navi kernel: [ 0.317416] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
Aug 19 15:48:16 navi kernel: [ 0.317416] pci 0000:00:02.0: vgaarb: bridge control possible
Aug 19 15:48:16 navi kernel: [ 0.317416] vgaarb: loaded
Aug 19 15:48:16 navi kernel: [ 0.339718] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
Aug 19 15:48:16 navi kernel: [ 0.883234] pci 0000:00:02.0: Adding to iommu group 1
Aug 19 15:48:16 navi kernel: [ 1.150023] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
Aug 19 15:48:16 navi kernel: [ 8.739852] i915 0000:00:02.0: [drm] VT-d active for gfx access
Aug 19 15:48:16 navi kernel: [ 8.739856] i915 0000:00:02.0: vgaarb: deactivate vga console
Aug 19 15:48:16 navi kernel: [ 8.739899] i915 0000:00:02.0: [drm] DMAR active, disabling use of stolen memory
Aug 19 15:48:16 navi kernel: [ 8.740050] i915 0000:00:02.0: Invalid PCI ROM data signature: expecting 0x52494350, got 0xe937aa55
Aug 19 15:48:16 navi kernel: [ 8.740052] i915 0000:00:02.0: [drm] Failed to find VBIOS tables (VBT)
Aug 19 15:48:16 navi kernel: [ 8.740287] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
Aug 19 15:48:16 navi kernel: [ 8.779273] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on minor 0
Aug 19 15:48:16 navi kernel: [ 8.779449] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
Aug 19 15:48:16 navi kernel: [ 8.905494] fbcon: i915drmfb (fb0) is primary device
Aug 19 15:48:17 navi kernel: [ 9.675952] i915 0000:00:02.0: [drm] *ERROR* uncleared fifo underrun on pipe A
Aug 19 15:48:17 navi kernel: [ 9.675956] i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun
Aug 19 15:48:17 navi kernel: [ 9.675966] i915 0000:00:02.0: [drm] *ERROR* uncleared pch fifo underrun on pch transcoder A
Aug 19 15:48:17 navi kernel: [ 9.675967] i915 0000:00:02.0: [drm] *ERROR* PCH transcoder A FIFO underrun
Aug 19 15:48:17 navi kernel: [ 9.719781] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
Therefore, it seems you have to configure in libgfxinit/coreboot the specific timings used by your Intel GMA graphic cards to drive the default integrated display (panel). The documentation [2] reports how they can be acquired from the default (legacy) VBT (Video BIOS Table).In order to set up the display panel, see the display panel-specific documentation.
It seems the log came from the "ThinkPad W520 (4282C37)" with an integrated intel GMA graphic card and an NVIDIA discrete graphic card:
Code: Select all
Aug 19 15:48:16 navi kernel: [ 0.000000] DMI: LENOVO 4282C37/4282C37, BIOS CBET4000 4.17-988-g8915abe115 08/12/2022
It could interesting to watch an image or a short video of the boot sequence. It could be interesting to compare the already sent log with the ones generated when system boots correctly with coreboot configured for textmode and legacy VGA plane, too
---
[1] https://doc.coreboot.org/gfx/libgfxinit.html
[2] https://doc.coreboot.org/gfx/display-panel.html
-
- Posts: 7
- Joined: 2022-06-19 19:11
Re: Initramfs has some graphics issue with Coreboot libgfxinit
You are correct: there's no VBT to load, the BIOS image has not been compiled with one. This is probably related to the issue but it still shouldn't freeze the screen on boot - other configurations (Artix and my Gentoo builds) have been able to boot on these machines normally using a similar encrypted LVM setup with GRUB and a generated initramfs. It's definitely a fixable configuration issue from the OS, but the tools are too different to just do the same as the other setups.
I recompiled coreboot to boot in textmode instead of providing a framebuffer. Worked predictably. I have included the tapes of the boot process here:
Framebuffer: https://files.catbox.moe/m03wy1.m4v
Textmode: https://files.catbox.moe/dlpw4l.m4v (GRUB does not display in this one, but that's expected. Fixable with gfxmode=console)
And logs:
dmesg: https://pastebin.com/pidzeFZb
syslog: https://pastebin.com/8Qr6kCAW
messages: https://files.catbox.moe/i231g8
kern.log: https://files.catbox.moe/es7kv4.log
(they were longer than pastebin's allowed 512k so I uploaded the text files to catbox.moe)
Unless I'm wrong about what's going on here, the thing I ultimately trying to figure out is how to mess with the initramfs generation such that it doesn't try for graphics at all, and just prints to the provided framebuffer.
I recompiled coreboot to boot in textmode instead of providing a framebuffer. Worked predictably. I have included the tapes of the boot process here:
Framebuffer: https://files.catbox.moe/m03wy1.m4v
Textmode: https://files.catbox.moe/dlpw4l.m4v (GRUB does not display in this one, but that's expected. Fixable with gfxmode=console)
And logs:
dmesg: https://pastebin.com/pidzeFZb
syslog: https://pastebin.com/8Qr6kCAW
messages: https://files.catbox.moe/i231g8
kern.log: https://files.catbox.moe/es7kv4.log
(they were longer than pastebin's allowed 512k so I uploaded the text files to catbox.moe)
Unless I'm wrong about what's going on here, the thing I ultimately trying to figure out is how to mess with the initramfs generation such that it doesn't try for graphics at all, and just prints to the provided framebuffer.
-
- Global Moderator
- Posts: 3016
- Joined: 2014-07-20 18:12
- Location: Europe
- Has thanked: 75 times
- Been thanked: 411 times
Re: Initramfs has some graphics issue with Coreboot libgfxinit
Hello,
Some of this parameters could be[1]:
They can be initially passed interactively to grub. Once you have found the correct parameter (or the correct combination) you can configure grub to pass it to the kernel always at every boot.
[1] https://support.digium.com/s/article/Ho ... g-problems
The initramfs is only a container of files the kernel uses to start from. If I understand correctly, you wish to disable the framebuffer at boot. In this case, it could be obtained passing some parameters to the kernel before booting using grub.iwakura_lain wrote: ↑2022-08-20 19:03 Unless I'm wrong about what's going on here, the thing I ultimately trying to figure out is how to mess with the initramfs generation such that it doesn't try for graphics at all, and just prints to the provided framebuffer.
Some of this parameters could be[1]:
Code: Select all
vga=normal
nofb
nomodeset
video=vesafb:off
i915.modeset=0
[1] https://support.digium.com/s/article/Ho ... g-problems
-
- Posts: 7
- Joined: 2022-06-19 19:11
Re: Initramfs has some graphics issue with Coreboot libgfxinit
Note: boot text says vga=normal is deprecated and to instead use gfxpayload=text, so I did that.
I passed all of them simultaneously and, instead of making the boot process display past loading initramfs, it instead disabled the framebuffer that loaded _after_ the encryption key was entered, so it would stay frozen forever. I know that it booted from watching the disk access light. I also went and tried them all individually and in various combinations, and the only one that had any effect is nomodeset. My initial post appears to be incorrect - `nomodeset` causes the behaviour where it will freeze past the boot process, but none of these options make it print properly between loading initial ramdisk and the login prompt.
I passed all of them simultaneously and, instead of making the boot process display past loading initramfs, it instead disabled the framebuffer that loaded _after_ the encryption key was entered, so it would stay frozen forever. I know that it booted from watching the disk access light. I also went and tried them all individually and in various combinations, and the only one that had any effect is nomodeset. My initial post appears to be incorrect - `nomodeset` causes the behaviour where it will freeze past the boot process, but none of these options make it print properly between loading initial ramdisk and the login prompt.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Initramfs has some graphics issue with Coreboot libgfxinit
Is plymouth installed ?
If yes, what happens if you boot with the kernel parameter "nosplash" ?
If no, what happens if you install it and boot with the kernel parameter "splash" ?
If yes, what happens if you boot with the kernel parameter "nosplash" ?
If no, what happens if you install it and boot with the kernel parameter "splash" ?
-
- Posts: 7
- Joined: 2022-06-19 19:11
Re: Initramfs has some graphics issue with Coreboot libgfxinit
Plymouth was not installed - installation has no DE or anything. Installing it... fixed the issue? It throws a handful of i915 drm errors: "uncleared fifo underrun on pipe A ; CPU pipe A FIFO underrun ; uncleared pch fifo underrun on pch transcoder A ; PCH transcoder A FIFO underrun" but it does actually give me a responsive prompt. Doesn't display an image (presumably because I never fed it one - never used this software before so idk) but something it did fixed the terminal.
Good suggestion, I would not have thought to try that. I'll check the differences between plymouth's initramfs and the original and see if I can compile those options into in the vanilla initramfs independently of this program. Thanks.
Good suggestion, I would not have thought to try that. I'll check the differences between plymouth's initramfs and the original and see if I can compile those options into in the vanilla initramfs independently of this program. Thanks.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Initramfs has some graphics issue with Coreboot libgfxinit
Plymouth loads the graphic driver earlier during the initramfs, before the LUKS passphrase is asked. I guess you could do the same by adding i915 in /etc/initramfs-tools/modules.
-
- Posts: 7
- Joined: 2022-06-19 19:11
Re: Initramfs has some graphics issue with Coreboot libgfxinit
Adding i915 to /etc/initramfs-tools/modules followed by initramfs-update -u fixed the issue.
-
- Global Moderator
- Posts: 3016
- Joined: 2014-07-20 18:12
- Location: Europe
- Has thanked: 75 times
- Been thanked: 411 times
Re: Initramfs has some graphics issue with Coreboot libgfxinit
hello,
I’m happy you sorted it out. Kudos to p.H.iwakura_lain wrote: ↑2022-08-22 20:25 Adding i915 to /etc/initramfs-tools/modules followed by initramfs-update -u fixed the issue.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Initramfs has some graphics issue with Coreboot libgfxinit
No it does not fix the real issue, it is just a workaround. You are still out of luck if anything bad happens before the i915 module is loaded.iwakura_lain wrote: ↑2022-08-22 20:25 Adding i915 to /etc/initramfs-tools/modules followed by initramfs-update -u fixed the issue.