I do not like the frequency of reboots necessitated by kernel upgrades. I know that I could mask it, but IME that eventually causes problems with packages than make .ko kernel modules; it’s just more things to fail, and it makes me really wish Linus would have just based Linux on MINIX.
Here’s a tip that you might not be aware of: Arch has an LTS kernel. It may seem counter intuitive to run Arch and not have the latest, bleeding edge kernel, but the upside is that you get a stabler, less breakage-prone system.
I didn’t know about the LTS kernel. How does that interact with module packages, like the fscking Broadcom support packages, or bcachesfs (before it for mainlined)? That’s where I’ve historically run into issues with pinning the kernel.
I will absolutely look into this, though. If it prevents the “you need to reboot or else” messages after every Syu, I’m in. On Arch, when you get a message like that, it’s best heeded.
Another pro tip: You don’t need to update Arch every day.
I update about once a month. Just make sure you read the news and deal with your .pacnew files.
I’ve gone months between updates. On servers, that’s a little more risky because it CVEs, which can also apply to the kernel, but LTS is probably safe enough there: if there’s a kernel CVE, LTS will be updated.
I’ve had trouble with pinning the kernel before, though. Last time I did it, I went several months and forgotten I’d done it, and my system got itself wedged because some package was expecting a newer kernel; it took me a while to figure out.
LTS might be a better option, since that will be caught be dependency management. Pinning can cause version dependency mismatch issues.
I’ve never had to deal with Broadcom drivers or pinned the kernel, so I can’t tell you anything about that. The LTS kernel (currently 6.6.32-1) still updates regularly, albeit not nearly as often as the stock Arch kernel, so that means fewer updates that require a reboot.
Just install linux-lts and linux-lts-headers via pacman, and you’re good to go.
Here’s a tip that you might not be aware of: Arch has an LTS kernel. It may seem counter intuitive to run Arch and not have the latest, bleeding edge kernel, but the upside is that you get a stabler, less breakage-prone system.
I didn’t know about the LTS kernel. How does that interact with module packages, like the fscking Broadcom support packages, or bcachesfs (before it for mainlined)? That’s where I’ve historically run into issues with pinning the kernel.
I will absolutely look into this, though. If it prevents the “you need to reboot or else” messages after every Syu, I’m in. On Arch, when you get a message like that, it’s best heeded.
Another pro tip: You don’t need to update Arch every day.
I update about once a month. Just make sure you read the news and deal with your .pacnew files.
I’ve gone months between updates. On servers, that’s a little more risky because it CVEs, which can also apply to the kernel, but LTS is probably safe enough there: if there’s a kernel CVE, LTS will be updated.
I’ve had trouble with pinning the kernel before, though. Last time I did it, I went several months and forgotten I’d done it, and my system got itself wedged because some package was expecting a newer kernel; it took me a while to figure out.
LTS might be a better option, since that will be caught be dependency management. Pinning can cause version dependency mismatch issues.
I’ve never had to deal with Broadcom drivers or pinned the kernel, so I can’t tell you anything about that. The LTS kernel (currently 6.6.32-1) still updates regularly, albeit not nearly as often as the stock Arch kernel, so that means fewer updates that require a reboot.
Just install
linux-ltsandlinux-lts-headersvia pacman, and you’re good to go.