In my third article in this series, I’m going to talk a bit about the failure case I hit after installing Fedora 29 on my laptop, and how I was able to get to a command line to fix it. You can read the story up to this point in this article.

To sum up though, I have a Dell Inspiron laptop, with a discrete nvidia video adapter. Fedora’s Nouveau driver does not handle this card well, and I always have video issues right after install, and sometimes after upgrades. Many suggest the use of Bumblebee to get around this, you can do that if you’d like. I’ve never had any luck there. So I just use the proprietary NVIDIA drivers found in RPMFusion. I’ll talk about that more in the next article.

The Problem…

The issue is simple. After a fresh install of Fedora 29, my laptop wont boot. This is because the Nouveau driver just doesn’t get along with my discrete video adapter. An NVIDIA 960M. First boot looked something like this:

That looks fine, until I mention that it’s hung there, for eternity. Power-off is the only way to recover. Can’t even hit ESC to get the console output. Locked up good. If you hit ESC before it gets locked up, you’ll see the following errors:

Troubleshooting

I was pretty sure I knew that this was the video card, but I did do quite a bit of digging to see what that particular error meant, I came up mostly empty. I got a few good nudges from the Red Hat Accelerators, a group of linux nuts (and Red Hat customers) that I’m a member of. I decided to attack it as the problem I suspected it was, the nouveau problem that I usually have. See, I can clearly remember support for my card getting improved in Nouveau at some point during my previous install of Fedora, so I was a little surprised when this happened. I should have known better than to trust my memory.

I started with the usual, interrupt your GRUB boot loader (I usually just hit the up/down arrows during boot until I see the GRUB screen), and edit the Fedora 29 default boot line by selecting it (first in the list) and hitting ‘e’. Then find the line that loads the kernel, it looks like this.

First, let’s disable plymouth for this boot, just remove the two arguments “rhgb” and “quiet”. Then add the infamous line, ‘nomodeset’. This is suposed to disable noveau, from what I’ve read. The nouveau docs actually don’t mention it. I also don’t see it in the kernel docs.. Maybe it’s outdated info? At any rate, I added nomodeset, and nouveau.modeset=0, which IS documented, it disables nouveau. The thing I don’t understand is how that helps? Is X supposed to fall back to some failsafe video driver? Not sure, the internet suggests this, I tried it. It actually didn’t help. I ended up adding “nomodeset nouveau.modeset=0” to the “linux” line in place of the “rhgb quiet” that I removed. That helped, but I still ended up with a system that tried to load X at boot time, and failed. However, it didn’t lock up. So this is progress.

I used a virtual console, ctrl-alt-f2, to get to a command line, and I set my default boot target to “multiuser” instead of “graphical. This is done by changing a symlink in /etc/systemd/system. Change default.target to link to multiuser.target. Here’s what it looks like:

[gangrif@meliodas system]$ pwd
/etc/systemd/system
[gangrif@meliodas system]$ ls -l default.target
lrwxrwxrwx. 1 root root 36 Dec 22 09:52 default.target -> /lib/systemd/system/graphical.target
[gangrif@meliodas system]$ 

There are lots of other targets you can link, but the one you want to multi-user.target

[gangrif@meliodas system]$ ls -l /lib/systemd/system/multi-user.target
-rw-r--r--. 1 root root 532 Oct 28 20:29 /lib/systemd/system/multi-user.target
[gangrif@meliodas system]$ sudo rm ./default.target; sudo ln -s /lib/systemd/system/multi-user.target ./default.target
[sudo] password for gangrif: 
[gangrif@meliodas system]$ ls -l default.target 
lrwxrwxrwx. 1 root root 37 Jan  5 13:03 default.target -> /lib/systemd/system/multi-user.target

Now, at your next reboot, you’ll get right to a login prompt rather than the GDM graphical login. This is where that user we added during the liveusb setup comes in handy. Once I did that, I rebooted, and used the same kernel arg swapping in grub to get to a text login. Logged in with my user, and then tried to startx, which should give me better output than gdm does. It also fails back to the command line rather than a broken gdm login!

Getting X to start…

X still wont start, as I expected. If it started right up I’d be surprised, since it failed at boot. So now we get to troubleshoot in a more sane manner.

The framebuffer thing threw me off. I went back to the accelerators, and it was suggested that I add one more kernel arg. i915.modeset=0. Which should do the same thing that nouveau.modeset=0 does, except for the integrated Intel card. So I added that. Making my final kernel command like something like:

Remove:

rhgb quiet

And in their place, add:

nomodeset nouveau.modeset=0 i915.modeset=0

That did it! I was able to boot up, and try to start X, and then the framebuffer error was gone. Unfortunately I forgot to get a screenshot/picture of it. X still wouldnt start, but that’s because I hadn’t yet installed any NVIDIA drivers. Installing the proprietary NVIDIA drivers on Fedora 29