Moving to Manjaro

Cordelia’s been on a couple different Linux distributions. Initially it was built in Fedora Server. Later I moved over to Ubuntu Server 22.04 LTS.

And recently I decided to move it to Manjaro.

Why the move?

I was looking for a “minimal” Linux distro with a desktop. And why the desktop when this is a virtualization server? VirtualBox’s user interface.

Basically I just got fed up with having to deal with the command-line with VirtualBox. I use VirtualBox on my Windows desktop a LOT, so having that UI for managing the virtual machines on Cordelia is, more or less, something I can’t really do without anymore. Since I have a couple projects coming up for which I want to be able to create and remove VMs more-or-less on-demand.

I’m also using a third-party Pi-KVM from Geekworm to remotely control this system, so a web UI (e.g., Proxmox) isn’t necessary for controlling the virtual machines. Though I will still be using Portainer CE to monitor and control the Docker containers.

What else did I consider?

Rocky Linux and Linux Mint were the only other considerations.

With Rocky, I did not like the desktop installed with its “Server with GUI” option. And I didn’t want to mess around in figuring out how to add a desktop to an installation without one. That also meant Arch was definitely NOT in the running here.

But the “Server with GUI” option did mean it was above Linux Mint in the contention. Well above it, actually. My singular gripe with Mint – but also the main reason it exists – is the inability to control what is installed. Meaning I’d be going in and removing a lot of things before I started adding in what I wanted.

That it was based off Ubuntu is the only reason I considered Mint. Since that meant it wouldn’t be too far off what I previously had. And I would’ve been able to use the official repositories for Docker and VirtualBox.

But in trying out Manjaro’s “Minimal” distribution (specifically with KDE Plasma) in a virtual machine, I was very pleasantly surprised at how little was installed. With Docker and VirtualBox also installed, the entire installation footprint on the main boot partition is… not even 10 GB.

Proxmox wasn’t even a consideration.

Why not Proxox?

I’ve already written before on why I decided to move away from Proxmox. So unless those gripes have been corrected – specifically the one about not being able to make incremental updates without going through substantial steps – there’s nothing to discuss.

And I fully understand why Proxmox does that. But I don’t have to go along with it. And I won’t be.

Current specs

CPU:Intel Xeon E5-2697 v4 – 18 cores, 36 threads
CPU cooler:ThermalTake TH120
Mainboard:Machinist MR9S (buy on eBay)
RAM:256GB (8x32GB) Registered ECC DDR4-2400
GPU:Zotac GTX 1060 3GB
Storage:500GB Samsung 850 EVO M.2 SATA
Inland QN322 2TB QLC NVMe

The migration

The 500GB drive is the main OS drive. There were a few things sitting in my home folder that I just moved to the 2TB NVMe. I also copied off the entire /etc/fstab file to the NVMe drive so those could be restored with a simple copy/paste. Then it was a matter of just installing Manjaro with the open source drivers, again using the “Minimal” version of the distro for the smallest installation footprint, going with the KDE Desktop – though I may redo the installation later using the Cinnamon installer.

With Manjaro installed, the next major step was restoring the fstab entries and mounting the media folders on Nasira.

Then came installing Docker and VirtualBox. My only gripe here being that there is not any official VirtualBox or Docker builds for Arch (and, by extension, Manjaro). I very much prefer that over relying on builds in a distro’s repository, but I think I can live with that. Here are the guides I followed:

The only necessary step I forgot to take before installing Manjaro was completely purging the old Docker folder. For storage space more than performance, I had it sitting on the NVMe drive as well. And I needed it completely gone to avoid conflicts – simple rm -rf (with sudo) and mkdir command combo. Configuring Docker to use that folder is straightforward, especially if you have jq to make the JSON file:

# Install jq with this command:
# sudo pamac install --no-confirm jq

sudo systemctl stop docker # If it's running
sudo mkdir /etc/docker

echo '{}' | jq '."data-root"="/path/to/new/docker"' | sudo tee /etc/docker/daemon.json

sudo systemctl start docker

Side note: if you work with JSON regularly – e.g., creating JSON files for server configurations during deploys – and you’ve never used or heard of jq, you really need to check it out. It can eliminate a LOT of complication. Anyway…

Plex was the only critical Docker container for restoration, but also the easiest to set up. I had everything critical living outside any Docker volumes, with it all being connected in via the -v switch. So getting Plex back online was just a matter of running my update-plex.sh script I first mention in my article about migrating Plex from a VM to Docker:

sudo docker stop plex
sudo docker rm plex

sudo docker pull plexinc/pms-docker

sudo docker run \
-d \
--name plex \
--network host \
-e TZ="America/Chicago" \
-v /path/to/plexmediaserver:/config \
-v /path/to/media:/mnt \
-h plexmedia \
plexinc/pms-docker

Portainer was the next container to restore using the update script I keep around for that:

sudo docker pull portainer/portainer-ce

sudo docker stop portainer
sudo docker rm portainer
sudo docker run -d \
-p 9443:9443 \
--name portainer \
--restart=unless-stopped \
-v /var/run/docker.sock:/var/run/docker.sock \
-v portainer_data:/data portainer/portainer-ce

With the latest versions of Docker, you actually do NOT need to create volumes in advance of creating the containers unless you’re restoring data into them. When running the above script for the first time, Docker will automatically create the portainer_data volume. You do not need to run docker volume create portainer_data first.