Display failure on auto boot but no problem on manuel kernel selection

[MisterL55]

Hello everyone,

Since I've updated the kernel to the latest version via the update manager, I have a weird display problem when GRUB automatically selects the kernel on booting.
The screen is like 80% black, but the rest is normal.

After noticing this problem (I had this problem with other distributions such as Linux Lite, and the kernel was the faulty one), I tried to boot on the previous kernel with GRUB. Worked fine.
So I tried to boot manually on the latest kernel I can SEE on GRUB's menus(4.13.0-26 generic), just to try it out again... and surprise : it works. No display bug.

I have no clue why the system is behaving this way.
Also I don't know if the kernel's version 4.13.0-26 is the latest, but here it is. If I list all the installed kernels, this version is the latest I have on the running Linux Lint 18.3.

If this can help, the computer is a EEEpc Samsung N140. Graphics running on Intel Graphics Media Accelerator 945 (CPU ; Intel Atom N270 1,6GHz)

Is anyone having this issue? Any clues on what is happening?

Thanks in advance

[prestonR]

Asus eee-pc same processor/graphics, same graphics issue (Didn't notice, was on 4.10. with 4.13 installed). Apart from that the system runs fine, with a 10-15sec increase in boot-up time.

Removed 4.13.26 and installed 4.13.25 with the same result, no matter if I auto-boot or pick via 'Advanced options'. If I remove 4.13, update-grub and reboot with only 4.10 I'm back to normal.

However, and now it gets really weird; If I boot the second Mint (which is not in charge of grub and appears further down the list) 4.13.26 is running nicely

Maybe this points to a bug in grub? Has there been a recent update? If anyone has got an idea I'm happy to run through it.

[MisterL55]

This is indeed really weird...

I downgraded to 4.10.0.42 and deleted the 4.13.0.26 and this is booting fine now.

Let's hope a fix will be released soon.

[prestonR]

Some news on this (80% black desktop glitch on 4.13.0-26 32bit) ;

- the black bit is clickable, and all mouse-overs of windows below are visible on your cursor, if you open a terminal via keyboard you can 'feel' your way to the title bar, drag it into the 20% and use it
- if you remote desktop into your glitched machine there is no glitch, all looks and works fine
- the glitch is 'fixable'

How to 'fix' it:
- I use a script to change my eee-pc resolution on the fly, 'newrez' https://www.linux-apps.com/content/show ... ent=134686
- place newrez.sh where you can see it, the 20% strip
- run it

and the glitch is gone!

This only happens on 1 of the 2 Mint on this machine plus a Manjaro32.

[prestonR]

I believe I worked this out:
This is not a kernel issue by itself but a grub issue that is triggered by the ‘fixed’ kernels of the 4.13/4.14 series, both in Mint and Manjaro:

On a multi-boot system (2 Mint, 1 Manjaro (intel-ucode removed) whatever OS is in charge of grub will glitch when one of the ‘fixed’ kernels is booted (4.13.0-26 on Mint, 4.14.13-1 on Manjaro). Booting the ‘fixed’ kernels of the other OS further down the grub menu works fine.

If I then sudo grub-install /dev/sda from there, the error shifts to the new OS in control of grub, allowing both of the others to boot without problem, including the one that glitched when in control of grub.

In a nutshell: If you boot a ‘fixed’ kernel of the 4.13 or 4.14 series via the 2 top lines of your grub it will glitch, both on Mint and on Manjaro.

Apart from the lame work-around offered in my previous post you can also fix this for a single boot by booting the system that is in charge of grub with:

Code: Select all

GRUB_GFXPAYLOAD_LINUX=text

or fix it permanently by editing grub.cfg and either out-commenting the line

Code: Select all

GRUB_GFXPAYLOAD_LINUX=keep

so it looks like

Code: Select all

#GRUB_GFXPAYLOAD_LINUX=keep

or changing it to

Code: Select all

GRUB_GFXPAYLOAD_LINUX=text