Installing Fedora on System76


This is about what I went through to install Fedora 27 (XFCE spin) onto my Gazelle system76 laptop. For those not aware, system76 provides hardware that ships with Linux (Ubuntu) instead of Windows; which actually results, depending on what you order, a system just as powerful as the usual suspects (Dell, HP, etc.) but $200-$500 cheaper because you don’t have to pay for Micro$oft Windows (yes, you are still paying for Windows when you buy from those others).


So, as I mentioned earlier, system76 systems (that sounds redundant) comes with Ubuntu. For me, that lasted all of 30 minutes before I replaced it with something else. That wasn’t an easy task. With the newer Skylake processors, kernel 4.x is needed. That left distros like CentOS out the question with its 3.10 kernel; oh, it would some how install completely, but on reboot it would croak. Plus, that Gnome2 UI (think it’s Gnome3 now, but still the 3.10 kernel) just wasn’t for me. Native Debian behaved similarly. So I jumped between various other distros, such as Mint (which I view as Ubuntu with a green color scheme), wattOS (which uses LXDE, a session-managed Openbox, but still based off of Ubuntu). SparkyLinux, another LXDE distro based of the “testing” branch of Debian, wasn’t too bad. There were some others in there as well. The last one, before attempting Fedora, was system76‘s Pop!_OS. Pop!_OS uses a somewhat customized Gnome3 desktop and Ubuntu repositories. I’ve never been a fan of Gnome3. Maybe because I’m used to DEs like XFCE and Openbox where you can right-click on your desktop and get the applications menu right there, as well as being severely limited in customizing; things as simple as date/time formatting, had to find an extension for that. I did “try” to use Gnome3 for a while, but I could never get used to it. So, this is how I got to Fedora.

About Fedora

Fedora is basically a bleeding-edge distro based off RedHat (actually owned by RedHat).


The initial installation didn’t go to well. I got through everything until the end, when it attempted to write the boot loader, which it failed. Having installed countless distros of Linux, I can’t say that I’ve run into that all to often; OpenSuSe may be the one other distro that had that issue. Through some digging around the ‘Net, I found that the reason may be that the BIOS wasn’t set to UEFI. I normally don’t set my BIOS to UEFI and don’t recall on this system whether or not it was set to that or not. So, I set my BIOS to UEFI and the installation, after creating the requisite /boot/efi partition, worked flawlessly. One of the faster installs, to be honest.

Initial Boot & Login

The initial boot went fine until I tried logging in as a non-root user (who really logs into a system as root anyway?). The screen would flicker and then take me back to the login screen; as root I could log in fine. So I went to the console level, logged in with the non-root account and executed startx. As soon as XFCE came up, SELinux started giving all sorts of messaging about access my $HOME, reading $HOME/.cache, reading some other directory in $HOME, etc.


I read/followed how to set up a policy to be OK with that, etc., but after about the fifth one, I went to find how to disabled SELinux, or, at the very least, dial it down. Initially, instead of flat out disabling in /etc/selinux/config, per recommendation from various readings, I set it to permissive. This resulted in not being able to boot at all. That’s not entirely true, it would boot, but a lot of the services would fail to start. This resulted in me having to boot into single-user mode and set SELINUX=disabled in /etc/selinux/config. This worked like a champ and booted up in record time and allowed me to log in. SELinux has been around for a while and while it has it’s purpose, I don’t know that it’s necessary for a home system. I suspect why SELinux was so upset about my $HOME was because it wasn’t encrypted. To me, it’s just a bit overkill.


After working through the above, everything worked as I expected. In the past I used Fedora almost exclusively, right around the time RedHat turned into the Micro$oft of the Linux world and RedHat was no longer free. After a while I started using variations of Debian, with some dabbling with Slackware and OpenBSD (and FreeBSD) of which requires a lot of hand-holding, patience, time and good code compilation error troubleshooting skill. I’ll have to get used to using DNF (Dandified yum, next-gen fork of yum) again versus Debian’s APT. Syntactically, they’re close and I’m not exactly new to using dnf.

That’s it. That was my, not so problematic experience installing Fedora on my system76 device.

And that’s all I have to say about that.

Monitor Hot-plug Script


I recently installed Pop!_OS from system76 (maker of my laptop) which happens to use a customized implementation of the Unity desktop. I’ve never been a fan of Ubuntu and certainly never cared for the Unity desktop. But I figured I would give it a try for a period of time before switching to something that is, in my opinion, more user-friendly and configurable (such as XFCE, Openbox, etc.). This isn’t about my opinion of Ubuntu, Unity or all efforts in Linux that go out of their way to mimic Microsoft Windows and Apple.

While it is a laptop that I use, I do, for the most part have an external monitor connected to it via an A/B switch for my work laptop and my personal one. One the functionalities lacking in Gnome3 (as well as other desktop environments) in general is the detection of when an external monitor is connected. Sure, you could use something like arandr the will generate a script for you and you can map it to a keyboard shortcut (binding), but that requires some manual effort that, frankly, shouldn’t be necessary. So, what I did was create a utility (chreli-monitor-hotplug) that simulates detecting when an external monitor is connected or disconnected, leveraging xrandr. The script is written in Perl and loops continuously (sleeping for 5 seconds) parsing the output of xrandr to see what’s connected, primary, etc. It’s not elegant, as I’m sure there are other like scripts or applications out there that can do the same thing better, but this gets the job done (for me any way).


The following are required for chreli-monitor-hotplug:

  • x11-xserver-utils (needed for xrandr)
  • perl


To install, download chreli-monitor-hotplug-1.0.20171103.deb and execute the following command:

Disclaimer: This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

sudo /usr/bin/dpkg -i chreli-monitor-hotplug-1.0.20171103.deb


Using GNOME Tweaks, navigate to Startup Applications, click the + and in dialog, search for ChrEli.

Select ChrEli Monitor Hotplug and click the Add button.

Alternatively, you could just copy /usr/share/applications/chreli-monitor-hotplug.desktop to ~/.config/autostart.

The above will result in chreli-monitor-hotplug auto-starting on next restart (or re-login).


Upon initial execution of chreli-monitor-hotplug, it will create and set defaults in ~/.config/chreli-monitor-hotplug/chreli-monitor-hotplug:

# chreli-monitor-hotplug 1.0.20171104
# configuration file for chreli-monitor-hotplug

# debug
# default: 0

# interval (in seconds) to check monitor changes
# default: 5

# dual
#  o flag to use both connected monitors
# default: 0

# external.primary
#  o flag to make external primary monitor
# default: 1


That’s it. Nothing complex, but gets the job done and meets my needs (at least on my system). Given that every system and distro is different in how they behave, name devices, etc., chreli-monitor-hotplug may not work out-of-the-box on all system, but should for most.

And that’s all I have to say about that.