arch chaos

Tue, 23 Jan 2024 00:00:00 GMT

本文由 LLM (DeepSeek) 自动翻译生成，仅供参考。如有错误或不准确之处，请以原文为准。
Translated by LLM (DeepSeek) automatically, for reference only. Please refer to the original text for accuracy.

Origin

Anyway, installing a physical Linux system is always a rite of passage in the coding community... However, I am quite risk‑averse. I kept putting it off until my portable hard drive had no stable power source other than a computer (previously, plugging it into the router’s junk box always caused it to disconnect). So what else could I do with that hard drive? I just threw some random system onto it.

This article is not a serious tutorial; it’s a record of my chaotic dance during the installation. Proper tutorials will be listed in the references.

Note the timeliness of this article – I was driven crazy by the timestamps of forum posts when I was installing.

Preparation

Source of everything: arch download

The canon: arch wiki

Magic: I can’t imagine how much effort a magical Ethernet cable saved me. There’s no guarantee that the wireless card would work out of the box, not to mention stability and speed. More importantly, how could various proxy setups compare to a default transparent proxy? Even if you know all kinds of mirrors and proxy software, you’d still need to set environment variable proxies and individual configurations for each app...

Getting Started

Now, let the chaos begin. First, I didn’t want to burn a USB boot device. I just couldn’t find my USB stick at the time – a portable hard drive would have worked, but since I was going to install the system on it anyway, I figured I might as well boot directly into it. I couldn’t be bothered with VMware either, so I dug out Hyper‑V on Windows and gave it a try. Just boot the Arch ISO with Hyper‑V, remember to pass through the target disk, and most other VMs should support this too.

The advantage is that you don’t need a real USB boot drive. In fact, I even booted Arch inside the VM and could later boot it on bare metal (though with plenty of hardware issues – it was mainly for initial debugging) ...

Installation

I mainly followed the archlinux concise guide – basically just tweaking miscellaneous settings, partitioning the disk, and mounting things properly. If you want encryption, you have to do it at this stage. Linux isn’t like Windows where you can casually enable BitLocker and still have decryption; I used btrfs and later realised there was no way to encrypt it at runtime, so I skipped it. After that, I disabled Secure Boot, changed the boot entry in BIOS, and I was in Arch.

But such a system is not enough. A GUI is optional, but with modern laptops having dual graphics and an external monitor – NVIDIA Optimus or whatever – it’s a mess. First off, I never relied on optimus‑manager. Fiddling around with it is annoying; fortunately, ASUS has a good asus-linux that manages GPUs well. I also recommend nvidia-tweaks – it sets up everything for NVIDIA so you don’t have to worry. Then just use prime‑run for NVIDIA apps; the integrated GPU works fine for daily tasks (though I was eventually forced to bypass the dGPU for the external monitor).

Secure Boot is mandatory on Windows 11 – Windows Hello and BitLocker need it, so I couldn’t avoid it. But setting up hooks and signing things manually, with updates to worry about, was too much of a hassle. So I tried sbctl. It depends on BIOS implementation – it worked on my machine.

Troubleshooting

From the start, the dual‑GPU + external monitor setup caused all kinds of weird issues – nobody cares about this scenario anyway.

Initially, connecting the external monitor via a USB‑C DisplayPort directly to the dGPU was fine. Switching the BIOS to integrated graphics would kill the external monitor – expected, because I knew that particular USB‑C port is directly wired to the dGPU. But in hybrid mode, a bug appeared: the external monitor dropped to 36 FPS – it seemed like the output had to go through the CPU or iGPU copy. After thinking it over, I just switched to dGPU‑only mode. Fine, since I’m plugged into power anyway.

Then, a few days later, after an update to either the NVIDIA driver or the Linux kernel, the desktop in dGPU‑only mode failed to render completely – I was stuck in TTY. After hours of debugging, it dawned on me: the other USB‑C port is connected to the iGPU! So I plugged the external monitor into that port, and suddenly both iGPU‑only and hybrid modes worked (the external monitor was smooth again). I didn’t bother testing dGPU‑only.

Hardware acceleration is still a pain – Intel’s works well enough.

Migration

It’s impossible to seriously use a system installed on a portable hard drive over USB – the speed is abysmal. My NVMe SSD can read at 3000 MB/s, but over USB it barely reaches 20‑30 MB/s. That’s not a viable system.

So I transferred the root filesystem to the internal drive – there was plenty of free space anyway. This also prompted me to reorganise my internal disks and decrypt unnecessary BitLocker partitions (for file sharing between the two systems).

I freed up 142 GB on one of the internal SSDs. Since Arch was installed on btrfs, I used the snapshot send feature to send the root subvolume to the new location, then updated the UUID in fstab.

I also created a new ESP partition on the internal drive. Of course, with TPM + Secure Boot, changing the boot partition or EFI file would trigger BitLocker recovery.

Snapshots

Yes, I use Timeshift (though it has saved my bacon only a few times – installing often destroys /boot, which snapshots can’t fix). A minor bug (at least until a few weeks ago): even after specifying the subvolume layout, snapshots wouldn’t work. The fix was to use UUID instead of device paths in fstab. I don’t know if that’s still the case.

Hibernate

I actually dreamed of being able to hibernate both Windows and Arch simultaneously. ~~I almost succeeded, but NVIDIA issues and some weirdness during Windows hibernation were beyond me.~~

Now I’ve made it work – most of the time, at least! Both systems can hibernate independently, and the switching speed rivals a VM.

Currently, the conclusion is that it’s generally safe to hibernate Windows and boot Arch (which is already better than common wisdom). As for reading/writing an NTFS partition from Arch while Windows is hibernated… well, that happens to be my OneDrive folder – let it be.

Pacman & AUR Configuration

Everyone knows about mirrors, so I won’t elaborate – but speeding things up is still necessary.

In /etc/pacman.conf:

ParallelDownloads: enable parallel downloads.

In /etc/makepkg.conf:

CFLAGS: change to -march=native
MAKEFLAGS: change to -j$(nproc)

Maintenance

I even wrote a pacman hook to update the package list after every installation. ~~(yay is a pacman wrapper – you can use others.)~~ Switched to paru – because Rust is the future.

paru -Qqe > pkglist.txt  # list of all explicitly installed packages

For a reinstall (which I will never allow!):

paru -S --needed - < pkglist.txt

OCD commands:

paru -c
yes | paru -Scc

dotfiles

I use yadm, ~~with git-crypt encryption and a private repository – barely secure...~~ Encryption is overkill – don’t bother.

Fonts: Fonts expose everything. ~~Just steal C:\Windows\Fonts from Windows.~~ Get them from the AUR.

Forcing Wayland: Even now, it still needs some configuration. ~~It’s far from “default works” – I have:~~ It’s good enough now.

hyprland (legacy)

It’s a bit annoying but actually usable – it can coexist with KDE without problems. However, the official version doesn’t support NVIDIA – use it as long as you can. The configuration is messy – if you like it, tinker; if not, grab a ready‑made config like Arch-Hyprland, then pick up some dotfiles from GitHub.

Security

I can’t stand the feeling of insecurity – call it paranoia. So I decided to re‑create the root partition with full encryption.

You can’t encrypt in‑place. I transferred the entire / to an external drive for storage. Ideally, you’d boot an ISO as if reinstalling, but no – I simply changed the kernel parameters and operated elsewhere. (But then I realised how annoying GRUB is! It loves to decide my root location…)

So I realised that having a bootloader that insists on choosing my kernel parameters is frustrating. Enter Unified kernel image. But I haven’t fully escaped yet – that shows the strange nature of people: if there were no grub-mkconfig, and you had to write the bootloader config manually, you’d tolerate it. But with it, seeing it decide my boot entries and kernel parameters makes me uneasy (though if no good alternative exists, I’d still end up modifying grub‑mkconfig scripts).

Solution: Limine

b2sum verification of UKI
Modified Limine source to embed public keys and verify its configuration with signatures (instead of just the built‑in enroll‑config)

This avoids Secure Boot / TPM triggering after kernel updates.

Remaining

Security is a chain – here’s a brief summary:

Secure Boot

Same as sbctl: sign the bootloader and UKI (the bootloader is extra attack surface anyway – UKI can boot directly, but I still want to choose Windows).
Full Disk Encryption

Add TPM for TPM+PIN disk decryption (imitating BitLocker). The default PCR 7 measurement is fine. Also add a physical FIDO2 key + PIN for high security, plus a recovery key.

Partition layout remains the same: a 100+ GB encrypted block containing a btrfs filesystem with @ and @home subvolumes. Behind that, a swap block (previously a swap partition), now also LUKS‑encrypted, containing a swap partition – and I still need hibernation, otherwise a random key would suffice.

After comparing, systemd’s initramfs is more powerful, so I replaced mkinitcpio hooks (see dm-crypt/System configuration - ArchWiki). The root must be decrypted inside initramfs. According to the wiki, crypttab.initramfs and rd.luks both work, but I could only make it work with rd.luks kernel parameters – not sure why.

For swap – if you don’t need resume, you can decrypt it after boot. But for resume, it must be in initramfs. Solution: pass rd.luks again, but I didn’t want to enter two passwords, nor use the same key. I chose chained unlocking: store the swap partition’s keyfile inside the root filesystem. This means decrypting sequentially in initramfs – surprisingly, it works: rd.luks.key=SWAP-UUID=/@/keyfilepath:/dev/mapper/root – a horrible syntax.

One discovery: rd.luks added for root doesn’t need the tpm option to use TPM – if a TPM key exists, it will try it. My option only had FIDO2 – without the token, it falls back to TPM automatically, even though the option didn’t specify TPM.

Then I extracted all kernel parameters to pass to UKI generation. mkinitcpio generates the UKI, and I sign it with sbctl.

This way, kernel images and microcode no longer reside in /boot. I modified linux.preset to move ALL_kver and ALL_microcode into encrypted directories.

GRUB could no longer detect boot entries, so I manually added the UKI entry (chain‑loading) to /etc/grub.d/40_custom (changing its priority to be low enough).

Now Windows can’t directly access the Arch system (WinBtrfs used to work) – great, so secure! ... Not really. (But WSL can still unlock LUKS.)

This makes the Linux boot chain reasonably reliable.

Beautification

I added Plymouth and set loglevel, quiet – no more staring at a black screen during boot.

Rescue

Well, today it broke.

After a few days, when I booted, the system wouldn’t start. The kernel image had no decryption hooks? I was sure the hook configuration was correct last time I generated it. Anyway, it broke and I had to recover.

As noted above, my root is encrypted – but I had a recovery key. I dug up my offline storage (took a while to find where I put it), decrypted multiple layers, and finally got the key. Burned an Arch ISO to a USB, disabled Secure Boot, booted, manually decrypted the root (btrfs requires mounting subvolumes separately), arch‑chrooted in, fixed the hook configuration, regenerated the image – done.

This accident proved that my recovery design works and the security is acceptable. Strangely, re‑enabling Secure Boot (which should irrevocably change PCR values) didn’t trigger TPM (but I also have a PIN, so it’s not fatal) – weird.

New Thoughts

I’ve been tinkering recently. First, every WM’s compositor has its quirks. NVIDIA + Wayland is a disaster – maybe KWin is the real deal.

For full‑disk encryption, I removed kernel parameters and moved everything into /etc/crypttab.initramfs.

Swap is now a swapfile – one less encrypted partition.

~~nwg-shell components are usable – use them for notifications and status bar, although for the bar waybar is still fine.~~

Switched to dms-shell

Display manager: ly – simple and lightweight, written in Zig.

I also tried niri for a while – ~~tiling logic is a bit confusing, not as mature as hyprland.~~ I think I’ve figured it out.

~~Also strongly recommend the catppuccin theme – great for us code monkeys without design taste.~~

Using matugen to auto‑generate colour themes from wallpapers.

Wallpapers: awww plus custom scripts for rotation.

Virtual Machines

virt-manager runs Windows. This has allowed me to completely replace – well, not completely yet.

Wind_Mask's blog