your own personal kernel command line parameter

Another day, another Nvidia issue. More specifically, the latest version of mesa (25.1.1) has updated and the poor souls who own Nvidia cards running with nouveau experience a full system freeze on X startup.

This is not that rare. In the many years I've been running Arch Linux, almost every single issue after an upgrade has been in some way or another linked to the stupid mistake I made when I purchased an Nvidia graphics card. Unfortunately, back then I didn't know about Nvidia's reputation with Linux, and I've been paying the price ever since.

Anyway.

I don't bother with a display manager, as it's just another piece of software I don't need. I generally always want to boot straight into X, so I simply call startx in .profile:

if [[ ! $TMUX && ! $DISPLAY && ! $SSH_CONNECTION && $XDG_VTNR -eq 1 ]] && which startx &>/dev/null; then
    exec startx
fi

These conditions ensure that

• we're not in tmux
• X isn't running ($DISPLAY is empty)
• this isn't an ssh connection
• the current tty is 1
• startx actually exists

This has worked fine forever, but the aforementioned X crash resulted in a completely unusable system, requiring a reboot. Of course, that's not a big deal: I can boot into archiso from a pen drive, mount my disks, arch-chroot back in, and fix it¹.

The part that was most annoying was that I could have fixed this without booting from the iso, if only I had some way of preventing the automatic running of startx. As you can see in the snippet, I have no way of (even temporarily) disabling it, and that's what I want to fix.

So, what do I have control over before my system boots? In reality, not very much, leaving only one obvious solution for this. It was already spoiled in the title of this post: I can make changes to the kernel command line from the boot menu, so I'll create my own parameter.

Not much is involved in "creating" one, since the kernel and system will just ignore any it doesn't recognise. You just start using the one you want and make the software on the other end read the value and act upon it. The responsibility falls on the user to pick one that doesn't conflict with any others, lest they discover unforeseen side effects.

Since absolutely anyone (and their dog) can invent their own, there is no exhaustive list. The kernel documentation lists all the official ones, and well-behaved software normally namespaces their own, like systemd and the systemd. prefix.

Let's go with xorg.disable=1.

The currently booted kernel command line can be obtained by reading the virtual file /proc/cmdline. There's no need to do any clever parsing, as X is enabled by default and detecting the presence of xorg.disable=1 (as a whole) is all that's needed. Using a regex with word boundaries (\b) guarantees a precise match.

grep -q '\bxorg\.disable=1\b' /proc/cmdline || exec startx

Now I can simply edit the kernel command line in the boot menu and add xorg.disable=1 to boot up without X and diagnose the issue, without having to get out that dusty archiso pen drive.

But I'm sure this'll be the last time it happens, right?

Right?