# [HOWTO] UEFI, nvidia - made simple(fb)

## kernelOfTruth

So you want to install nvidia-drivers on an UEFI PC ?

Oftentimes when attempting to do that - one gets to one conclusion:

"One does not simply install nvidia-drivers on an UEFI system"

Yeah, well - that was at least my experience and the one of several other wanderers along the path to the promised land of "The Way It's Meant to be Played ™"

Hi guys,

when you're transitioning from a BIOS based PC to a UEFI based one,

setting up the bootloader, adding an entry to UEFI and getting it to boot up at all can be quite a chore - it took me a week to understand how all works & to collect the information of the EFI boot partition

(what a noob ! - yeah yeah   :Laughing:  )

(see https://forums.gentoo.org/viewtopic-t-992002-view-next.html)

After the dust has settled of setting up your bootloader & once you're able to boot into your new shiny installation (or if you've made a stage4 tarball of your old system and transitioned e.g. from very-old Intel to Ubercool new Intel cpu),

the main action part of the fun (emerge world) firstly begins here   :Smile: 

So you want to install the proprietary nvidia-drivers to savor some Triple A Steam games (like Metro 2033 Redux, Metro: Last Light Redux, Bioshock Infinite, ...) and cherish the power of Linux gaming ?

This can be quite troublesome since there are several ways to do it:

- uvesafb + nvidia-drivers

- efifb + nvidia-drivers

- simplefb + nvidia-drivers

- ...

and probably several more options I haven't considered

Well, if you don't have to insist on having shiny high-res boot-up graphics right from the start - let's just settle with the KISS (keep it simple, stupid) option and settle with simplefb for now

Provided of course that you can live with the following error message:

 *Quote:*   

> [   18.354144] NVRM: Your system is not currently configured to drive a VGA console
> 
> [   18.354148] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver
> 
> [   18.354150] NVRM: requires the use of a text-mode VGA console. Use of other console
> ...

 

Once you're finished with compiling through your system and fine-tuning it, you can get into the gory act of attempting to get uvesafb running   :Wink: 

(uvesafb didn't always work for me - so it was quite a relief to have simplefb)

So what do we need to get this running ? (long version) 

For short version: https://forums.gentoo.org/viewtopic-p-7719338.html#7719338  

Kernel configuration:

 *zcat /proc/config.gz | grep -i CONFIG_FB wrote:*   

>  Framebuffer Devices 

 

```

CONFIG_FB=y

CONFIG_FB_CMDLINE=y

# CONFIG_FB_DDC is not set

# CONFIG_FB_BOOT_VESA_SUPPORT is not set

CONFIG_FB_CFB_FILLRECT=y

CONFIG_FB_CFB_COPYAREA=y

CONFIG_FB_CFB_IMAGEBLIT=y

# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set

# CONFIG_FB_SYS_FILLRECT is not set

# CONFIG_FB_SYS_COPYAREA is not set

# CONFIG_FB_SYS_IMAGEBLIT is not set

# CONFIG_FB_FOREIGN_ENDIAN is not set

# CONFIG_FB_SYS_FOPS is not set

# CONFIG_FB_SVGALIB is not set

# CONFIG_FB_MACMODES is not set

# CONFIG_FB_BACKLIGHT is not set

CONFIG_FB_MODE_HELPERS=y

CONFIG_FB_TILEBLITTING=y

# CONFIG_FB_CIRRUS is not set

# CONFIG_FB_PM2 is not set

# CONFIG_FB_CYBER2000 is not set

# CONFIG_FB_ARC is not set

# CONFIG_FB_ASILIANT is not set

# CONFIG_FB_IMSTT is not set

# CONFIG_FB_VGA16 is not set

# CONFIG_FB_UVESA is not set

# CONFIG_FB_VESA is not set

# CONFIG_FB_EFI is not set

# CONFIG_FB_N411 is not set

# CONFIG_FB_HGA is not set

# CONFIG_FB_OPENCORES is not set

# CONFIG_FB_S1D13XXX is not set

# CONFIG_FB_NVIDIA is not set

# CONFIG_FB_RIVA is not set

# CONFIG_FB_I740 is not set

# CONFIG_FB_LE80578 is not set

# CONFIG_FB_INTEL is not set

# CONFIG_FB_MATROX is not set

# CONFIG_FB_RADEON is not set

# CONFIG_FB_ATY128 is not set

# CONFIG_FB_ATY is not set

# CONFIG_FB_S3 is not set

# CONFIG_FB_SAVAGE is not set

# CONFIG_FB_SIS is not set

# CONFIG_FB_VIA is not set

# CONFIG_FB_NEOMAGIC is not set

# CONFIG_FB_KYRO is not set

# CONFIG_FB_3DFX is not set

# CONFIG_FB_VOODOO1 is not set

# CONFIG_FB_VT8623 is not set

# CONFIG_FB_TRIDENT is not set

# CONFIG_FB_ARK is not set

# CONFIG_FB_PM3 is not set

# CONFIG_FB_CARMINE is not set

# CONFIG_FB_SMSCUFX is not set

# CONFIG_FB_UDL is not set

# CONFIG_FB_VIRTUAL is not set

# CONFIG_FB_METRONOME is not set

# CONFIG_FB_MB862XX is not set

# CONFIG_FB_BROADSHEET is not set

# CONFIG_FB_AUO_K190X is not set

CONFIG_FB_SIMPLE=y

```

 *zcat /proc/config.gz | grep -i CONFIG_DRM wrote:*   

>  DRM - Direct Rendering Manager (Opensource Acceleration

 

```

# CONFIG_DRM is not set
```

Kernel permissions:

```
chmod -R go+rX /usr/src/linux-3.19
```

```
chmod 755 /lib/modules/3.19/
```

otherwise it's possible that you'll get an error message that files in /usr/src/linux/include can't be read

or some other kernel version thingy

Mesa configuration:

 *Quote:*   

> eselect opengl list
> 
> Available OpenGL implementations:
> 
>   [1]   nvidia *
> ...

 

if the nvidia mesa implementation is at 1

```
eselect opengl set 1
```

X-Server configuration:

http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers#The_X_server

```
Section "Device"

   Identifier  "nvidia"

   Driver      "nvidia"

 EndSection

```

 *Sample xorg.conf wrote:*   

> the one I'm currently using

 

(Since evdev several months before decided to stop playing fair - probably due to switching to eudev, udev and all this systemd-related mess; I'm using the kbd and mouse drivers)

```
# nvidia-xconfig: X configuration file generated by nvidia-xconfig

# nvidia-xconfig:  version 331.38  (buildmeister@swio-display-x64-rhel04-15)  Wed Jan  8 19:53:14 PST 2014

Section "ServerLayout"

    Identifier     "Layout0"

    Screen      0  "Screen0"

    InputDevice    "Keyboard0" "CoreKeyboard"

    InputDevice    "Mouse0" "CorePointer"

EndSection

Section "Files"

EndSection

Section "InputDevice"

    # generated from data in "/etc/conf.d/gpm"

    Identifier     "Mouse0"

    Driver         "mouse"

    Option         "Protocol"

    Option         "Device" "/dev/input/mice"

    Option         "Emulate3Buttons" "no"

    Option         "ZAxisMapping" "4 5"

EndSection

Section "InputDevice"

    # generated from default

    Identifier     "Keyboard0"

    Driver         "kbd"

        Option          "XkbRules"      "xorg"

        Option          "XbkModel"      "pc105"

        Option          "XkbLayout"     "de"

EndSection

Section "Monitor"

    Identifier     "Monitor0"

    VendorName     "Unknown"

    ModelName      "Unknown"

    HorizSync       28.0 - 33.0

    VertRefresh     43.0 - 72.0

    Option         "DPMS"

EndSection

Section "Device"

    Identifier     "Device0"

    Driver         "nvidia"

    VendorName     "NVIDIA Corporation"

##    Option      "GlyphCache"            "1"

##    Option      "InitialPixmapPlacement"   "2"

##    Option      "DamageEvents"             "1"

EndSection

Section "Screen"

    Identifier     "Screen0"

    Device         "Device0"

    Monitor        "Monitor0"

    DefaultDepth    24

    SubSection     "Display"

        Depth       24

    EndSubSection

EndSection

```

Bootloader (aka kernel append option):

append the following to your kernel parameters:

```
console=tty1 nomodeset
```

----------

## kernelOfTruth

Tl;dr (aka Checklist)

* Kernel configuration

Device Drivers -> Graphics support -> 

```
< > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
```

(de-selected)

Device Drivers -> Graphics support -> Frame buffer Devices -> 

```
[*] Enable Video Mode Handling Helpers

[*] Enable Tile Blitting Support

[*] Simple framebuffer support
```

* Kernel permissions

* Mesa (eselect mesa)

* X-Server configuration (xorg.conf) 

* Bootloader

```
console=tty1 nomodeset
```

----------

## poncho

It should be possible to enable CONFIG_DRM and skip the "X-Server configuration" part.

```
cat /usr/share/X11/xorg.conf.d/50-nvidia-drm-outputclass.conf

# This xorg.conf.d configuration snippet configures the X server to

# automatically load the nvidia driver when it detects a device driven by the

# nvidia.ko kernel module.  Please note that this only works on Linux kernels

# version 3.9 or higher with CONFIG_DRM enabled, and only if the nvidia.ko

# kernel module is loaded before the X server is started.

Section "OutputClass"

    Identifier     "nvidia"

    MatchDriver    "nvidia-drm"

    Driver         "nvidia"

EndSection
```

----------

## kernelOfTruth

Thanks for your input poncho !

good to know that it would work with that enabled

well, your approach is close to the way Ubuntu or Debian do it (nouveau, etc. kernel modules ARE compiled - the kernel is NOT changed during installation 

and allows for a greater flexibility since you only need to blacklist the kernel modules).

It comes down what the user's preferred way of doing things is.

The gentoo wiki does show this same way or the way that was pointed out to me in the past,

and I'm following that since it has worked fine so far,

also there's less confusion and more clarity (you're only going for the one approach),

later on don't need to un-blacklist the kernel modules, etc.

 *https://wiki.gentoo.org/wiki/NVidia/nvidia-drivers#Direct_rendering_is_not_enabled wrote:*   

> Direct rendering is not enabled
> 
> If direct rendering does not work, it may be because the kernel has Direct Rendering Manager enabled, which conflicts with the driver. See the direct rendering status by following instructions in the section Testing the card.
> 
> First, disable Direct Rendering Manager (CONFIG_DRM) in the kernel :

 

```
Disabling Direct Rendering Manager

Device drivers --->

    Graphics support --->

        < > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
```

----------

## Silent-Hunter

I can't find several of these in the menuconfig. fillrect is missing for example. How do I enable these through the menu?

EDIT: I found the options. Still, following these directions precisely gives nothing after "Loading initial ramdisk ...". Was there something I missed?

----------

## kernelOfTruth

@Silent-Hunter:

you, by chance, are running a laptop with optimus where the dedicated CPU can not be enabled and thus the other one disabled in BIOS ?

I took a look what other options might be related 

and stumbled over the following:

```
<*> /dev/agpgart (AGP Support)

<*>   Intel 440LX/BX/GX, I8xx and E7x05 chipset support

<M>

<M>

<M>

[*] CONFIG_FIRMWARE_EDID

[*] CONFIG_VGA_CONSOLE

<*> CONFIG_FRAMEBUFFER_CONSOLE

[*] CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY

[*] Bootup logo  ---> 

[*]   Standard black and white Linux logo

[*]   Standard 224-color Linux logo

```

Only the firmware_EDID, vga_console and other framebuffer_console settings are relevant though

the logo is nice to have and the AGP probably will not even make a change (since there's no AGP on this system anymore   :Rolling Eyes:   )

Could you post some details of your system ?

edit:

I haven't tried this out on notebooks yet where you e.g. can't disable the iGPU of the Intel processor

if simplefb doesn't work out for you

how about uvesafb ?

I'm continuing to post on your thread

----------

## steveL

Nice tip KoT :-) (Installation: "UEFI and nvidia")

Keep up the good work, as ever.

----------

## photonic

Very nice guide, thanks for the work.

----------

## steveL

With regard to the error message ("NVRM: Your system is not currently configured to drive a VGA console"), blugendoo points out:

NVidia says:  *Quote:*   

> The message is a little misleading in UEFI mode. What it means it that the GPU was initialized to a graphical mode using the legacy VGA BIOS, regardless of whether the system was booted in UEFI mode or not. Typically this happens if the Compatibility Support Module (CSM) is enabled in the system BIOS. If you have an option to disable CSM in the SBIOS, please try that.

 

 *blugendoo wrote:*   

> So I'll try with pure EFI boot, as initially intended. I've kept EFI+CSM compatibility to be able to boot my current Linux Mint system.

 

----------

## VinzC

Thank you very much, KernelOfTruth for this guide as I believe it contains hints as to a problem that I've just experienced.

Just some clarification though. When you say "install nvidia-drivers on an UEFI PC" what do you mean exactly? I'm asking because I do have a computer with a UEFI motherboard — an ASUS P8H67-M. I bought it a couple of years ago and never experienced a hiccup with Gentoo: proprietary nVidia drivers coexisted with uvesafb and I boot my PC with extlinux, not Grub. No problem until today, as I've just updated about 390 packages (I don't upgrade very often and only rarely get bitten but that's another story) including nvidia drivers, from 352.x to 361.y.

So basically I do have a UEFI computer but what you described didn't seem to apply to me until now. What have I missed? How are nvidia drivers related to UEFI?

Now to the issue I've just ran into.

After the upgrade I noticed switching away from X (e.g. to a text console) then back froze the computer. The only option was (still is) the magic SysRq key (sync, boot). I suppose what you described here is the reason for this lock-up?

For the record, I'm considering switching to nouveau. There have been quite a lot of changes since I last tried it. Any recommendation?

----------

## kernelOfTruth

 *VinzC wrote:*   

> Thank you very much, KernelOfTruth for this guide as I believe it contains hints as to a problem that I've just experienced.
> 
> Just some clarification though. When you say "install nvidia-drivers on an UEFI PC" what do you mean exactly? I'm asking because I do have a computer with a UEFI motherboard — an ASUS P8H67-M. I bought it a couple of years ago and never experienced a hiccup with Gentoo: proprietary nVidia drivers coexisted with uvesafb and I boot my PC with extlinux, not Grub. No problem until today, as I've just updated about 390 packages (I don't upgrade very often and only rarely get bitten but that's another story) including nvidia drivers, from 352.x to 361.y.
> 
> So basically I do have a UEFI computer but what you described didn't seem to apply to me until now. What have I missed? How are nvidia drivers related to UEFI?
> ...

 

Hi VinzC,

as steveL pointed out with that message, I'm currently booting in EFI+CSM compatibility mode,

there were some issues with getting it to work with vesafb, uvesafb, etc. the first time I tried to get my new PC to boot into Gentoo.

It was a migration from BIOS -> UEFI so the two hurdles were to set up the EFI partition + grub2 and getting into terminal at first 

(I had backed up my system from the previous PC with Core i7 and extracted it on the new SSD)

the trouble was that afaik in the beginning I would get NO screen output at all - vesafb or uvesafb would either hardlock - or some other non-usable behavior (can't really remember anymore since some time has passed),

after quite some research I stumbled upon simpleFB and that turned out to work quite well, despite that scary message of NVRM:

I could boot into the system and get the nvidia-drivers to work,

second approach later was to compile the nouveau driver into the kernel and boot it up with KMS and get meaningful output of the kernel and init steps right from the start

(that was the 3rd hurdle I had, afaik, that some scripts weren't set up correctly - e.g. luks, etc.)

Highly probable - yes, if you're using uvesafb and switching between VT <-- --> X that could lead to lockups (it did for me)

Regard nouveau:

there was some time when it got quite unstable so that I only could use nvidia-drivers (which I still do right now),

a reason was the DRI 3 acceleration, some weird access pattern/permissions to VRAM (if I remember correctly) which needed a patch (which isn't included yet in the kernel ?)

but it seems to work again without it,

in case you run into instabilities - try

```
   Option         "DRI3"               "0"
```

I'm currently also carrying along in /etc/modprobe.d/nvidia.conf

(for nvidia-drivers)

```
# Nvidia drivers support

alias char-major-195 nvidia

alias /dev/nvidiactl char-major-195

# To tweak the driver the following options can be used, note that

# you should be careful, as it could cause instability!! For more 

# options see /usr/share/doc/nvidia-drivers-367.27/README

#

# !!! SECURITY WARNING !!!

# DO NOT MODIFY OR REMOVE THE DEVICE FILE RELATED OPTIONS UNLESS YOU KNOW

# WHAT YOU ARE DOING.

# ONLY ADD TRUSTED USERS TO THE VIDEO GROUP, THESE USERS MAY BE ABLE TO CRASH,

# COMPROMISE, OR IRREPARABLY DAMAGE THE MACHINE.

options nvidia NVreg_DeviceFileMode=432 NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=27 NVreg_ModifyDeviceFiles=1

options nvidia NVreg_EnableMSI=1

options nvidia NVreg_RegisterForACPIEvents=0

options nvidia NVreg_UsePageAttributeTable=1

```

which seems to improve things,

last time I left it out I had latency issues (?),

anyway - that's all I currently can think of

Hope it helps

----------

## VinzC

Thanks again for these insights. As a matter of fact I now experience lockups with nouveau, too   :Sad:  . I can get the computer to reboot from SSH btu it's about all I can do. FTR lockups occur while browsing google maps, go the f*** figure! I'm not sure which is the most annoying so far... (ah computers  :Evil or Very Mad:  !)

So maybe I'll turn nVidia drivers in again. Which of course now means no more fancy pancy bootsplash... *sighs*

(Why does it have to be so complicated!)

----------

## AaylaSecura

Just to share my experience: I have ASUS X99, but I was booting in BIOS mode until yesterday when I decided to swicth to UEFI (all went more quickly and painfree than I thought). I found out that since recently nvidia-drivers support KMS and I was trying to get it to work but I couldn't (in BIOS mode): I kept getting black screen (tried vesafb and no fb at all) even though dmesg showed no errors and all the modules were loaded properly. When I switched to UEFI mode (converted from MBR to GPT, disabled CSM completely and built an EFI stub kernel). I was finally able to get KMS with nvidia-drivers. I read on the Arch wiki that nvidia-drivers still do not support a high resolution console using vesafb (don't know about uvesa), but they do using efifb, so I only tried efifb; and it worked (and the resolution is high) It's imperative that CONFIG_DRM is enabled and that nvidia_drm module is loaded with modeset=1. Here are the relevant options I have:

```
zcat /proc/config.gz | sed -n '/^CONFIG_\(DRM\|FB\)/p'

CONFIG_DRM=y

CONFIG_DRM_KMS_HELPER=y

CONFIG_DRM_KMS_FB_HELPER=y

CONFIG_DRM_FBDEV_EMULATION=y

CONFIG_DRM_BRIDGE=y

CONFIG_FB=y

CONFIG_FB_CMDLINE=y

CONFIG_FB_NOTIFY=y

CONFIG_FB_CFB_FILLRECT=y

CONFIG_FB_CFB_COPYAREA=y

CONFIG_FB_CFB_IMAGEBLIT=y

CONFIG_FB_SYS_FILLRECT=y

CONFIG_FB_SYS_COPYAREA=y

CONFIG_FB_SYS_IMAGEBLIT=y

CONFIG_FB_SYS_FOPS=y

CONFIG_FB_EFI=y

```

To clarify I am doing a native UEFI boot (not Grub, no nothing).

P.S. Disabling CONFIG_DRM and blacklisting the nvidia module instead works great too, again using efifb (no KMS).

----------

## VinzC

@AaylaSecura,

Thanks a lot for your interesting post.

From your message I understand that (U)EFI boot implies no bootloader, is that correct...? That sure spares the "hassle" of selecting which boot loader to install (I prefer syslinux over Grub though) but in the meantime how are arguments supposed to be passed to the kernel then?

I guess there's always the possibility to store them in the kernel configuration but I'm curious — FTR I'm asking because I always viewed (U)EFI as evil since it takes the control away from the user and puts it into the hands of manufacturers, i.e. people we, users don't know. And who reasonably trusts someone she doesn't know...? Well, I mean I didn't dig hard into UEFI, for short. Hence my question. Off-topic, I admit...

----------

## 324874

The previous post has been removed due to changes and therefore it was no longer relevant in this thread.

Best regards, feng.Last edited by 324874 on Sat Aug 20, 2016 6:48 am; edited 5 times in total

----------

## AaylaSecura

 *VinzC wrote:*   

> From your message I understand that (U)EFI boot implies no bootloader, is that correct...? That sure spares the "hassle" of selecting which boot loader to install (I prefer syslinux over Grub though) but in the meantime how are arguments supposed to be passed to the kernel then?

 

VinzC, that's right. The kernel has had support for native UEFI boot for some time now. This means the kernel image can appear to the UEFI firmware (which is looking for a bootloader on the EFI partition) as a bootloader and can be executed by the firmware directly. As far as I know there is no way to pass parameters during boot (the way you would for example using GRUB by pressing e to edit the options, or rEFInd by pressing F2) but you don't have to hard code the cmdline into the image: you can use efibootmgr to edit/add/delete entries in the boot menu of the UEFI firmware. (I read however it's dangerous to use on Apple hardware, even if it's Intel based, as it's been reported to damage the firmware, but I guess this doesn't concern you). Have a read about "EFI stub kernel" (a kernel that's able to act as an EFI bootloader) and efibootmgr. The handbook also has EFI specific information in most sections.

----------

## VinzC

Thanks a lot, AaylaSecura. May the Force be with you  :Wink:  .

----------

## Catanduva

nvidia_drivers + simple_fb is working even with DRM active. Ugly big old school console tty, but at least it works.

With efi_fb i got a black screen. It boots and i can login and do startx, but console is just black.

It would be nice to have a bigger console, but i can live with that.

----------

## Mapt

My current state (december 2019):

```

~ # uname -a 

Linux mpc 4.19.86-gentoo #1 SMP Fri Dec 6 13:06:16 +04 2019 x86_64 Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz GenuineIntel GNU/Linux

~ # lspci | grep -i vga

01:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1)

~ # dmesg | grep "DMI:"

[    0.000000] DMI: MSI MS-7A72/H270 PC MATE (MS-7A72), BIOS 2.20 12/07/2016

~ # fdisk -l /dev/nvme0n1

Disk /dev/nvme0n1: 232.91 GiB, 250059350016 bytes, 488397168 sectors

Disk model: Samsung SSD 960 EVO 250GB               

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: gpt

Disk identifier: 7FEFAE4C-BF9F-4C1B-BB25-E8DB9A80756B

Device          Start       End   Sectors   Size Type

/dev/nvme0n1p1   2048      6143      4096     2M BIOS boot

/dev/nvme0n1p2   6144    268287    262144   128M EFI System

/dev/nvme0n1p3 268288 488395119 488126832 232.8G Linux filesystem

~ # emerge --info nvidia-drivers

x11-drivers/nvidia-drivers-440.36-r1::gentoo was built with the following:

USE="X acpi driver kms multilib tools -compat -gtk3 (-libglvnd) -static-libs -uvm -wayland" ABI_X86="(64) -32 (-x32)"

```

Many years i stand at legacy bios mode, gpt, grub-pc install. In this i has black screen problem in grub. But my kernel framebuffer output and nvidia drivers in X worked normal.

Some days ago i think "wtf, 2019 now! goto UEFI, old fogey".

I recreate boot partition to vfat, reinstall grub with x86_64-efi, turn on UEFI in bios settings, reboot in feature. Results:

* Yes, grub black window problem solved.

* Yes, nvidia in X work fine, too.

* But i have new problem: black screen while kernel loading, and if we go to console (ctrl+alt+f1).

I hope this howto fix my problem, but it doesnt.

I think "hmmm, check another distro, get ubuntu, but it use nouveau as module. Output work fine, but with delay. And nouveau with my card work unstable.

Parallel i test many other ways:

* efifb

* vesa

* nouveau

* video=simplefb

* nvidia-drm.modeset=1

* nomodeset

* etc...

And no result.

Does you know any solution of this problem?

```

~ # zcat /proc/config.gz > /usr/src/config

https://pastebin.com/Cj3eFsQy

~ # dmesg

https://pastebin.com/cS3GMyQh

```

----------

## wolfieh

I've been using efifb for a while with no issues (proprietary drivers). You need to disable the CONFIG_X86_SYSFB (Mark VGA/VBE/EFI FB as generic system framebuffer) kernel option for it to work, and set video mode with GRUB

----------

