Framebuffer setting in GRUB_CMDLINE_LINUX_DEFAULT has no effect

Bug #1828273 reported by John Bester
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
New
Undecided
Unassigned

Bug Description

I have an Ubuntu Server 18.04 installation with KVM and a guest OS to which a AMD video card needs to be passed through. It worked great for about 9 months and after a recent Ubuntu upgrade, efifb grabs the video card irrespective of the linux command line. The commnand line that worked before is:

GRUB_CMDLINE_LINUX_DEFAULT="amd_iommu=on iommu=pt pci_stubs=1106:3483 vga=normal nofb nomodeset video=efifb:off"

Currently, this is the command line (changes I made based on searching the web for hours):
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt earlymodules=vfio-pci pci_stubs=1106:3483 vga=normal nofb nomodeset video=vesafb:off,efifb:off gfxpayload=text"

The current active kernel options (proc/cmdline)

BOOT_IMAGE=/boot/vmlinuz-4.15.0-48-generic root=UUID=a83137ad-9598-4dc2-aca9-7ab19d17d3c0 ro quiet amd_iommu=on iommu=pt earlymodules=vfio-pci pci_stubs=1106:3483 vga=normal nofb nomodeset video=vesafb:on,efifb:off gfxpayload=text

This is verified by syslog:

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-48-generic root=UUID=a83137ad-9598-4dc2-aca9-7ab19d17d3c0 ro quiet amd_iommu=on iommu=pt earlymodules=vfio-pci pci_stubs=1106:3483 vga=normal nofb nomodeset video=vesafb:on,efifb:off gfxpayload=text

According to one of the web sites I found, any (or all) of the following options should disable the frame buffer:

vga=normal nofb nomodeset video=vesafb:on,efifb:off

Yet, a framebuffer is still created

crw-rw---- 1 root video 29, 0 May 8 18:26 /dev/fb0

Memory locked by efifb (grep -B 5 -A 5 "26[:]00" /proc/iomem)

e0000000-fec2ffff : PCI Bus 0000:00
  e0000000-f01fffff : PCI Bus 0000:26
    e0000000-efffffff : 0000:26:00.0
      e0000000-e01effff : efifb
    f0000000-f01fffff : 0000:26:00.0
      f0000000-f01fffff : vfio-pci

Yet, vfio driver is successfully loaded for this device: (ls /sys/bus/pci/drivers/vfio-pci/)

/sys/bus/pci/drivers/vfio-pci/0000:26:00.0
/sys/bus/pci/drivers/vfio-pci/0000:26:00.1

Any help on how efifb can be blocked from loading will be greatly appreciated.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: grub2-common 2.02-2ubuntu8.13
ProcVersionSignature: Ubuntu 4.15.0-47.50-generic 4.15.18
Uname: Linux 4.15.0-47-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: GNOME
Date: Wed May 8 19:32:36 2019
InstallationDate: Installed on 2017-01-12 (846 days ago)
InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
SourcePackage: grub2
UpgradeStatus: Upgraded to bionic on 2018-09-27 (223 days ago)

Revision history for this message
John Bester (stellenbosser) wrote :
Revision history for this message
John Bester (stellenbosser) wrote :

I found another comment online and tried it: I added "blacklist efifb" to /etc/modprobe.d/blacklist-framebuffer.conf. I then executed "update-initramfs -u" followed by "update-grub" and rebooted. Still no joy.

Revision history for this message
John Bester (stellenbosser) wrote :

Found another page stating that vga=0 should be in GRUB_CMDLINE_LINUX_DEFAULT - this does not work either.

Another page states that you should enable GRUB_TERMINAL=console, this does not work.

Another page says you should add "blacklist vga16fb" in /etc/modprobe.d/blacklist-framebuffer.conf, this does not work

Is there any way I can destroy /dev/fb0 or onload efifb after Linux has booted?

Revision history for this message
John Bester (stellenbosser) wrote :

Yet another comment I found said that the following would work, but it did not:
systemctl set-default -f multi-user.target

Take into account that this is Ubuntu Server 18.04. Server operating system should not rely on graphics cards, so it should be possible to boot Ubuntu Server without a framebuffer.

Is there a systemd service which I can blacklist to avoid the framebuffer being created?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.