Every second(?) boot fails to display anything [MSHYBRID mode]

[Chris Halse Rogers]

When this laptop's firmware is set to MSHYBRID mode (intel/nvidia switchable graphics) it seems that every second boot it fails to display anything.

This appears to be regardless of whether or not I enter the grub menu.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: linux-image-4.13.0-12-generic 4.13.0-12.13
ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
Uname: Linux 4.13.0-12-generic x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.20.7-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: chris 3020 F.... pulseaudio
CurrentDesktop: GNOME
Date: Thu Sep 28 13:41:53 2017
InstallationDate: Installed on 2017-09-20 (8 days ago)
InstallationMedia: Ubuntu-GNOME 17.10 "Artful Aardvark" - Alpha amd64 (20170919)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 8087:0a2b Intel Corp.
 Bus 001 Device 002: ID 1c7a:0603 LighTuning Technology Inc.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: System76 Oryx Pro
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-12-generic.efi.signed root=ZFS=rpool/system ro
RelatedPackageVersions:
 linux-restricted-modules-4.13.0-12-generic N/A
 linux-backports-modules-4.13.0-12-generic N/A
 linux-firmware 1.168
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 02/20/2017
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.05.02dRSA1 02/20/2017
dmi.board.asset.tag: Tag 12345
dmi.board.name: Oryx Pro
dmi.board.vendor: System76
dmi.board.version: oryp3-ess
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: System76
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.05.02dRSA102/20/2017:bd02/20/2017:svnSystem76:pnOryxPro:pvroryp3-ess:rvnSystem76:rnOryxPro:rvroryp3-ess:cvnSystem76:ct10:cvrN/A:
dmi.product.family: Not Applicable
dmi.product.name: Oryx Pro
dmi.product.version: oryp3-ess
dmi.sys.vendor: System76

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

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.14 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14-rc2/

[Kai-Heng Feng (kaihengfeng)]

Is GRUB itself drawn on the screen?

[Chris Halse Rogers (raof)]

Yes. In all cases, GRUB itself draws fine.

On further experimentation, it seems that it might be the case that the
boot after a *failed* boot works.

If nothing is visible and I blindly enter my cryptroot password it can
boot all the way; rebooting with ctrl-alt-delete after that seems to
result in another faliure to display anything on the subsequent boot.

Restarting with ctrl-alt-delete from the (unseen) initramfs prompt
seems to reliably result in the subsequent boot getting displayed.

This does not seem to be related to $VT_HANDOFF in GRUB; whether or not
it is enabled in grub.cfg does not appear to make a difference.

[Kai-Heng Feng (kaihengfeng)]

Edit the Ubuntu boot entry in Grub menu, change "gfxmode $linux_gfx_mode" to "gfxmode text".
I think this can workaround your issue.

[Kai-Heng Feng (kaihengfeng)]

If this work, it's probably due to buggy VBIOS.

[Chris Halse Rogers (raof)]

You are absolutely correct; forceing “gfxmode text” appears to make
booting reliably visible.

That's a nice workaround.

I guess this is a buggy VBIOS issue, then.

[James Gross (xeboc)]

System76 here. We have also had luck with this grub flag:

GRUB_GFXPAYLOAD_LINUX=1920*1080

[Kai-Heng Feng (kaihengfeng)]

Can you attach the output of "videoinfo" under GRUB?

[Kai-Heng Feng (kaihengfeng)]

Debian bug [1] is resolved by introducing a patch that has "set gfxpayload=keep" when kernel uses config "CONFIG_FB_EFI=y".

A new feature is introduce by patch [2], to enable gfxpayload=keep dynamically. The blacklist is in package "grub-gfxpayload-lists".

The package is depends on "grub-pc", which conflicts grub-efi-*. So on EFI systems, there's no blacklist mechanism to use.

It's 2017, yet we can still see this bug on new systems. I guess go back to the old behavior "gfxpayload=text" will be really desirable.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567245
[2] https://anonscm.debian.org/cgit/pkg-grub/grub.git/tree/debian/patches/gfxpayload_dynamic.patch

[Steve Langasek (vorlon)]

This sounds like the same as bug #1711452.

[Kai-Heng Feng (kaihengfeng)]

I think this one is the reversed of bug #1711452.

The system I have does not display anything when gfxpayload=keep.
When using gfxpayload=text, it works normally.

IIUC, in text mode, grub will still try to iterate all available modes, I guess that's why the issue is gone under "gfxpayload=text"?

[Chris Halse Rogers (raof)]

Oh, it might be worth mentioning - on the boots where I wouldn't see anything, adding the fbcon=map:1 parameter to the kernel command line gives a usable system - the console and X¹ both come up correctly.

¹: For X there's an additional wrinkle in that the hybrid graphics detection in gpu-detect fails to correctly identify the need for offloading, but if I have a correct Xorg.conf already in place X will run just fine.

[Kai-Heng Feng (kaihengfeng)]

Do you mean gpu-manager?

What's the output of "systemctl status gpu-manager"?

[Mathieu Trudel-Lapierre (cyphermox)]

Is this still reproducible? We have changed the default gfx mode to stay "text" on EFI.

[Chris Halse Rogers (raof)]

I have made some changes to my configuration, so it's not an entirely clean test, but I *did* notice that I no longer needed to mess with gfxpayload. I guess that it's fixed?