Graphics is corrupt on VT1-VT7 even during boot

[Jarl]

This is on an Acer Aspire One (https://en.wikipedia.org/wiki/Acer_Aspire_One) after upgrading from ubuntu 17.04 to 17.10

When booting. At the time where the load screen flashing "Kubuntu" is normally displayed, the graphics is corrupted. Both on text terminals VT1-VT6 and graphics terminal VT7

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: grub2 (not installed)
ProcVersionSignature: Ubuntu 4.13.0-17.20-generic 4.13.8
Uname: Linux 4.13.0-17-generic i686
ApportVersion: 2.20.7-0ubuntu3.5
Architecture: i386
CurrentDesktop: KDE
Date: Sun Dec 3 20:44:14 2017
InstallationDate: Installed on 2014-12-15 (1084 days ago)
InstallationMedia: Kubuntu 14.10 "Utopic Unicorn" - Release i386 (20141022.1)
SourcePackage: grub2
UpgradeStatus: Upgraded to artful on 2017-12-02 (0 days ago)

[Jarl (jarl-dk)]

During an attempt to solve the problem myself I discovered
*) The problem did not exist on ubuntu 17.04
*) When removing the option `gfxmode $linux_gfx_mode` in the grub2 boot config. It boots perfectly fine.
*) When investigating the value `$linux_gfx_mode` in the boot console, the value is `keep`.
*) According to the grub2 manual (https://www.gnu.org/software/grub/manual/grub/html_node/gfxmode.html), then `keep` is not a valid value for the `gfxmode` variable. However the value `keep` is a valid value for the `gfxpayload` variable, see https://www.gnu.org/software/grub/manual/grub/html_node/gfxpayload.html#gfxpayload

And when looking into how the `$linux_gfx_mode` is assigned the value in the `/boot/grub/grub.cfg` (line 119-136) where it achieves either the value `text` or `keep`. It looks like this value should be used to set the `gfxpayload` variable in stead of `gfxmode`.

[Jarl (jarl-dk)]

Here is a proposed patch against master that should resolve the problem...
Disclaimer: The patch has not been tested as I don't know how to build and test a package.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Git_patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Jarl (jarl-dk)]

This is a more proper patch.

[Jarl (jarl-dk)]

This is the same patch, but rebased to the latest master on git.

[Colin Watson (cjwatson)]

I don't think that patch actually results in any effective change at boot time.

- echo " gfxmode \$linux_gfx_mode" | sed "s/^/$submenu_indentation/"
+ echo " gfxpayload \$linux_gfx_payload" | sed "s/^/$submenu_indentation/"

... but gfxmode is a function, and its definition hasn't meaningfully changed here. All you've done is rename it. Likewise, linux_gfx_mode is only used within this file, and you've just changed all references to it, so nothing actually changes.

And while in some ways it could be argued that the changed names are less confusing, the value of GRUB's gfxpayload variable does still describe a mode - the difference between the gfxmode and gfxpayload variables is that the first sets the mode for GRUB's graphical terminal while the second sets the mode that the Linux kernel starts in, but they're still both modes, so I would definitely argue that "linux_gfx_mode" is still a good choice of variable name.

The thing that confused you is that the "gfxmode" *function* is used to set the "gfxpayload" *variable* (among other functions), which I'll concede is a bit confusing. But it doesn't make any difference to GRUB that the argument passed to the gfxmode function isn't a valid value for the gfxmode variable, because it isn't used to set that variable.

So ... I think you need to research this further, and the problem is probably just that this is hardware on which gfxpayload=keep doesn't work. Perhaps this is a kernel bug, and/or perhaps it needs to be blacklisted in the grub-gfxpayload-lists package (note also the update-grub-gfxpayload manual page in that package that describes a local workaround).

[Jarl (jarl-dk)]

Thanks for the feedback, Colin.

I will do some more research/testing.

At least for now here is a workaround:
1) when booting, enter grub startup menu
2) enter 'e' to edit command before upstart
3) delete the line saying "gfxmode $linux_gfx_mode"
4) hit CTRL-x to start boot

Another thing that works (more permanently) is to add a line
GRUB_GFXPAYLOAD_LINUX=text
to /etc/default/grub as described in the manual page for update-grub-gfxpayload and run `sudo update-grub` after that.

Jarl

[Mathieu Trudel-Lapierre (cyphermox)]

Assigning to linux to we can investigate whether this is caused by a kernel bug.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1736023

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Jarl (jarl-dk)]

After upgrading ubuntu to 18.04 I can no longer reproduce this problem using unmodified package-installed grub files.

So if nobody else can reproduce this problem I suggest it is closed as fixed in 18.04.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]

[Jarl (jarl-dk)]

I change status to fixed released as per comment#11