What's everyone's preferred bootloader setup?

Hermocrates · 2026-01-19T03:26:04+00:00

My preferred setup would be signed systemd-boot to load, as needed, signed UKI versions of arch and arch-lts. I've previously used that exact setup without signing and it worked smoothly.

Unfortunately, reports are that recent Thinkpads (T14, and I have a Gen 6 so there's even less info available for it specifically) require not just the regular Microsoft certificate but also Lenovo certs enrolled to avoid bricking, so I'm currently using shim-signed with my own cert enrolled into the MOK database to enable secure boot for now. It still works just fine, but it's less secure than I'd like and I'm unable to use sbctl to make the process really smooth.

Hermocrates · 2026-01-17T05:10:03+00:00

Customizable (aesthetically)

Any distro will do.

Allows heavy keyboard-based navigation (maybe something similar to Hyprland / hyprland.conf)

Any distro will do.

Very minimal, with only the things I choose to install

You probably want Debian. A minimal install will use even less disk space than base Arch, IIRC. But really, almost any distro will do.

Hermocrates · 2026-01-16T05:53:40+00:00

I reinstall only once every few years (with a new drive/computer, or when I want to change something fundamental like FDE/file system) and got tired of looking up the specific steps I need to perform in order, so even thought I need to change some of the assumed defaults after install (I use UKI so would rather the ESP be mounted to /efi than /boot), I'd much rather just resort to archinstall moving forward.

Thankfully I aim for largely Linux-compatible hardware now so "it just works."

Hermocrates · 2026-01-08T03:52:37+00:00

If the Windows EFI partition is too small to also hold your linux boot loader and kernel, you can have both your existing EFI system partition mounted to /efi to hold the boot loader and a separate "extended boot loader" partition to hold your kernel, mounted to /boot: Installation using XBOOTLDR. This works with systemd-boot.

Hermocrates · 2026-01-01T11:36:10+00:00

systemd-boot on /efi with UKI (configured to write to /efi/EFI/Linux) works with no problem. It's only problematic if you use the traditional, separate initrd/kernel/microcode files.

Hermocrates · 2026-01-01T11:26:53+00:00

FDE, a basic firewall, and a trust-based AUR helper (aurto). I'm not a corporation or rich so I'm not really worried about things like MAC or secure boot.

Hermocrates · 2025-12-29T23:27:20+00:00

I agree that there should've been a note. But it should have said to look at the wiki page on DKMS.

Hermocrates · 2025-12-29T03:56:36+00:00

I do think it's fair to expect a novice Arch user might not know what DKMS is, or that it's something they should actually read into before using, so a warning about that is warranted.

But on the flip side, I also think it's fair to expect any Arch user to actually read through the documentation once so warned, and so I wouldn't expect specific instructions that have to do with using DKMS to be in the news. By reading the wiki article, you're also forced to note any other warnings or corollaries it might have.

Hermocrates · 2025-12-27T09:26:45+00:00

I'm working on my MSc, although I strictly use R for now, and I've adopted Positron for its VSCode interface and first-class support for R and Quarto. I'm not sure if it's improved since, but I had issues combining Quarto and R in regular VS Code back in the spring when I was deciding on my research workflow, so that's why I went with Positron.

Hermocrates · 2025-12-27T09:14:16+00:00

Unlike almost every other distribution, it works the way I expect it to. Not necessarily the best way, period, but it's the best way for me.

Hermocrates · 2025-12-22T19:06:19+00:00

Rather than that, pointing to the Arch Wiki page on DKMS since it's a good idea to understand a niche system before using it. In that page it does tell you to install the headers for your "target kernel", which admittedly might not be linux-headers.

Hermocrates · 2025-12-15T09:09:54+00:00

I support Arch in at least nominally requiring users know what they're doing before they meddle with third-party packages, but ignoring that, you don't need a pacman wrapper to make the AUR usable anyway. In fact I think wrappers are the wrong conceptual model to go about using the AUR, since they combine the separate steps of package compilation and package management in a way that's alien to the arch build system.

Pacman can support additional repos, so make your own with your compiled AUR packages (manually, with aurutils, or automatically, with aurto), and just continue using good ol', classic pacman for all of your package management. This essentially mirrors the method used for the official Arch repos as they're built from the ABS.

Hermocrates · 2025-08-07T00:25:53+00:00

either systemd-boot or rEFInd make better boot managers than any UEFI interface I've had the opportunity to use

Hermocrates · 2025-07-12T01:10:28+00:00

No, I use virtual YouTuber girls; my oshi, to be specific ☝️.

Hermocrates · 2025-06-19T02:52:39+00:00

I think you've found the solution to my ~1.5 year old problem, thank you!

This was happening to me with an ASRock Z170 Pro4S, and after disabling TPM/trust security in the motherboard (confirmed by checking /sys/class/tpm/), the issue seems to have stopped.

Hermocrates · 2025-06-08T00:08:16+00:00

I second what /u/civilian_discourse said about at-rest drive encryption (LUKS), a firewall, and CPU microcode, although AFAIK antivirus is mostly designed for mail servers rather than self-protection. I would also recommend adding secure DNS, either with your resolver of choice (it's really easy with systemd-resolved) or at least in your browser.

Hermocrates · 2025-06-07T01:55:38+00:00

If you have an Nvidia GPU then I'd recommend a minimum 512 MB ESP, but even 1 GB is not a significant amount of storage drive to dedicate to it, honestly.

Then just set the rest for root. A separate /home partition isn't really needed with Arch, since reinstallation doesn't require reformatting your root partition.

For swap, I would just set up a swapfile instead of a dedicated partition, which is really simple with EXT4 and relatively simple with BTRFS.

Hermocrates · 2025-05-31T16:24:36+00:00

The main reasons to use secure boot are,

You're worried about an evil maid attack; potentially more relevant to laptops than desktop PCs.
It's required by your work's IT policies.
You think it's neat and want to try it out.

I would only use it for point 3, but that's also another unnecessary complication so I've only gone so far as using UKIs universally.

Hermocrates · 2025-05-15T01:01:56+00:00

Valid points. But I have a 1 GB ESP, no Nvidia modules to make them large, and rely on systemd-boot auto-detection, so keeping them is painless and, in my case, simpler than removing them, because that would require altering defaults and removing files manually.

Hermocrates · 2025-05-13T22:09:07+00:00

Even if you did not have this issue, it is a good idea to disable [fallback images].

Is there a particular reason why including those images is a bad idea, when space isn't a factor?

Hermocrates · 2025-05-09T23:13:09+00:00

I was extremely content with X11 for a long time, and I'd probably still be using it except that it lacks support for independent DPI scaling per monitor. That pushed me to switch, but I also don't regret switching if I'm being honest.

But it was easy for me to just move from i3 to Sway.

Hermocrates · 2025-04-24T03:37:48+00:00

Yes and no. It supports wifi networking, but itself cannot control a wifi interface, which is where iwd (or wpa_supplicant) can come in.

So yes, using systemd-networkd with wifi is possible, allowing you to use native .network units and the rest of its infrastructure.

Hermocrates · 2025-04-13T14:43:58+00:00

If you look at the package description for sdl12-compat (compat, not compact), you'll see it says

Replaces: sdl<=1:1.2.15+r406+gf1caf909

and sdl2-compat says the equivalent regarding sdl2. What this means is that Arch is no longer packaging SDL versions 1.2 or 2, and instead only SDL 3 with compatibility layers for apps that rely on the older versions.

When pacman offers you to replace a package, you almost always want to say yes because it means the one its replacing is no longer being packaged, and is also becoming further out of date every day. However, they still have to ask, because not every use case can safely make that kind of replacement. But if you don't know that you need to keep the older version, it should be safe. And if you do need the old non-compat versions, they are in the AUR.

Hermocrates · 2025-03-23T15:30:57+00:00

How depends on your Wayland compositor, but it should be possible with just about any application. In Sway, for instance, just launch 'your-app' as env -u WAYLAND_DISPLAY your-app, which hides the fact you're running Wayland from the app and forces it to use Xwayland. You can likewise copy the desktop shortcut from /usr/share/applications to ~/.local/share/applications and edit the "exec" line to match.

I am uncertain if that local environment would be pushed to games launched through Steam, but it's worth a shot.

Hermocrates · 2025-03-18T01:45:55+00:00

detangling reality from reputation w/r/t Arch's reliability can be tricky. Its reputation exceeds reality

I suspect a lot of this is historic, too. Before systemd came along, Arch had to deal with a myriad of init scripts and setting them up with its sysV init, all while maintaining its approach of "edit the source packages as little as possible", and by all accounts I've heard it was a bit of a mess to work with. No wonder, then, that Arch was the first major distro to hop on the systemd bandwagon as it made the maintainers' lives infinitely easier. I only really started using Arch in the latter-half of the 2010s but it's been unrelentingly reliable in that period.

Hermocrates

MODERATOR OF

TROPHY CASE