Distorted GRUB background wallpaper

Beep · 2018-06-26 12:09:19

This is in response to https://forums.bunsenlabs.org/viewtopic … 976#p73976

On my Lenovo G50-30 laptop the GRUB background image is displayed as an abstract collection of blobs:

I guess this may be related to the graphics card:

# lspci -vv
...
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0c) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Atom Processor Z36xxx/Z37xxx Series Graphics & Display
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 89
	Region 0: Memory at 90000000 (32-bit, non-prefetchable) [size=4M]
	Region 2: Memory at 80000000 (32-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 3050 [size=8]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0300c  Data: 41c1
	Capabilities: [b0] Vendor Specific Information: Len=07 <?>
	Kernel driver in use: i915
	Kernel modules: i915

sleekmason · 2018-06-26 14:53:04

Please post the output of:

sudo lspci | grep VGA ; lsmod | grep "kms\|drm" ; find /dev -group video ; \
cat /proc/cmdline ; find /etc/modprobe.d/; cat /etc/modprobe.d/*kms* ; \
ls /etc/X11/xorg.conf ; glxinfo | grep -i "vendor\|rendering" ; \
grep LoadModule /var/log/Xorg.0.log

This will pretty much cover the spectrum of what might be needed to know for graphics. In particular, I'm interested whether your hardware requires the i915g version to operate properly.

Last edited by sleekmason (2018-06-26 14:53:31)

nobody · 2018-06-26 18:17:05

sleekmason wrote:

Please post the output of:
sudo lspci | grep VGA ; lsmod | grep "kms\|drm" ; find /dev -group video ; \
cat /proc/cmdline ; find /etc/modprobe.d/; cat /etc/modprobe.d/*kms* ; \
ls /etc/X11/xorg.conf ; glxinfo | grep -i "vendor\|rendering" ; \
grep LoadModule /var/log/Xorg.0.log
This will pretty much cover the spectrum of what might be needed to know for graphics. In particular, I'm interested whether your hardware requires the i915g version to operate properly.

GRUB has nothing to do with Linux kernel/drivers/Xorg. The menu shown is rendered only using GRUB code (and drivers), though the exact type of graphics hardware would still be useful to know.

@OP: Is your system using EFI?

sleekmason · 2018-06-26 18:58:25

GRUB has nothing to do with Linux kernel/drivers/Xorg. The menu shown is rendered only using GRUB code (and drivers), though the exact type of graphics hardware would still be useful to know.

Clarifying here, would it not be important if he was using:

nomodeset i915.modeset=0

or some other bootline code?

Actually I don't think it's the driver. My guess is that it may be as simple as:

Mark VGA/VBE/EFI FB as generic system framebuffer

Located in Bus Options

isn't enabled by default in the Bunsenlabs kernel. years ago when newer devices came out, this was buggy. But no longer. It defaults through the different options, ultimately winding up with the simplest available legacy drivers.

Here's the kernel info on Mark VGA/VBE/EFI FB as generic system framebuffer:

CONFIG_X86_SYSFB:                                                                          │  
  │                                                                                            │  
  │ Firmwares often provide initial graphics framebuffers so the BIOS,                         │  
  │ bootloader or kernel can show basic video-output during boot for                           │  
  │ user-guidance and debugging. Historically, x86 used the VESA BIOS                          │  
  │ Extensions and EFI-framebuffers for this, which are mostly limited                         │  
  │ to x86.                                                                                    │  
  │ This option, if enabled, marks VGA/VBE/EFI framebuffers as generic                         │  
  │ framebuffers so the new generic system-framebuffer drivers can be                          │  
  │ used on x86. If the framebuffer is not compatible with the generic                         │  
  │ modes, it is adverticed as fallback platform framebuffer so legacy                         │  
  │ drivers like efifb, vesafb and uvesafb can pick it up.                                     │  
  │ If this option is not selected, all system framebuffers are always                         │  
  │ marked as fallback platform framebuffers as usual.                                         │  
  │                                                                                            │  
  │ Note: Legacy fbdev drivers, including vesafb, efifb, uvesafb, will                         │  
  │ not be able to pick up generic system framebuffers if this option                          │  
  │ is selected. You are highly encouraged to enable simplefb as                               │  
  │ replacement if you select this option. simplefb can correctly deal                         │  
  │ with generic system framebuffers. But you should still keep vesafb                         │  
  │ and others enabled as fallback if a system framebuffer is                                  │  
  │ incompatible with simplefb.                                                                │  
  │                                                                                            │  
  │ If unsure, say Y.                                                                          │  
  │                                                                                            │  
  │ Symbol: X86_SYSFB [=n]                                                                     │  
  │ Type  : bool                                                                               │  
  │ Prompt: Mark VGA/VBE/EFI FB as generic system framebuffer                                  │  
  │   Location:                                                                                │  
  │     -> Bus options (PCI etc.)                                                              │  
  │   Defined at arch/x86/Kconfig:2842

Also, the support for simple framebuffer is also disabled (located in Device Drivers --> Graphics-->frame buffer devices)

CONFIG_FB_SIMPLE:                                                                          │  
  │                                                                                            │  
  │ Say Y if you want support for a simple frame-buffer.                                       │  
  │                                                                                            │  
  │ This driver assumes that the display hardware has been initialized                         │  
  │ before the kernel boots, and the kernel will simply render to the                          │  
  │ pre-allocated frame buffer surface.                                                        │  
  │                                                                                            │  
  │ Configuration re: surface address, size, and format must be provided                       │  
  │ through device tree, or plain old platform data.                                           │  
  │                                                                                            │  
  │ Symbol: FB_SIMPLE [=n]                                                                     │  
  │ Type  : bool                                                                               │  
  │ Prompt: Simple framebuffer support                                                         │  
  │   Location:                                                                                │  
  │     -> Device Drivers                                                                      │  
  │       -> Graphics support                                                                  │  
  │         -> Frame buffer Devices                                                            │  
  │   Defined at drivers/video/fbdev/Kconfig:2333                                              │  
  │   Depends on: HAS_IOMEM [=y] && FB [=y]=y                                                  │  
  │   Selects: FB_CFB_FILLRECT [=y] && FB_CFB_COPYAREA [=y] && FB_CFB_IMAGEBLIT [=y]

Anyway, my guess is that without the first item being enabled, the op's framebuffer is falling back to legacy, and giving bad output. This would allow for everything to work correctly after boot, but have issues during. (You will note the driver says "if unsure, say yes" in the config).

I have noted this being enabled by default in other distros. The OP could try a recompile with those options enabled. Pretty sure this is also what will allow for the pretty colors and such on the boot console

Last edited by sleekmason (2018-06-26 18:59:22)

Beep · 2018-06-26 20:48:44

sleekmason wrote:

Please post the output of:

sudo lspci | grep VGA ; lsmod | grep "kms\|drm" ; find /dev -group video ; \
cat /proc/cmdline ; find /etc/modprobe.d/; cat /etc/modprobe.d/*kms* ; \
ls /etc/X11/xorg.conf ; glxinfo | grep -i "vendor\|rendering" ; \
grep LoadModule /var/log/Xorg.0.log

Here goes...

$ sudo lspci | grep VGA ; lsmod | grep "kms\|drm" ; find /dev -group video ; \
> cat /proc/cmdline ; find /etc/modprobe.d/; cat /etc/modprobe.d/*kms* ; \
> ls /etc/X11/xorg.conf ; glxinfo | grep -i "vendor\|rendering" ; \
> grep LoadModule /var/log/Xorg.0.log
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0c)
drm_kms_helper        155648  1 i915
drm                   360448  4 i915,drm_kms_helper
/dev/fb0
/dev/dri/card0
/dev/dri/renderD128
/dev/dri/controlD64
/dev/video0
BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-amd64 root=UUID=93641644-ff00-4816-8a96-eda626b10298 ro quiet
/etc/modprobe.d/
/etc/modprobe.d/intel-microcode-blacklist.conf
/etc/modprobe.d/amd64-microcode-blacklist.conf
cat: '/etc/modprobe.d/*kms*': No such file or directory
ls: cannot access '/etc/X11/xorg.conf': No such file or directory
direct rendering: Yes
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
    Vendor: Intel Open Source Technology Center (0x8086)
OpenGL vendor string: Intel Open Source Technology Center
[    22.850] (II) LoadModule: "glx"
[    23.651] (II) LoadModule: "modesetting"
[    23.667] (II) LoadModule: "fbdev"
[    23.670] (II) LoadModule: "vesa"
[    23.699] (II) LoadModule: "fbdevhw"
[    23.720] (II) LoadModule: "glamoregl"
[    24.090] (II) LoadModule: "fb"
[    25.543] (II) LoadModule: "libinput"
[    25.872] (II) LoadModule: "synaptics"

nobody wrote:

@OP: Is your system using EFI?

Nope

ohnonot · 2018-06-26 21:06:16

clearly grub recognizes and loads the image, but does not render it properly.
if the system is otherwise working fine, the problem/solution can only be within grub.
i'm not sure if there are options on __how__ the graphical terminal is set up and what sorts of images are loaded...
grub specialists, maybe the default setup can be tweaked to accomodate for such edge cases?
one person says the .tga format was better:
https://askubuntu.com/questions/893863/ … ge-in-grub

sleekmason · 2018-06-27 16:15:17

ohnonot wrote:

clearly grub recognizes and loads the image, but does not render it properly.
if the system is otherwise working fine, the problem/solution can only be within grub.

Before grub. Framebuffer settings.

If however, you want to change the resolution during boot, you can:

xdpyinfo | grep dimensions

To get your screen dimensions, and then open /etc/default/grub and uncomment the line showing:

#GRUB_GFXMODE=

and change the existing numbers to match your screen size found using xdyinfo:

sudo nano /etc/default/grub

Example for my screen:

GRUB_GFXMODE=1440x900

Then update grub for the change to take affect:

update-grub

ohnonot · 2018-06-27 18:13:17

sleekmason wrote:

Before grub. Framebuffer settings.

what is there before grub?
not sure if i understand, esp. since you go on recommending grub configuration stuff.

If however, you want to change the resolution during boot...

why is that about resolutions now?

hhh · 2018-06-27 18:39:22

Moderator here; I'm editing the thread title to something a little more search-engine friendly.

sleekmason · 2018-06-27 19:52:38

ohnonot wrote:

what is there before grub?
not sure if i understand, esp. since you go on recommending grub configuration stuff.

please read the description of Mark VGA/VBE/EFI FB as generic system framebuffer, that I wrote about a couple of posts up.

I do not know for sure. What I think, is that grub is reading the screen from the computers bios wrong. Grub can set its own fonts, jpegs, and such, but ifgrub cannot set the picture format correctly, then it is because grub is using the screen settings from the bios, which may be giving a legacy output instead of reading the bios correctly, based on the above kernel setting not being enabled.

So do I know for sure? Nope. Just suggesting a possible solution to the problem like everybody else.

If however, you want to change the resolution during boot...
why is that about resolutions now?

Because I like helping people. Showing one of the screen settings you can adjust from within grub seemed like a good idea. You made reference to settings within grub. Seemed relevant at the time.

Last edited by sleekmason (2018-06-27 19:53:03)

ohnonot · 2018-06-28 07:29:22

going back to op #1.

this is something that happens before the kernel even gets loaded.
while there might be some kernel documentation that touches on the subject of bios framebuffers, the kernel has nothing to do with the problem at hand.

i previously suggested that bunsenlabs (or op) might consider using a background image that is compatible with as much hardware as possible.

i now found this:
https://wiki.debian.org/Grub/SplashImage
it suggests a very specific format for grub2.
i wonder if bunsenlabs' grub background conforms to that format.
Beep, could you please try to convert the background image to the exact format specified for grub2. does that work better?
if that doesn't work, could you try to convert the image to the format specified for grub1?

johnraff · 2018-06-28 10:13:27

ohnonot wrote:

i now found this:
https://wiki.debian.org/Grub/SplashImage
it suggests a very specific format for grub2.
i wonder if bunsenlabs' grub background conforms to that format.

That page seems a bit restrictive, compared with this: https://help.ubuntu.com/community/Grub2 … ound_Image or this: https://github.com/BunsenLabs/bunsen-im … efault.png Both are Ubuntu links, but is grub2 any different in Debian? JPG files are subject to some restrictions, but I thought our 640x480 PNG would be OK. If anyone can suggest how it can be improved then let's do it.

sleekmason · 2018-06-28 12:01:30

this is something that happens before the kernel even gets loaded.

While I understand this to be true after install, Doesn't the live kernel supply grub the initial screen settings that grub uses for it's settings on install from live cd?

If the above code I referenced wasn't set by default in the live cd kernel version, Then the op's bios may not have been read correctly, and provided grub with the wrong initial settings. Don't be so quick to dismiss something because you are not familiar with it.

This can still be adjusted from userland. The below from the grub manual might be what we are looking for.

Maybe setting gfxpayload differently? Note, this is not the same as gfxmode.

15.1.13 gfxpayload

If this variable is set, it controls the video mode in which the Linux kernel starts up, replacing the ‘vga=’ boot option (see linux). It may be set to ‘text’ to force the Linux kernel to boot in normal text mode, ‘keep’ to preserve the graphics mode set using ‘gfxmode’, or any of the permitted values for ‘gfxmode’ to set a particular graphics mode (see gfxmode).
Depending on your kernel, your distribution, your graphics card, and the phase of the moon, note that using this option may cause GNU/Linux to suffer from various display problems, particularly during the early part of the boot sequence. If you have problems, set this variable to ‘text’ and GRUB will tell Linux to boot in normal text mode.
The default is platform-specific. On platforms with a native text mode (such as PC BIOS platforms), the default is ‘text’. Otherwise the default may be ‘auto’ or a specific video mode.
This variable is often set by ‘GRUB_GFXPAYLOAD_LINUX’ (see Simple configuration).

Maybe not, but worth looking at.

https://www.gnu.org/software/grub/manua … gfxpayload

Last edited by sleekmason (2018-06-28 12:02:58)

Beep · 2018-06-28 12:43:06

I've tried a few things...

I poked the BIOS. The only setting that looked relevant was Intel Virtual Technology, which was disabled. Enabling it didn't make a difference.
I exported the background PNG to a TGA as suggested at https://askubuntu.com/questions/893863/ … ge-in-grub. GRUB is using the new image but renders it as before.
I added GRUB_GFXPAYLOAD_LINUX="text" to my /etc/default/grub file (and ran update-grub). That didn't do anything either. I also ran videoinfo from the GRUB command line to see what modes are supported (as per https://www.gnu.org/software/grub/manua … ml#gfxmode) but that presented me with a black square box - it looks like it's using black text on a black background.

Not sure what else to try. It's not a major issue (I can live with no background image in GRUB) and it seems this is a very uncommon issue.

sleekmason · 2018-06-28 12:49:51

I would try a reinstall to mbr to see if correct settings are picked up.

sudo grub-install /dev/sda

(For an sda drive)
then update grub

update-grub

**Edit - I don't know if reinstalling from here would change the settings.

Something you could try that would test the kernel code option, would be to install antix, and then grub from the antix live cd. The afore mentioned support is enabled in their live cd kernel.

This isn't the most reliable of tests for all sorts of reasons, but may shed light on this part anyway:)

Last edited by sleekmason (2018-06-28 13:18:07)

hhh · 2018-06-28 15:22:04

Beep wrote:

GRUB background image is displayed as an abstract collection of blobs

Let's back up. You installed via the live image? And you had a normal grub screen there, you had the Beam wall and you could choose Live, Install, etc...?

sleekmason · 2018-06-28 16:22:07

hhh wrote:

Let's back up. You installed via the live image? And you had a normal grub screen there, you had the Beam wall and you could choose Live, Install, etc...?

Excellent thought! The only problem with this is that the initialization script readings are taken(unknown) directly from the bios before the session boots.

As the "make grub" script is coming from a file within the distro image, any configuration Grub draws from would be after the initial kernel install, and likely the configuration would come from kernel land, rather than the beginning of the initialization script.

Everyone's bios is different, reading from a setting gathered by the kernel makes sense. The file is always in the same path on all computers.

Edit** -- I thought I would try to outline this a bit easier.

It's basically like this,

1.Grub installs from the live cd.
2.The script to install grub is within the Bunsenlabs image on the cd.
3.Grub doesn't have everybody's bios info. Doesn't have to. Gets it from the settings the kernel obtained from the legacy drivers which "always work".

4.While they "always work" they can sometimes be buggy.
5.The kernel option I brought up provides a replacement to retrieving that very same screen information. This is now considered a default "YES" option in the kernel.

6.If it doesn't work, it falls back to the legacy drivers.

Don't know how else to explain this. I do not know either that this is the problem, however, enabling the first option above shows a major change in the way the screen looks on my computer, shrinking the font of the code displayed to a readable size during boot. Before boot, it would have to be baked in during install.
Sorry If I've upset everybody. That's all I can offer. Generally instead of being picked apart for everything I say, people try to see my point of view. This was mine, based on my experience. I'll leave it go now.

Last edited by sleekmason (2018-06-28 20:36:18)

johnraff · 2018-06-29 01:12:21

I think the installer's boot screen only uses grub if it's in efi mode - otherwise that menu is put up by isolinux.

ohnonot · 2018-06-29 02:26:51

^ good point.

Beep, please keep us updated, if you feel like messing around with the image formats some more (or maybe some hidden, unknown grub settings).

____________________________________

sleekmason wrote:

Doesn't the live kernel supply grub the initial screen settings that grub uses for it's settings on install from live cd?

what? 8)
grub's job is to load linux.
therefore, by definitoion, it cannot take any "supplies" from the kernel it is to load.
op's problem lies in either grub itself, or some setting saved on hard drive, or bios.
could be hardware trouble, but i find that unlikely, because the screenshot in post #1 clearly shows an image decoding problem (it's not garbled, the colors are reduced).

If the above code I referenced wasn't set by default in the live cd kernel version, Then the op's bios may not have been read correctly, and provided grub with the wrong initial settings. Don't be so quick to dismiss something because you are not familiar with it.

for heaven's sake.
i think we're going to have a lot of fun with you.

tynman · 2018-06-29 03:44:41

I may not understand sleekmason's point properly, but my understanding of what he/she is saying is ...

Although grub doesn't get anything from the Linux kernel when grub is running -- because Linux isn't loaded yet -- ....

grub's configuration typically does happen while Linux is running (i.e., when we run the update-grub program). So it is plausible that grub gets info about your video card and/or screen geometry, etc. from Linux, and grub configures itself accordingly for the next time it's called during the next boot.

#1 2018-06-26 12:09:19

Distorted GRUB background wallpaper

#2 2018-06-26 14:53:04

Re: Distorted GRUB background wallpaper

#3 2018-06-26 18:17:05

Re: Distorted GRUB background wallpaper

#4 2018-06-26 18:58:25

Re: Distorted GRUB background wallpaper

#5 2018-06-26 20:48:44

Re: Distorted GRUB background wallpaper

#6 2018-06-26 21:06:16

Re: Distorted GRUB background wallpaper

#7 2018-06-27 16:15:17

Re: Distorted GRUB background wallpaper

#8 2018-06-27 18:13:17

Re: Distorted GRUB background wallpaper

#9 2018-06-27 18:39:22

Re: Distorted GRUB background wallpaper

#10 2018-06-27 19:52:38

Re: Distorted GRUB background wallpaper

#11 2018-06-28 07:29:22

Re: Distorted GRUB background wallpaper

#12 2018-06-28 10:13:27

Re: Distorted GRUB background wallpaper

#13 2018-06-28 12:01:30

Re: Distorted GRUB background wallpaper

#14 2018-06-28 12:43:06

Re: Distorted GRUB background wallpaper

#15 2018-06-28 12:49:51

Re: Distorted GRUB background wallpaper

#16 2018-06-28 15:22:04

Re: Distorted GRUB background wallpaper

#17 2018-06-28 16:22:07

Re: Distorted GRUB background wallpaper

#18 2018-06-29 01:12:21

Re: Distorted GRUB background wallpaper

#19 2018-06-29 02:26:51

Re: Distorted GRUB background wallpaper

#20 2018-06-29 03:44:41

Re: Distorted GRUB background wallpaper

Board footer