Changelog and customization tips for my Arch Linux system, which is running on a Dell Precision 5530 laptop (same machine as the XPS 15 (9570).) If nothing else, it's a record of things I tend to forget.
Obligatory "dirty" screenshot running an even more obligatory MNIST example. Also, I like GNOME. (So sue me.)
Follow the Arch wiki. Basically (1) switch SATA mode from RAID to ACHI, (2) disable secure boot, and (3) change fastboot to "Through" in "Post behaviour". Not sure that this last step is needed. I also enabled legacy BIOS drivers, since my system was having trouble reading the live USB.
You can, of course, build Arch from scratch. But not everyone is a masochist has time for that. I installed my Arch system using the (sadly discontinued) Antergos project. Luckily, there are many more options available. I recommend either:
- EndeavourOS: Picking up where the super Antergos community left off. Comes with all of the benefits of a bleeding-edge Arch setup without the pain. This would be my first choice if I were starting anew.
- Manjaro: Another good option that a lot of people swear by. (Note, this is actually a derivative of Arch with its own repositories, etc.)
- Garuda: This is an opinionated Arch derivative, with an emphasis on workstation performance, for example by using the Zen kernel. Lots of defaults are set up for the user, including btrfs and snapper for automatic snapshot backups.
I think this was an option on the original install media, but I somehow missed it. At any rate, creating this after the fact wasn't too hard. I first created a GParted Live USB (download the ISO image here and flash with Etcher). This was a lot quicker than creating a live USB of an entire distro and I only needed to resize some partitions anyway. From here, there are various guides (e.g. here and here) and I just followed along. FWIW, keeping your home directory on a separate partition is probably safer and also makes distro hopping easier.
My Dell Precision 5530 laptop comes with a hybrid graphics system comprised of two card: 1) an integrated Intel GPU (UHD 630) and 2) an NVIDIA Quadro P2000. After various steps and misteps trying to install the NVIDIA drivers, I finally got everything working thanks to this outstanding guide on the Arch wiki. (Which, in turn, is based on this this community thread.). Some high level remarks:
The NVIDIA GPU and drivers only appear to work well on the Xorg session. Wayland performance is still shaky, or not even supported AFAIK.Scratch that. The GPU is working just fine on the Wayland session. (Admittedly, I'm using it primarily for computation, not gaming.)- The way the setup works is that the discrete NVIDIA GPU is switched off by default when the computer boots up to save battery life, etc.
- To turn it on, I just need to run a simple shell script that I've saved to my home directory.
$ cd ~ ## Just emphasising the location
$ sudo bash enablegpu.sh ## 'sudo bash disablegpu.sh' to turn off. Or, just shut down.
$ nvidia-smi ## Optional: confirm that the NVIDIA card has been enabledTip: To monitor GPU use and performance (a la htop), run $ watch -n 1 nvidia-smi. Or, you can install the gpustat command line utility and ran $ gpustat -i.
With the NVIDIA chip working, it's now fairly straightforward to set up a GPU-enabled deep-learning environment (see here).
PS — As noted above, my working NVIDIA setup only came after various misteps. And the "solution" to these misteps back then was basically just to keep the discrete GPU switched off at all times. Thankfully, the real solution was easy enough thanks to the Arch wiki guide. Still, for posterity and since I learned a lot from working through these steps, the old changelog is under the fold...
Old NVIDIA changelog (click to expand)
I initially tried to get CUDA support going by installing the `nvida` package from the Arch repositories... Which turned out to be a mistake! The system would boot up fine, but I was subsequently presented with a blank screen once I got passed the GRUB menu.Solution: Boot directly into the shell (i.e. TTY) and uninstall the nvidia package: Press "Ctr-Alt-F2" at the grub menu and then hit "e" to edit the selection. Look for the line starting with "linux" and add "3" (without the quotation marks) to the end of that line. F10 to exit and then you will be presented with the shell upon booting up. Enter your username, followed by your password. Finally, uninstall the nvidia package by typing sudo pacman -Rs nvidia and
reboot as normal ("CTR-ALT-DEL").
Update: After some package and system updates, I'm back to the post-login blank screen! Weirdly, starting GDM from TTY1 (see above) works fine, so this is my current workaround. Have left a question on the Antergos forum about this.
Update 2: Added "nouveau.modeset=0" to the kernel boot parameters as per various online suggestions:
$ sudo nano /etc/default/grubAdd "nouveau.modeset=0" to the GRUB_CMDLINE_LINUX_DEFAULT variable. Then CTL+X and "y" to save. Re-generate the grub.cfg file:
$ sudo grub-mkconfig -o /boot/grub/grub.cfgThis solves the log-in and hibernate problem... but only for Xorg. In other words, now my Wayland session(s) have disappeared!
Update 3: Have tried various fixes in the interim, including removing KDE/Plasma entirely in case there were some sytem conflicts with Gnome. I also tried removing the folder ~/.config/gnome-session as per this thread. Didn't work. In fact, it turns out that the issue of GDM not being able to recognize Wayland sessions is common. Here are some relevant threads: 1, 2, 3, 4. Will read through these various threads and try different options.
Update 4: Solved! Thanks to this suggestion, I needed to enable early KMS start. (Basically, my laptop is too fast for its own good.) The full solution then is to disable modesetting for the Nouveau driver (see Update 2 above) and enable early KMS start for the integrated Intel GPU, by adding following Intel modules to /etc/mkinitcpio.conf:
/etc/mkinitcpio.conf
---
MODULES=(intel_agp i915)
Once that's done, regenerate initramfs:
$ sudo mkinitcpio -p linuxReboot and I can now log directly into Gnome Wayland from GDM.
Very easy with rsync. See this video.
Given my external hard drive — which I named "PrecisionBackup", but for some reason is called "PrecisionBackup1" under the /media/ mount point — first do a dry run with:
$ bash ## zsh doesn't work for some reason
$ sudo rsync -aAXv --delete --dry-run --exclude=/dev/* --exclude=/proc/* --exclude=/sys/* --exclude=/tmp/* --exclude=/run/* --exclude=/mnt/* --exclude=/media/* --exclude="swapfile" --exclude="lost+found" --exclude=".cache" --exclude=".VirtualBoxVMs" --exclude=".ecryptfs" / /run/media/grant/PrecisionBackupExclude the --dry-run flag when you're read to go for real. (Update: I probably could/should have exclude the /var/lib/docker/* directory too to save space.)
I followed (most of) the tips on Patrick Schratz' outstanding guide. His setup is tailored to R and spatial analysis, which covers my major needs. Here is a list of things that I did in addition to that, including other languages and GPU setup.
Again, see Patrick's guide for general installation and optimization tips. However, I also made the following additional changes.
Adapting this SO post answer, I set a system wide library path as follows:
$ sudo groupadd rusers
$ sudo gpasswd -a grant rusers
$ cd /usr/lib/R ## Get location by typing ".libPaths()" in your R console
$ sudo chown grant:rusers -R R/
$ sudo chmod -R 775 R/Once that's done, tell R to make this shared library path the default for your user, by adding it to your ~/.Renviron file:
$ echo 'R_LIBS_USER=/usr/lib/R/library' >> ~/.RenvironReinstallation of R packages is already much quicker thanks to ccache. However, I also enabled parallel compilation of R packages to speed up first-time installation, as well as any further compiling that needs to be done.
$ echo 'options(Ncpus=parallel::detectCores())' >> ~/.RprofileAn optimised BLAS library like OpenBLAS or MKL yields significant speed improvements. One downside is that upgrading OpenBLAS requires manual reinstallation of the linked R packages. Trying to load the sf or lfe packages for example, will prompt the following error message: libopenblas.so.3: cannot open shared object file: No such file of directory
(Reason: R itself loads the packages and so they are "hidden" from the OS. This means that the normal OS resolution of dynamic library loading after an update — via $ ldconfig and co. — doesn't work.)
It's possible to fix this problem through trial and error; i.e. simply reinstall any package that prompts the above loading error manually. However, a much better way is to do everything in one fell swoop with this script from Michael Lang.
Patrick mentions in radian — a modern R console with a bunch of nice features ‐ in his guide. This entry is just to note that I needed to update my PATH, so as to include the location where the radian source script was installed. (I was duly notified about this during the pip installation).
$ echo 'export PATH="$HOME/.local/bin:$PATH"' >> .zshrc
$ source ~/.zshrcFollowing Jake Vanderplas, I opted for Miniconda instead of the full-blown Anaconda install.
In most cases, your conda environment should automatically get added to your PATH. However I installed Miniconda3 using bash before switching over to the zsh shell. As a result, I had to add the Miniconda directory to the zsh PATH environment variable (see here).
$ echo 'export PATH="$HOME/miniconda3/bin:$PATH"' >> ~/.zshrc
$ source ~/.zshrc ## Or you can just close and reopen the shellTo activate conda environments, you first need to initialise this capability for your particular shell (zsh, fish, etc.). However, this has the undesirable effect of automatically activating the previous conda env whenever you open the shell, regardless of whether you want to use conda or not. Luckily there's a pretty simple solution:
$ conda init zsh ## Initialise. Then log out and then back in.
$ conda config --set auto_activate_base false ## Stop automatic activation.Once that's done, it's easy to activate and switch between environments
$ conda info --envs ## list all environments
$ conda activate tf_gpu ## activate the "tf_gpu" environment
$ conda deactivateNecessary, for example, when I wanted to add the Apache Arrow C++ module from Conda Forge.
$ conda config --add channels conda-forge
$ conda config --set channel_priority strictI already have a GPU-enable CUDA installation (see below), so opted for the JAX version that comes with both CPU and GPU support. For some reason, JAX expects CUDA to be located at /usr/local/cuda-X.X, so I first had to symlink with my actual CUDA install location.
$ sudo ln -s /opt/cuda /usr/local/cuda-10.2(The JAX installation guide also suggests the possibility of using an XLA_FLAGS environment variable to solve this problem, but that didn't work for me. More here.)
After that, I just used the suggested shell command to auto-install the right JAX version for my system.
$ pip install --upgrade https://storage.googleapis.com/jax-releases/`nvidia-smi | sed -En "s/.* CUDA Version: ([0-9]*)\.([0-9]*).*/cuda\1\2/p"`/jaxlib-0.1.51-`python3 -V | sed -En "s/Python ([0-9]*)\.([0-9]*).*/cp\1\2/p"`-none-manylinux2010_x86_64.whl jaxThere's a distributed version of Julia via the Arch community repos, but I eventually switched to using the official Julia binaries instead as is recommended. To take the pain out managing subsquent versions and updates, I used the handy JILL script:
$ sudo bash -ci "$(curl -fsSL https://raw.githubusercontent.com/abelsiqueira/jill/master/jill.sh)"This is a known issue. See: https://discourse.julialang.org/t/glibcxx-3-4-26-not-found-in-rcall/29113/11
First ID which version of JUlia is being used/symlinked.
readlink -f /usr/local/bin/juliaFor example, gives me /opt/julias/julia-1.5-latest/bin/julia. So the file I need to replace is /opt/julias/julia-1.5-latest/lib/julia/libstdc++.so.6 . I created a backup first just in case.
JULIA_HOME="/opt/julias/julia-1.5-latest"
sudo mv $JULIA_HOME/lib/julia/libstdc++.so.6 $JULIA_HOME/lib/julia/libstdc++.so.6_backup
sudo cp /usr/lib/libstdc++.so.6 $JULIA_HOME/lib/julia/
This section presumes that you have enabled your discrete GPU and installed the NVIDIA drivers (here). After that, you have a couple of options. I actually ended up installing several CUDA-enabled environments, since I have the disk space and this was easy enough to do. As you as wish.
As per this killer blog post, all you need is
$ conda create --name tf_gpu tensorflow-gpuAlternatively, you can also install the TensorFlow packages directly from the official Arch repos. For the GPU-versions:
$ pac install tensorflow-cuda python-tensorflow-cudaFinally, you can go through the excellent tensorflow and keras packages built for R. These allow for various installation options depending on your setup, as well as multiple installations for different Python virtual environments.
For example, the default install_keras(tensorflow = "gpu") approach will download and install everything to a new virtual environment located at ~/.virtualenvs/r-reticulate.
As another example, assume that you already created the "tf_gpu" conda environment described above. Then you obviously don't need to install the whole Python setup again. Instead, just tell R to interface with this existing environment as follows:
library(keras)
use_condaenv("tf_gpu") ## Now build your DL model...Update I've written a shell script that automates a lot of the steps outlined below. Just run $ sudo bash hidpi.sh. Particularly useful after sytem/application updates, since it saves have to do everything manually.
The Arch wiki has the goods here. I've even added a few sections for things that I had to troubleshoot. (E.g. Gnome Shell text scaling for Xorg sessions, although I primarily use Wayland.) Here are some additional things beyond that:
Annoyingly, I added a wiki section on RStudio HiDPI scaling that was removed by a mod for reasons that make absolutely no sense. At any rate if your RStudio fonts are too big, try editing the RStudio desktop app so that it recognizes an appropriate QT_SCALE_FACTOR environment variable. (A scaling of 0.5 works well for me, but play around.) Open /usr/share/applications/rstudio.desktop with your preferred text editor as root. Then change the first line to:
Exec=env QT_SCALE_FACTOR=0.5 /usr/bin/rstudio-bin %F
Next time you launch RStudio, all of the fonts (including menu items) should now be correctly scaled.
Rstudio has started to require OpenSSL 1.1 (the package is called openssl-1.1). It's not enough to have the latest version of OpenSSL installed. The error you'll see is the following when trying to launch Rstudio from the terminal (GUI will just fail):
rstudio: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
This one took a little bit of troubleshooting. Everything was way too big initially. To fix, first go to Options > Configure TeXstudio > Adv. Editor > Hacks/Workarounds. (Note: Make sure the "Show Advanced Options" box at the bottom of the configure panel is checked.) Uncheck Try to automatically choose best display options. Then, change Render Mode to "Qt". Cick OK and close TeXstudio.
Once that's done, similarly to what we did for RStudio, open up the desktop app at /usr/share/applications/texstudio.desktop and add an appropriate scaling factor.
Exec=env QT_SCALE_FACTOR=0.5 texstudio %F
Re-open Texstudio and bath in the serenity of your correctly scaled workspace.
Another thing I'll add explicitly here is how to change the default Linux Console font that appears when booting up (or when booting into TTY). First download the terminus fonts family:
$ pac install terminus-fontYou can then see the set of available fonts by typing ls /usr/share/kbd/console. To temporarily test out a larger font, type
$ setfont ter-132n(Type showconsolefont if you want to see a table of the font's glyphs and letters).
To set this font permanently, open /etc/vconsole.conf with nano and add
FONT=ter-132n
My university mail system runs on MS Outlook (Exchange). While it's certainly possible to connect to the Exchange system using standard Linux mail apps like Evolution, Thunderbird, etc., I enountered slight (and slightly annoying) delays across my devices. Luckily, it's now possible to run Outlook — or, indeed, any other web app — "natively" on Linux thanks to nativefier. On Arch, there's even an AUR package that installs the whole Office 365 suite for you. However, I opted to install and configure a nativefied Outlook app myself, so that I could run it as a separate entity. (It's not really separate as you can still switch between the different Office 365 apps, but you get the point.) Start by installing the Node.js nativefier command line tool.
$ npm install nativefier -g
## Or, use the packaged AUR version: https://aur.archlinux.org/packages/nodejs-nativefier/
# $ pac install nodejs-nativefierNext, create the app
$ nativefier -n "Outlook-Office365" --maximize --show-menu-bar --internal-urls ".*(office|office365|sharepoint|microsoft|onenote|microsoftazuread-sso|microsoftonline)\.(com).*" --tray --counter --single-instance 'https://outlook.office.com/owa'This will create a folder called outlook-office-365-linux-x64 in your current directory containing all of the scaffolding needed to run the Outlook app. So you can start Outlook from the shell simply by calling
$ ./outlook-office-365At this point, everything is good to go. (Simple!) However, I wanted to make some additional configurations, so that Outlook could be run as a regular desktop app in Gnome (i.e. click to open) and also fix some HiDPI scaling issues. There are some good resources for how to do this (e.g. this one for Ubuntu), but here's a quick rundown of my own steps. The first step is optional, but moving the folder to /opt allows other users to access the new Outlook app too.
$ sudo mv outlook-office-365-linux-x64 /opt ## Optional: Move the app folder to /optNext, you want to find the hexidemical (6-character) "suffix" associated with your particular app instance. This hexidecimal string represents the so-called WMClass property of your app, preserving your session state so that you don't need to keeping logging in every time. From a practical perspective, finding the WMClass string will prevent additional Outlook icons from popping up in your desktop launcher whenever you start the app. (More here and here.) There are a couple of ways to find the WMClass, but the simplest is probably just to start the app if you haven't already ($ /opt/outlook-office-365-linux-x64/outlook-office-365). Then, run the following command in your terminal and click on your Outlook app window.
## Run this command and then click on your open Outlook app window
$ xprop WM_CLASS
## Should return shomething like:
## WM_CLASS(STRING) = "outlook-office-365-nativefier-xxxxxx", "outlook-office-365-nativefier-xxxxxx"Now that you have the WM_CLASS, we can create our desktop app entry. Create a new ms-outlook.desktop file by running
$ sudo nano /usr/share/applications/ms-outlook.desktopand then pasting across the below text chunk. Don't forget to replace xxxxxx in the bottom line with your actual WM_CLASS string. (Also: Drop the --force-device-scale-factor=2 flag if you aren't on a HiDPI machine.)
[Desktop Entry]
Name=MS Outlook
Comment=MS Outlook (nativefier)
GenericName=Outlook
Exec=/opt/outlook-office-365-linux-x64/outlook-office-365 --force-device-scale-factor=2
Terminal=false
Type=Application
Icon=/opt/outlook-office-365-linux-x64/resources/app/icon.png
StartupNotify=true
StartupWMClass=outlook-office-365-nativefier-xxxxxxSave and close (Ctrl+X, y). Finally, update your icon cache.
## Change to your default theme locationas needed
$ sudo gtk-update-icon-cache /usr/share/icons/hicolor -fYou should now able to launch Outlook like any desktop app (e.g. using the super key in Gnome and search for "outlook"). It can also be added to your launcher favourites in the usual way. (See my desktop screenshot at the top of this README.)
I prefer Tilix to the default Gnome terminal. The old way of changing the default terminal no longer works in the latest versions of Gnome (see here). But a simple solution that covers most use cases is to modify the "Ctrl+Alt+T" shortcut. Go to Settings > Devices > Keyboard Shortcuts. At the bottom, change the "Terminal" command entry to "tilix" (from ").
My home printer had been found automatically at first. However, I couldn't find it after a while for some reason. Adding it manually was a pain, because I didn't have the correct permissions in CUPS. (Adding myself to the "cups" user group didn't work either.) I solved the problem by following these instructions.
Relevant to cases where you need to log into the Shell/TTY to fix some hanging/freeze problem (e.g. CUDA/NVIDIA above). The easiest way I've found is to use nmcli (command line version of network manger). To see the available SSIDs type
$ nmcli dev wifiThen connect with
$ nmcli dev wifi connect SSID_NAME password SSID_PASSWORDSimilar rationale to the above:
$ XDG_SESSION_TYPE=wayland dbus-run-session gnome-sessionAlternatively, launch via GDM:
$ sudo systemctl start gdmI initally installed Julia via the Arch community repos. However, a build problem cropped up when upgrading to Julia 1.2.0; see bug report and GitHub issue. I ultimately took this as a sign to install the official Julia binaries instead. (See above.) However, this also seemed like a good chance to practice compiling a package from the community repos with an edited PKGBUILD. There's suprisingly little guidance about this online, although this Manjaro forum thread proved very helpful. My full steps as follows:
- Create some folder to download the relevant files to. I used
~/juliabut I don't think the location really matters.
$ mkdir ~/julia
$ cd ~/julia- Download/create the PKBUILD and ancilliary files to this location. There may be a smart way to to this automatically, but I just created the files manually using nano+copy+paste.
- Edit the PKGBUILD (and any other files) as needed.
- Build the package. This will take a while. Note: Using regular
$ makepkg -sigave me errors. So instead I used:
$ makepkg -g >> PKGBUILD
#$ makepkg ## Gives GPG verification error. Fix that below first:
$ gpg --recv-key 66E3C7DC03D6E495 ## Add GPG key
$ makepkg ## NB: Don't use sudo!- Install the pkg.tar file. Be careful not to confuse with any of the other .tar files lying around in the same directory.
$ sudo pacman -U julia-2:1.2.0-1-x86_64.pkg.tar- The updated version of Julia was now ready to go:
$ juliaNote: Only relevant for the Plasma DE, which I'm no longer using. The KDE graphical touchpad settings (System Settings > Input Devices > Touchpad) didn't seem to last and kept reverting back to the default behaviour. So I installed libinput and then followed the final section of this guide (See Fig. 7) to get tapping, right-click two finger tap, etc. working.
Following the resolution of the Antergos Project, I removed all (or, at least, most) of the residual Antergos libraries following these guides. This leaves a pure Arch system.
In related news, Endeavour OS has picked up where Antergos left off and looks really cool.