🌵OldMartijntje

Avans 2-x POA Arch Linux

13 min read

ID: S202602050916
Status: school
Tags: Arch Linux, POA

Arch Linux Progress information

I have a Arch Linux Todo, this is mostly things that I must not forget to do later on. Things that I have read in the ArchWiki but what I do not have time for yet.

Initial Setup

  • 05/02/2026 09:15-11:30
  • 05/02/2026 12:30-16:15
  • Total: 6h

I installed the torrent version, and then installed sudo apt install qbittorrent to be able to download the full file from the torrent. After torrenting the entire file, I checked the .iso it’s checksum:

echo "c0ee0dab0a181c1d6e3d290a81ae9bc41c329ecaa00816ca7d62a685aeb8d972  /home/<my_username>/Downloads/archlinux-2026.02.01-x86_64.iso" | sha256sum -c -

And it returned: /home/<my_username>/Downloads/archlinux-2026.02.01-x86_64.iso: OK which means it is good. Make sure to use the current checksum from the download page.

I am going to install it with a USB flash drive.

After installing the flashdrive, I have to point my pc to it in the BIOS and select Arch Linux Install Medium

Installing the flash drive

I first made sure that it is not mounted. then I ran

sudo dd bs=4M if=/home/<my_username>/Downloads/archlinux-2026.02.01-x86_64.iso \
  of=/dev/disk/by-id/usb-Generic_Flash_Disk_ABC00630-0:0 conv=fsync oflag=direct status=progress

When booted in terminal

After you told the BIOS to boot Arch Linux, you will be met with a terminal.

localectl list-keymaps
loadkeys us
setfont lat2-16 -m 8859-2

cat /sys/firmware/efi/fw_platform_size

With this we can see our Boot mode. If it is 64, it means it is UEFI booted in 64 bit.

Connect to internet

Then we try and connect to the internet with

ip link

To verify that you connected to it, you can ping:

ping ping.archlinux.org

Sync the clock

timedatectl

Mounting and formatting

wipefs -a /dev/nvme0n1
parted /dev/nvme0n1 mklabel gpt
parted /dev/nvme0n1

And then in the parted, these commands:

mkpart EFI fat32 1MiB 1025MiB
set 1 esp on
mkpart SWAP linux-swap 1025MiB 5121MiB
mkpart ROOT ext4 5121MiB 100%
quit

mkfs.fat -F32 /dev/nvme0n1p1
mkswap /dev/nvme0n1p2
mkfs.ext4 /dev/nvme0n1p3

then I ran:

blkid /dev/nvme0n1p1 /dev/nvme0n1p2 /dev/nvme0n1p3

And nano /etc/fstab:

# /etc/fstab: static file system information.
# See man fstab(5)

# EFI System Partition
UUID=AA11-BB22   /boot     vfat    defaults,noatime   0 2

# Swap
UUID=11112222-3333-4444-5555-666677778888   none    swap    sw   0 0

# Root filesystem
UUID=99998888-7777-6666-5555-444433332222   /   ext4   defaults,noatime   0 1

Where the UUID’s are replaced with the ones the blkid command showed.

and then I ran mount -a to test it.

pacstrap -K /mnt base linux linux-firmware amd-ucode networkmanager nano vim man-db man-pages

Configuring

genfstab -U /mnt >> /mnt/etc/fstab
arch-chroot /mnt
ln -sf /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime
hwclock --systohc
locale-gen

Then I created a /etc/locale.conf with LANG=en_US.UTF-8. I also created /etc/hostname with mothership as text. and i created /etc/vconsole.conf with the same keyboard as before: KEYMAP=us

Then I set a root password:

passwd

Then I skipped setting up a bootloader since I already have grub for my ubuntu, so I loaded my ubuntu and ran:

sudo update-grub

grub-install —target=x86_64-efi —efi-directory=/boot/efi —bootloader-id=Arch grub-mkconfig -o /boot/grub/grub.cfg


and then this on my ubuntu to keep using the grub on ubuntu's side:

sudo os-prober sudo update-grub

Fixing more bugs

  • 18/02/2026 13:00-13:45
  • Total: 6.45h

When I relaunched my Arch Linux partition, I got this:

[FAILDED] Failed to mount run-rpc_pipefs.mount - RPC Pipe File System. See 'systemctl status run-rpc_pipefs.mount' for details

And my first approach was to just immediately reboot. That didn’t fix it. When I ran systemctl status run-rpc_pipefs.mount I got this:

âś• run-rpc_pipes.mount - RPC Pipe File System
Loaded: loaded (/run/systemd/generator/run-rpc_pipes.mount; generated)
Active: failed (Result: exit-code) since Wed 2026-02-10 13:09:04 CET; 55s ago
Where: /run/rpc_pipes
What: sunrpc
CPU: 1ms
 
Feb 18 13:09:04 oldmartiintje-MS-7E26 systemd[1]: Mounting run-rpc_pipes.mount - RPC Pipe File System...
Feb 18 13:09:04 oldmartiintje-MS-7E26 mount[396]: mount: unknown filesystem type 'rpc_pipes'.
Feb 18 13:09:04 oldmartiintje-MS-7E26 mount[396]: dmesg() new heuristic information entry failed mount system call.
Feb 18 13:09:04 oldmartiintje-MS-7E26 systemd[1]: run-rpc_pipes.mount: Mount process exited, code=exited, status=32/n/a
Feb 18 13:09:04 oldmartiintje-MS-7E26 systemd[1]: run-rpc_pipes.mount: Failed with result 'exit-code'.
Feb 18 13:09:04 oldmartiintje-MS-7E26 systemd[1]: Failed to mount run-rpc_pipes.mount - RPC Pipe File System.

Claude Haiku 4.5 has assessed that the issue is because my Arch install includes NFS client by default via networkmanager and base packages. The system tries to mount the RPC pipes filesystem, but the sunrpc kernel module either isn’t loaded or configured properly. This is harmless but noisy.

It suggests 2 paths:

  • disabling NFS
  • Loading the kernel module to fix it.

The Arch wiki tells me that NFS is a distributed file system protocol, allowing a user on a client computer to access files over a network in a manner similar to how local storage is accessed. Seeing as I might use this in the future, I will go with the fix route instead of avoidance.

I tried running sudo modprobe sunrpc but that gave me a FATAL: module sunrpc not found in directory /lib/modules/6.18.7-arch1-1. This points me towards the fact that sunrpc doesn’t exist and didn’t come bundled with my install. I could re-bundle the kernel headers. but i’ll just choose the disable route for now. I’ll just write it down in my Desktop Arch Installation Context note.

sudo systemctl mask run-rpc_pipes.mount
sudo systemctl mask rpc-gssd.service

And it got this response:

Unit run-rpc_pipes.mount does not exist, proceeding anyway. Created symlink /etc/systemd/system/run-rpc_pipes.mount → /dev/null.

Created symlink /etc/systemd/system/rpc-gssd.service → /dev/null.

and then I ran systemctl reboot to check if it has been fixed.

Now when I select my Arch Linux in my grub, it first displays the text of, initialized A, initialized B etc etc. and then it sends me to my Ubuntu login screen?? I wanna cry SKULLEMOJI

Post-Installation

  • 18/02/2026 14:00-14:15
  • 19/02/2026 11:45-12:00
  • Total: 7.15h

The issue is as described above: Now when I select my Arch Linux in my grub, it first displays the text of, initialized A, initialized B etc etc. and then it sends me to my Ubuntu login screen.

First off I am going to run sudo update-grub again on my Ubuntu. And that has fixed the issue :D

See General recommendations for system management directions and post-installation tutorials (like creating unprivileged user accounts, setting up a graphical user interface, sound or a touchpad).

For a list of applications that may be of interest, see List of applications.

This was at the end of the arch wiki installation guide. And we’ll be going to do the general recommendations now.

A new installation leaves you with only the superuser account, better known as “root”. Logging in as root for prolonged periods of time, possibly even exposing it via SSH on a server, is insecure.

So now we are going to create an unprivileged account. We are going to do so by first reading about users and groups: Arch wiki.

useradd -m pye
passwd pye

This has added my main user to the pc.

Security

  • 19/02/2026 11:45-13:30
  • Total: 9h

I am going to be hardening my system according to the Arch Wiki. This page goes deeply into securing your passwords. Principles on how to backup your passwords, etc etc. It also explains how hashing works, it mentions salted passwords and rainbow tables.

I ran grep -r . /sys/devices/system/cpu/vulnerabilities/ to see if there were any known vulnerabilities on my CPU, all entries are either Not affected or it is already mitigated.

Data-at-rest encryption, preferably full-disk encryption with a strong passphrase, is the only way to guard data against physical recovery. This provides data confidentiality when the computer is turned off or the disks in question are unmounted. But I do not need this on my desktop, so for now I’ll skip this.

The default umask 0022 can be changed to improve security for newly created files. The NSA RHEL5 Security Guide suggests a umask of 0077 for maximum security, which makes new files not readable by users other than the owner. So I switched to our user to see our umask value:

su pye
umask
exit

This returned a 0022

So I ran nano /etc/login.defs and changed the umask from 022 to 077. This means it has been set globally :3

Enforce delay on failed login attempts: Add the following line to /etc/pam.d/system-login to add a delay of at least 4 seconds between failed login attempts, ofc with an editor like nano:

auth optional pam_faildelay.so delay=4000000

4000000 is the time in microseconds to delay.

I have learned that sudo is better than su because apparently:

  • sudo keeps a log of commands executed.
  • it prevents you from auto running things as root since your terminal stays normal. Only the commands where you add sudo will be privileged.

Denying root via SSH Even if you do not wish to deny root login for local users, it is always good practice to deny root login via SSH. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely. SSH can be configured to deny remote logins with the root user by editing the “Authentication” section in the daemon configuration file. Simply set PermitRootLogin to no:

nano /etc/ssh/sshd_config.d/20-deny_root.conf

and set it to be like:

PermitRootLogin no

And then restart the SSH daemon or just, wait till you restart your pc and don’t use SSH in the meanwhile.

I know that it can be smart to disable emergency shell, but I am not risking breaking my system and not being able to recover it. So I am taking the attack risk.

And with this, we finally left the security section of the ArchWiki. We will come back to it via the Arch Linux Todo, but for now, we are able to continue.

System Maintenance

  • 19/02/2026 15:45-16:45
  • Total: 10h

Arch Linux is a rolling release system and has rapid package turnover, so users have to take some time to do system maintenance.

Running systemctl --failed gave me 0 errors.

I ran journalctl -b, it gave me this error when scrolling through:

RDSEED32 is broken. Disabling the corresponding CPUID bit.

I have opened this new article for it: RDSEED32 is broken - Disabling the corresponding CPUID bit.

Before upgrading, users are expected to visit the Arch Linux home page to check the latest news, or alternatively subscribe to the RSS feed or the arch-announce mailing list. When updates require out-of-the-ordinary user intervention (more than what can be handled simply by following the instructions given by pacman), an appropriate news post will be made.

Before upgrading fundamental software (such as the kernel, xorg, systemd, or glibc) to a new version, look over the appropriate forum to see if there have been any reported problems.

Users must equally be aware that upgrading packages can raise unexpected problems that could need immediate intervention; therefore, it is discouraged to upgrade a stable system shortly before it is required for carrying out an important task. Instead, wait to upgrade until there is enough time available to resolve any post-upgrade issues.

Tip

You could use a pacman hook like informant, newscheck or arch-manwarn which prevents you from updating if there is fresh Arch News that you have not read since the last update ran.

When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums or check the latest news on the Arch Linux homepage (see Read before upgrading the system) for more detailed instructions.

Installing software Pacman does a much better job than you at keeping track of files. If you install things manually you will, sooner or later, forget what you did, forget where you installed to, install conflicting software, install to the wrong locations, etc.

PACMAN pacman is the Arch Linux package manager: it is highly encouraged to become familiar with it before reading any other articles. Ofc I have my own article: pacman.

stuff

  • 16/03/2026 15:15-15:30
  • Total: 10.25h

Learn about repositories. link

Graphical User Interface

  • 16/03/2026 15:30-18:15
  • Total: 13h

There is this list of things related to the GUI.

This is the point where I’ll have to choose a desktop environment:

  • KDE
  • GNOME
  • COSMIC
  • Xfce
  • Cinnamon
  • LXDE

I have chosen KDE. This means I’ll have to follow the KDE guide.

after fixing the user doesn’t have sudo access issue, i was able to run pacman -S plasma-meta as pye. I couldve also just installed it from root user. but I haven’t been using root for a bit

Running pacman -S plasma-meta gave me a lot of 404 issues. so i did:

sudo pacman -S archlinux-keyring
sudo pacman -Sy

And then I retried sudo pacman -S plasma-meta and it fixed the issue I had, but gave me another issue. Some packages already existed, so I tried:

sudo pacman -Syu gcc-libs
sudo pacman -S plasma-meta

And this finally allowed me to install it.

user doesn’t have sudo access

I am using pye ever since I created the user, so it could easily be fixed by logging into root user, but i don’t want to.

pye didn’t have access to run sudo. so i did the following when logged in as root:

su
pacman -S sudo
usermod -aG wheel pye

and then edit /etc/sudoers so that this is not commented out %wheel ALL=(ALL:ALL) ALL

and then i logged out and into pye: logout

nvidia and stuff

If you are an NVIDIA user, ensure the DRM kernel mode setting is enabled. is what the KDE page on the ArchWiki says.

Which gives me the command cat /sys/module/nvidia_drm/parameters/modeset on the nvidia page. But for this I first need to install nvidia drivers.

lspci -k -d ::03xx

This command gives you information about your nvidia GPU, and on this website you’ll be able to find the codenames.

Make sure to pick the right drivers as told on the nvidia page on the ArchWiki. I ran this:

sudo pacman -S nvidia-open

Then to avoid some issues:

sudo nano /etc/pacman.conf

and made sure Include = /etc/pacman.conf.d/mirrorlist wasn’t commented out ([multilib])

sudo pacman -Sy
sudo mkinitcpio -P

I tried running the optional sudo pacman -S lib32-nvidia-utils since I’d need it in the future for steam (I thought I had read). but it failed. So I have skipped it for now.

it is time for a sudo reboot.

And I got yet again booted into ubuntu instead of Arch Linux, when I selected Arch in the grub menu. I think this is an issue to do with the reboot vs the shutdown + startup, cause the latter works normally.

cat /sys/module/nvidia_drm/parameters/modeset

this command now finally returns something: Y

Starting plasma

/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

Touchdown, we have a GUI.

now, let’s make it load on startup.

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/plasmawayland.service

And then add this:

[Unit]
Description=Start KDE Plasma on Wayland
After=graphical-session-pre.target
PartOf=graphical-session.target

[Service]
Type=simple
ExecStart=/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland
Restart=on-failure

[Install]
WantedBy=graphical-session.target

and then:

systemctl --user daemon-reload
systemctl --user enable plasmawayland.service
sudo reboot

and that gave me a startup issue :/

References

Graph View

Backlinks