Black screen when booting in UEFI mode to install Qubes OS

[Simon-Davies]

I have a Dell XPS 15 Intel i9 and cannot install Qubes OS in UEFI mode.

I have updated the BIOS firmware. The system is UEFI mode only and when I boot the installation media I get a black screen before getting to the installer setup.

I have tried the steps in: Installation freezes before getting to Anaconda (Qubes 4.0) in the UEFI Troubleshooting Guide.

I have also added the kernel parameter to blacklist the nouveau driver like I did on my older Dell XPS 15 Intel i7 which Qubes OS installed on.

After commenting out the lines as suggested in the UEFI Troubleshooting Guide it now goes black and reboots. Before it went black and didn't reboot until I pressed Crl + Alt + Del.

[andrewdavidwong]

Based on our issue reporting guidelines, this appears to be too localized for qubes-issues, since it depends on a specific hardware configuration. We ask that you please send this to the qubes-users mailing list instead. qubes-users is intended for these sorts of issues and receives much more traffic, which means that your issue is more likely to receive a response there. If, after reading our issue reporting guidelines, you believe we are mistaken, please leave a comment briefly explaining why. We'll be happy to take another look, and, if appropriate, reopen this issue. Thank you for your understanding.

[anon8675309]

I have this same issue and I am not sure if it is a hardware specific issue. I booted from an Ubuntu Server 16.04 USB drive in UEFI mode and it worked just fine. The Qubes USB drive just goes to a black screen. It is not a general problem of "this computer won't boot to USB drives via UEFI" but it may be that the Qubes installer is set up in such a way that it's incompatible with certain hardware.

For future DuckDuckGoers, I was able to boot into the text based installer by booting from the drive in Legacy mode, using the "inst.text nomodeset" boot options (select the install Qubes with (or without) media check, press tab, put these right before "quiet"). This also works around the graphics issue that might frustrate you for several days. The text based installer is also broken (tickets #2113 #1161), but if you plug in a network adaptor, alt+tab to the terminal, use dhclient to get an IP address, use ip a to see the IP, remove /var/run/anaconda.pid, and run anaconda --vnc --vncpassword pass1234 and connect to your IP with a VNC client on port 5901, the install will work fine... but then you'll be left with the problem of not being able to boot to the SSD because UEFI doesn't see the drive.
Source: https://groups.google.com/forum/m/#!msg/qubes-users/-9qRHSkwfy8/CCx08nnTVEAJ and I've verified this works on the Dell XPS 15 i9.

The booting problem will not be fixed by copying/renaming files in /boot/efi/EFI/ as described on the Qubes UEFI troubleshooting guide. I haven't found a fix yet, but if I figure it out, I'll post back here since this is the third hit when searching for "qubes installer uefi boot black screen" and anyone with a laptop that has that problem will probably run into this problem as well.

[anon8675309]

It's always fun to run into a problem that you ran into 6 months ago and think "didn't I have around this issue a while ago and put notes somewhere?" and then find your post on the qubes issue tracker.

I ran into this exact same issue with Qubes 4.0.3rc1 on a desktop with a Gigabyte GeForce GT 1030 GV-N1030SL-2GL (it's fanless, which is an important feature for me). The network install did work and the computer booted into the newly installed O/S (unlike the aforementioned Dell XPS, which seems to have UEFI bugs that prevent booting).

Sadly, it failed shortly after entering my LUKS password. Digging into the xorg logs shows that it is because it attempted and failed to load the "nv" driver, followed by a failure to open /dev/fb0 (no such filter or directory), and ending with "Screen(s) found, but none have a usable configuration" error. Another Fedora/nVidia problem (the card works fine out of the box with the Ubuntu installer, confirming it is not a general Linux problem but rather Fedora specific).

Purely as a test, I then swapped in a different video card: AMD Radeon HD 6950. Got a black screen, so I figured I'd try a reinstall. Installer GUI came up without any problems (no text mode/VNC workaround). After install, it booted, displayed the initial setup page, and everything worked fine.

If I am able to find some way to get basic VESA support for the nVidia card so it'll boot far enough to get to the point where proprietary drivers can be installed, I'll document it here for the people of the future (which may well include "future me").

[anon8675309]

I put forth a noble effort to get an nVidia driver on dom0. There wasn't anything open source in the repos (as evidenced by looking through the list from sudo dnf list xorg-x11-drv-*), and I spent hours trying to get the close-source driver working before giving up.

I attempted to update the documentation on installing the proprietary nvidia driver, but since I didn't finish, I'm hesitant to submit a pull request. Replacing wrong documentation with less wrong documentation seems like progress...
https://github.com/anon8675309/qubes-doc/blob/update_nvidia_driver_docs/external/troubleshooting/install-nvidia-driver.md

Hey, average user hopping to Qubes from arch here. I just wanted to point out that I'm experiencing the same issue on my desktop (Ryzen 7 2700X, AMD Vega 64 for (unofficial) gpu passthrough, Radeon HD 4670 for dom0). I set my BIOS to only allow UEFI and use my inferior Radeon GPU on a PCIE 3.0x4 slot for initial monitor output. If I enable CSM to support legacy boot on a UEFI system and select the legacy boot option from my usb stick for installation everything works (apart from the installation window being slightly too large with buttons partly off-screen). However, UEFI boot results in a black screen after the initial white-on-black terminal output. I'm genuinely interested in this concept of isolation-by-default (and by design), but this is preventing me from having a good user experience. I hope this will get fixed soon, thanks for your investigation!

It seems like the workaround in #5383 fixed the issue for me (#5383 (comment)).