I set the feature image for this piece to one of my holding my SystemRescueCD. When it comes to Fedora “you gonna need it a lot!“
While I will say Fedora has gotten oceans better since I last touched it, I must honestly say it is still horrible. Basically they put a desktop front end on a locked down server version of Linux and didn’t actually finish the “front end” part. It is still really expert friendly if you want to actually use it.
I installed Fedora because of Pt. 10 of my CopperSpice series and I wasted most of a day trying to get Ubuntu 16 current repository stuff working with CopperSpice. That was even less successful than OpenSuSE. If you are establishing protocols for a regulated environment, you aren’t going to get CopperSpice to build with what is currently in the repos when it comes to Ubuntu 16. As everybody who has ever worked in the tightly controlled regulated environments knows, you can’t just go find something willy-nilly and install it. There is a formal vetting process. If you “just download and install it” no matter what “it” is or where it comes from, without getting it from the formally vetted repos, you are probably getting terminated and depending on what environment, possibly going to prison.
Let me be honest and up front here.
I don’t know how anyone could “like” Fedora let alone love it. The thing really comes up short.
My experimental project machines are also my BOINC machines. When I’m not installing something new on them for an experiment they sit on a bench running BOINC looking for cures to COVID-19, Cancer, HIV, etc. Most of my BOINC machines have NVidia GeForce 630 based video cards in them because those GPUs tend to rule number crunching, at least on the projects I support.
At some point I will publish Pt 11 and you can follow along to create your own issues. I did successfully build CopperSpice and Diamond. At some point I was going to try creating an RPM and possibly a container for Diamond. Since CopperSpice wouldn’t build on OpenSuSE, Fedora was the next least offensive platform.
There was a case of really bad timing here too. I had just finished building and testing Diamond. I decided I would just copy the screenshots and text files up to one of my NAS devices rather than walk the six feet over to another desk for a thumb drive. Low and behold I could see only WD MyCloud. The Buffalo didn’t show up in the file manager. I could open MyCloud, but it crashed when I tried to open my directory.
“Oh! They have this problem!” I said to myself.
I dutifully edited the file and rebooted. Login screen came up, I clicked my name, entered my password, and was greeted by a black screen with a flashing underline cursor in the upper left corner. Hitting return didn’t move it. You could type nothing. WTF?
Okay, it was the last thing I did and it does play a bit of a role during boot, maybe I fat fingered that? I tried every trick to log in as a terminal user.
“unable to get valid context for roland”
Mount an lvm under SystemRescueCD
Booting my SystemRescueCD I then had to figure out how to mount a Fedora partition. In the terminal window
root@sysresccd /root % lvm vgscan -v Wiping cache of LVM-capable devices Wiping internal VG cache Reading all physical volumes. This may take a while... Found volume group "fedora_localhost-live" using metadata type lvm2 root@sysresccd /root % vgchange -a y volume "fedora_localhost-live" 3 logical volume(s) in volume group "fedora_localhost-live" now active root@sysresccd /root % lvm lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert home fedora_localhost-live -wi-a----- 154.04g root fedora_localhost-live -wi-a----- 70.00g swap fedora_localhost-live -wi-a----- 7.85g root@sysresccd /root % mkdir /media/fedora_root root@sysresccd /root % mount /dev/"fedora_localhost-live"/root /media/fedora_root root@sysresccd /root % fsarchiver probe simple [======DISK======] [=============NAME==============] [====SIZE====] [MAJ] [MIN] [sda ] [Samsung SSD 840 ] [ 232.89 GB] [ 8] [ 0] [sdb ] [DataTraveler 2.0 ] [ 7.27 GB] [ 8] [ 16] [sr0 ] [DVDRAM GH24NSC0 ] [ 545.51 MB] [ 11] [ 0] [=====DEVICE=====] [==FILESYS==] [======LABEL======] [====SIZE====] [MAJ] [MIN] [loop0 ] [squashfs ] [<unknown> ] [ 469.86 MB] [ 7] [ 0] [sda1 ] [ext4 ] [<unknown> ] [ 1.00 GB] [ 8] [ 1] [sda2 ] [LVM2_member] [<unknown> ] [ 231.88 GB] [ 8] [ 2] [sdb1 ] [vfat ] [RED ] [ 7.27 GB] [ 8] [ 17] [dm-0 ] [swap ] [<unknown> ] [ 7.85 GB]  [ 0] [dm-1 ] [ext4 ] [<unknown> ] [ 154.04 GB]  [ 1] [dm-2 ] [ext4 ] [<unknown> ] [ 70.00 GB]  [ 2] root@sysresccd /root % mkdir /media/myusb root@sysresccd /root % mount /dev/sdb1 /media/myusb
I also mounted a thumb drive with the label “RED” (because it happens to be colored red and I wasn’t feeling creative the last time I initialized it). I wanted some place to write stuff that would survive and be accessible. What good would be writing all of the information about how to mount a Fedora lvm under SystemRescueCD on the drive I needed to know how to mount? The thumb drive I could at least stick in some other machine to look at.
Now I had to navigate to /media/fedora_root and undo what I had done. Being the glutton for punishment that I am I tried commenting it out first. One can never have enough practice booting SystemRescueCD after all.
It took a few reboots to realize this had nothing to do with what I did. Well, not this particular change anyway. One of the main reasons Fedora and its ilk are so ill-suited for desktop use is they tried to completely lock down the desktop without providing a complete desktop.
This Black Screen of Death is Really Common
In a YABU distro you install an NVidia driver via the “additional drivers” or “ubuntu-drivers” methods and you forget about it. Updates continually do whatever it is they need to do. Life goes on.
Not so with Fedora.
Most “advice” is to install the NVidia drivers via RPM Fusion. There is even Fedora doc about RPM Fusion. Okay, this should be properly packaged, right? I installed it, did battle with getting Boinc working (not a simple feat on Fedora!) and continued on with building CopperSpice. Things were smooth. Diamond built and ran.
I was having a good day. Just needed to copy all of this stuff up to the NAS. To do that I needed to reboot.
What happened to me and many many others is the realization that any hiccup, like falling back to a default video driver, is grounds for throwing up the black screen under Fedora. Make a change to your .bash_profile and you are probably going to get a black screen. During all of my installing stuff to make CopperSpice build, a kernel update got installed. It wouldn’t run until the next boot which was a few days later. The updates from Fedora don’t bother to rebuild the NVidia drivers provided by RPM Fusion. Niiiiice.
Unscrewing yourself from this major hosing requires quite a bit of near expert skill or you can just read the rest of this post and find out where the cheese is hidden. <Grin>
- Boot your SystemRescueCD
- Mount your Fedora root partition as I showed you earlier
- cd to your Fedora root then to etc/selinux
- nano config
I certainly wouldn’t leave it disabled forever, but you need it this way for at least a few more boots. Save and reboot.
You should be able to log in now.
If you don’t already have it, install dnfdragora and use it to find the proper names for nvidia things and rpmfusion. I chose to remove these from the command line.
[roland@localhost-live ~]$ sudo dnf remove akmod-nvidia [sudo] password for roland: Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: akmod-nvidia x86_64 3:450.66-1.fc32 @rpmfusion-nonfree-updates 22 k Removing unused dependencies: akmods noarch 0.5.6-25.fc32 @fedora 37 k elfutils-libelf-devel x86_64 0.181-1.fc32 @updates 34 k guile22 x86_64 2.2.6-4.fc32 @fedora 44 M kernel-devel x86_64 5.8.9-200.fc32 @updates 52 M kmodtool noarch 1-38.fc32 @fedora 18 k make x86_64 1:4.2.1-16.fc32 @fedora 1.4 M xorg-x11-drv-nvidia-kmodsrc x86_64 3:450.66-2.fc32 @rpmfusion-nonfree-updates 11 M Transaction Summary ================================================================================ Remove 8 Packages Freed space: 108 M Is this ok [y/N]: sudo dnf remove rpmfusion-free-release rpmfusion-nonfree-release
You will note it also removed kernel-devel and make. Those will play a role later on.
Now comes the expert-friendly part of the journey
Much of this information was thieved from this post. I’m just kind of documenting my journey for you. If that site goes down then I guess this will help some people.
Open a terminal.
lspci |grep -E "VGA|3D"
This will tell you what kind of chipset you have or I guess nothing. It told me what I already knew, GeForce 630. Now we have to find the NVidia driver and we do that by visiting the NVidia site. I downloaded the August 18 version of 450 because I wanted to shy away from beta versions and supposedly 450 is what I needed. Once the download is done, open a terminal.
cd Downloads chmod +x NVIDIA-Linux-x86_64-450.66.run sudo dnf update
Now you need to reboot. After reboot open another terminal.
sudo dnf install kernel-devel kernel-headers gcc make dkms acpid libglvnd-glx libglvnd-opengl libglvnd-devel pkgconfig sudo -i echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf nano /etc/sysconfig/grub
Please note this is the grub file in /etc/sysconfig. You need to add rd.driver.blacklist=nouveau on the CMDLINE, save, then exit.
First command below is for BIOS and second is for UEFI. I updated both because my system allows choosing between the two when you hit the boot menu function key at the proper time during power up.
grub2-mkconfig -o /boot/grub2/grub.cfg grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
I found this step a bit extreme but did it anyway. Physically remove nouveau
dnf remove xorg-x11-drv-nouveau
Backup the old initramfs just in case
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img
Now generate a new one
dracut /boot/initramfs-$(uname -r).img $(uname -r)
Now change to just temrinal support
systemctl set-default multi-user.target
Print out the rest of these instructions because you won’t have a GUI or a Web browser.
Reboot and log in.
sudo -i cd /home/roland/Downloads ./NVI <tab>
Of course your username won’t be roland. This is one of the few times you will find me recommending use of the TAB key to complete a file name.
Right here is where the RPM Fusion crowd screwed the pooch. Had their package done this it would have worked just like the ones you get from Ubuntu based distros. A new kernel comes out and it trips the trigger to force a recompile/link/whatever of the NVidia driver to the kernel.
You basically respond Yes to everything.
You need to edit your /etc/selinux/config file and set SELINUX=permissive. I don’t know why, I suspect something isn’t completely clean with the NVidia drivers or developers at Fedora just like to mess with you once you’ve installed something that had actual revenu and patents behind it. Even after all of this I still get
“unable to get valid context for roland”
The differences are:
- Boinc can now use the GPU
- My screen looks better
- I can actually log in.
You need to enable the graphical system again and reboot.
systemctl set-default graphical.target
If you are using NVidia this should permanently fix your black screen of death due to kernel update squashing the video driver.
I understand the thought behind Fedora. The reality is that programmers have to eat and live indoors. To do that we need to get paid. One way to get paid is have proprietary patented software algorithms. If you really want to get on your high horse, find the dude who patented storing a year in what was previously a 2 character field using binary right in front of Y2K.