DDG search drop in powered by ddg.patdryburgh.com
+
tl;dr - I bought a System76 Oryx Pro to cut down on the number of computers I own. Initially the cooling system was broken but System76 support was fantastic; repaired it and sent it back post-haste. System76’s commitment to F/OSS, use of Rust and the ever-heroic work of Arch Linux contributors, along with my extensive history of making mistakes made it a relatively pain-free to install Arch with proper hardware support.
Recently I’ve been looking for ways to own less things. It’s harder to get rid of things you feel are a part of yourself but those are often the most rewarding. One of the biggest (literally) things I own is my desktop, an old i7 3770K, in the smallest case I could find at the time, the EVGA Hadron. At that point in time I must not have known about DAN cases (or they didn’t exist yet?). As for graphics I purchased a Radeon R7 360 – not top of the line at the time, but a solid mid-range card IIRC. In addition to the desktop I have a laptop, and it’s been a goal of mine to only have one computer for everything. There were two major contenders for my one computer to rule them all:
The X1 Extreme is a pretty good looking machine, and while I was trying to decide, the 2nd generation of the X1 Extreme actually came out and made an already hard decision even harder. While it was somewhat difficult to find reviews for the two laptops (both individually and finding a review that compared them against each other), there were some good videos out there:
In the end I chose to go with the Oryx Pro because I want to support Linux-first companies like System76. There were a few major differences that stuck out in favor of the Oryx Pro:
The X1 is certainly the sexier machine, and ThinkPads are known for good build quality and sturdy parts – it was a hard choice but I do love me an underdog story, and System76 is that. There’s been lots of discussion and people disparaging System76 for not making their own laptops completely from scratch, choosing to re-brand Clevo hardware and provide software drivers, and the OS instead of the whole package. I personally would much rather the company produce and sell linux laptops today rather than spend 5 years trying to design & bring to market a new laptop and probably failing somewhere along the way.
(section) tl;dr - Awesome packaging and setup UX, overheating issues spoiled the fun temporarily. System76 support was professional and more than made up for any initial inconvenience.
So I bought the Laptop – The packaging was wonderful and very minimal (also emphasis on the packaging being reusable is amazing). Unfortunately I had to reuse this wonderful packaging immediately because the laptop was experiencing an overheating problem due to a faulty fan/cooling unit – basically the fan didn’t seem to be turning on, and the computer was overheating within ~5 minutes of booting.
I worried that I’d done something wrong while going through the very convenient/well designed PopOS set up process (I mean there wasn’t even anywhere to make a mistake really), since the computer seemed to lock up and shut down no matter what I did. After a bunch of debugging (turns out you can just open up a terminal and start exploring), I realized that the computer was overheating after viewing some kernel logs and other things. After getting into contact with System76 and showing them the results (pictures of the laptop screen, install logs, kernel warnings), they agreed and took the machine back under warranty to replace the part (there was also an option to have me replace the part but I opted out of that since I was about to travel). System76 support is pretty famous for being good and that reputation is untarnished in my case, they were helpful and competent and got my laptop fixed and mailed back to me.
(section) tl;dr - I chose Arch linux instead of PopOS or the maddest option; installing Guix SD (which I still want to do in the future).
So here’s where we start to go off the rails – what I originally wanted to do with this laptop is actually run System76’s PopOS (to minimize the chance of issues/incompatibility), and start building a Guix SD VM that would lead to a full Guix SD bootable system that I could switch to. I was a bit chafed at the thought of leaving the wonderful world of Arch and going to such a purpose-built distro (nothing against System76, I haven’t seen any wrongdoing on their part), so my eyes started to wander and I considered Ubuntu 18.04 (which was a no-extra-cost purchase option).
Ubuntu is a really impressive distribution way and deserves it’s place as the go-to consumer linux distribution, but I think of myself as a little more saavy and want the extra power/customizability even if I have to spend some more time reading the amazing Arch Wiki. That said, somewhere deep down I probably just want to be able to hold the fact that I “run Arch” over everyone else. I’ve grown to love Arch over the years and I really want to pacman instead of apt-get, and participate in r/archlinux or help update the wiki. Arch has a wealth of knowledge and knowledgeable community that I love. I will admit that the perceived difficulty of running Arch does act as a bit of a bulwark to keep out newer users/collaborators and that’s a double edged sword – as a bit of a newbie myself I immensely appreciate all the work that goes into the Arch Wiki – it’s saved me so many times and has taught me a lot.
The following will be a few vaguely chornographical notes that I took while setting up Arch on the Oryx Pro that might help others – the real meat of this post.
(section) tl;dr - Follow the Arch installation guide as usual. Don’t forget to install dialog and wifi-menu (which is a part of wpa_supplicant IIRC) during the arch-chroot phase.
Going through the Arch Installation Guide for a refresher on the OS install was enough to get me through the installation after burning a Arch LiveUSB (using good ol’ dd). A few things that were different or that I did differently while getting Arch set up:
arch-chroot period: dialog, wifi-menu, nvidia, yay, system76-driver (system76-driver wasn’t actually properly installed but I fixed that later, you might want to skip this)The Arch install went as usual so I did the usual stuff (creating the wheel group, creating my own user account, permissions, etc), and then did a bit more set up:
borg backup from an external drive onto the hard-drivesystem76-driver from the AUR and other drivers (There’s even a page on the Oryx Pro in the Arch Wiki!)After getting all this set up, I was more or less left to my own devices as getting the rest of my own environment (so restoring backups/setting up the actual computer) went.
(section) tl;dr - Installing Xorg, also XFCE4 has a bunch of tools I use. Double checked my installation of system76-* packages, and re-generated the kernel with the modules as a requirement via mkinitcpio.
I installed quite a bit of software but here are some of the major ones for me:
xorg-server (copying ~/.xinitrc from backup)bspwmpolybarxfce4-terminalthunarxfce4-appfinderOriginally when trying to start the Xorg server I ran into a DRM set master permission denied error. It turned out that I needed to enable kernel modesetting for Xorg, so I added both i915 (for the intel gfx driver) and all the relevant nvidia-related modules to my /etc/mkinitcpio.conf, running mkinitcpio to test it out (when you’re ready to actually generate the initial ramdisk, run sudo mkinitcpio -p linux).
While I was mucking with /etc/mkinitcpio.conf I realized that I didn’t actually include the system76 kernel module in the MODULLES section! After System76 packages are installed the /etc/modules-load.d folder is populated with files like system76.conf and system76-io.conf to force the loading of the kernel modules, but I put system76 in /etc/mkinitcpio.conf just in case (note that if the kernel module is not installed, mkinitcpio will tell you). This is actually how I realized originally that the kernel module wasn’t installed properly.
Once I realized that system76-driver wasn’t installed properly it took me on a bit of a chase – I had not properly installed system76-dkms and that wasn’t properly installed because I didn’t install linux-headers. After I straightened this out, I was able to install system76-* (dkms, io-dkms, power) packages from the AUR, and no missing modules when I run mkinitcpio (and resultingly sudo mkinitcpio -p linux) and restart the machine.
(section) tl;dr - It didn’t work, the values are read-only, and going all-manual w/ pwmconfig and fancontrol is almost certainly not a good idea.
After getitng all the system drivers properly installed, I started looking around at how I could get some of that information – most importantly what the hardware sensor data. A short look around the internet and the Arch Wiki guide on lm_sensors got me mostly up to speed. I didn’t have to deal with lm_sensors much on my last Laptop (it was fanless), but getting familiar with acpi and sensors was very useful (output is so nice and tidy!). Now I can worry a little bit less about the computer overheating.
I noticed my computer running @ around 50-70C during normal operation and while doing some compute intensive operations. Since the computer idles around 45C and polybar is configured to show temperatures over 60ish as red, I was wondering if I could do something to make the fans kick on earlier and keep the processor in a lower temp range, even at the cost of a bit of noise pollution (the Oryx Pro’s fans sound like a jet when they really get going) .
Looking at the output of sensors:
iwlwifi-virtual-0
Adapter: Virtual device
temp1: +44.0°C
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +70.0°C (high = +100.0°C, crit = +100.0°C)
Core 0: +67.0°C (high = +100.0°C, crit = +100.0°C)
Core 1: +65.0°C (high = +100.0°C, crit = +100.0°C)
Core 2: +65.0°C (high = +100.0°C, crit = +100.0°C)
Core 3: +66.0°C (high = +100.0°C, crit = +100.0°C)
Core 4: +70.0°C (high = +100.0°C, crit = +100.0°C)
Core 5: +62.0°C (high = +100.0°C, crit = +100.0°C)
acpitz-acpi-0
Adapter: ACPI interface
temp1: +88.0°C (crit = +120.0°C)
BAT0-acpi-0
Adapter: ACPI interface
in0: +16.88 V
curr1: +0.00 A
pch_cannonlake-virtual-0
Adapter: Virtual device
temp1: +72.0°C
system76-isa-0000
Adapter: ISA adapter
CPU fan: 2197 RPM
GPU fan: 2341 RPM
CPU temperature: +88.0°C
GPU temperature: +0.0°C
So if you’ll notice there, high is set to 100C, and crit is set to 100C as well. This should not be the case, and I’d much rather have high set to something like 75C. After some light searching I found an arch wiki entry on lm_sensors that cleared up how to override this configuration. Unfortunately, the values there are actually hard-coded into the processor, and the only things I could change seemingly via /etc/sensors.d configuration files were compute (which changes offsets for the measurements themselves) – what I wanted to change was the high mark.
After some more searching I thought maybe I needed to use tools like [sensors-detect][sensors-detect] (which I ran, it took a very long time) pwmconfig to generate fancontrol configuration, so I started looking into it, but the warning from pwmconfig stopped me dead in my tracks:
$ sudo pwmconfig
# pwmconfig revision $Revision$ ($Date$)
This program will search your sensors for pulse width modulation (pwm)
controls, and test each one to see if it controls a fan on
your motherboard. Note that many motherboards do not have pwm
circuitry installed, even if your sensor chip supports pwm.
We will attempt to briefly stop each fan using the pwm controls.
The program will attempt to restore each fan to full speed
after testing. However, it is ** very important ** that you
physically verify that the fans have been to full speed
after the program has completed.
Found the following devices:
hwmon0 is acpitz
hwmon1 is system76
hwmon2 is AC
hwmon3 is pch_cannonlake
hwmon4 is coretemp
hwmon5 is BAT0
hwmon6 is iwlwifi
Found the following PWM controls:
hwmon1/pwm1 current value: 63
hwmon1/pwm1 is currently setup for automatic speed control.
In general, automatic mode is preferred over manual mode, as
it is more efficient and it reacts faster. Are you sure that
you want to setup this output for manual control? (n)
Since I haven’t actually had a problem with the manual control (the computer will beep and shut itself down if temps go into the dangerzone), I was content to leave it in automatic speed control. So in the end I didn’t change the configuration for the high mark, because it’s actually hardcoded into the processor and moving to fullly manual control doesn’t seem neccessary (or a good idea) just yet. After running the computer through it’s paces I was satisfied with how quickly and strongly the fan came on when necessary, even though the temps were allowed to get higher than I would have liked (80/90C).
dhcpcd for automatic network-provided host configuration(section) tl;dr - Use dhcpcd, start & enable it with Systemd.
One of the reasons I chose the Oryx Pro was the fact that it had an on-board ethernet cable adapter – since it’s going to spend most of it’s life relatively stationary on my desk, I’ve got it directly connected to the router. With this direct connection though, your computer needs to get itself an IP using the Dynamic Host Configuration Protocol (AKA DHCP). A quick run through the excellent (as always) Arch Wiki Network Configuration guide should provide you all you need to know about setting up DHCP for your network configuration.
Originally I was running dhclient manually to perform the host configuration, and of course that’s a pretty silly think to do every time you restart your computer. The next step was to try automating it and while there are a few options, the arguable best choice is to use Systemd’s Units as outlined by the guide. Let’s first find out the name of our network device:
$ ip link # find your link interface the link interface
1: lo: .... information about the lo (AKA loopback) link
... more output ...
2: enp8s0: ... information about the ethernet link
... more output ...
3: wlp0s20f3: ... information about the wifi link
... more output ...
So the interface we want there is enp8s0 – It’s a pretty whacky name (in most guides you’ll find names like eth0), but check out the thread on SO that explains this. I’ll reproduce a bit of the answer here for posterity (thanks to SO user Braiam):
That’s a change in how now udevd assigns names to ethernet devices. Now your devices use the “Predictable Interface Names”, which are based on (and quoting the sources):
Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
Names incorporating the interfaces’s MAC address (example: enx78e7d1ea46da)
Classic, unpredictable kernel-native ethX naming (example: eth0)
Now that we know the network device name (enp8s0), let’s run dhclient by starting the Systemd unit that’s been made available to us:
$ systemctl start dhclient@enp8s0.service
We’ll also enable the service so that it starts automatically with systemctl enable:
$ systemctl enable dhclient@enp8s0.service
Unfortunately this didn’t work well for me – start worked, but upon restarts, the dhclient@enps8s0 unit would error, noting that the device was not found. Upon restarting the unit everything would be fine – it looks like the unit was attempting to start before the network was done initializing. Rather than try to override configurations (assuming my guess at what is wrong is even correct), I just went with using DHCP-C-D instead – the DHCP Client Daemon. Note this is different from dhcpd which is a DHCP Daemon – your router is what’s performing the dynamic host configuration – your computer is acting as a client in the process, but the client must be daemonized so you can can go about your day and refresh/retrieve host configuration as necessary. Arch’s page on dhcpcd has fantastic information about the process and how to get it set up.
Disabling dhclient and setting up dhcpcd was easy:
$ sudo pacman -S dhcpcd # install dhcpcd
$ systemctl stop dhclient@enp8s0.service # stop dhclient if it's running
$ systemctl disable dhclient@enp8s0.service # stop dhclient from starting automatically
$ systemctl start dhcpd.service # start dhcpcd (by default for all interfaces)
$ systemctl enable dhcpd.service # ensure dhcpcd starts automatically
Also use dhcpcd (spelling is important), instead of dhclient – I had problems with dhclient trying to start too early and not actually finding the interface. I could add some overrides for the dhclient@starting and enableing (mabye a target later in the sequence? Requires=Network?), but dhcpcd just works.
Right now I’ve only run into one thing that has been an issue (that I haven’t tried to solve) – hibernation does not work out of the box. Suspend (so the screen turns off, but the machine is still on) does work, but hibernation (attempting to save state and turn off the machine completely) does not. I really haven’t looked into why it’s not working at all, but with how I use my computer it’s not really much of an issue at present, I suspect I might have cause to figure it out later.
I’ve been thoroughly enjoying my Oryx Pro, and hope others will to. It’s working nicely for me (this post was written on it) as my daily driver, and I’m glad it was so easy to venture a little ways off the beaten path and put Arch on it.
As I’ve said before – all this is possible thanks to the tireless work of Arch Linux contributors (maintainance, documentation, etc), and the hard work and commitment to open source software of people at System76. Long live the linux laptop!
If you’re on the fence about purchasing a System76 because you’re worried it might not support your favorite linux distribution (Arch) – rest assured, it definitely works and works well.