I'm still bothered by Arch kernel upgrades removing the modules of the currently running version, so you're often forced into rebooting.

It would be handy if the upgrade generates a fallback image of the current kernel and its modules.

Someone must have already started working on that... right?

Well its the only reason to do a reboot, so i kinda like to be forced from time to time... ;)

@fribbledom If you use btrfs, you can add a hook that links the current version from a snapshot so that on update it happens automatically.

My personal strategy is to update at the end of my day, after which the system powers off for five minutes and turns itself back on (broken hardware, reboot always fails). Then I’m never in-between. But I also keep a local mirror of Arch so that I can guarantee that the update happens despite walking away from the system.

Wait, you're saying that while running kernel-X.Y.Z, an update installs kernel-X.Y.(Z+1) and removes or otherwise modifies modules for kernel-X.Y.Z? If so, that's... Just broken.


Indeed, it upgrades the package, which removes /lib/modules/X.Y.Z from the filesystem and installs /lib/modules/X.Y.(Z+1) instead.

Other distros solve that by offering a fallback package, but obviously it's a bit harder with rolling releases.

I think most other distros handle this by, you know, not deleting parts of the running kernel. You're required to do an autoclean or something after a reboot. That then removes unneeded stuff (not just kernels). But until you do that, the old packages just stay there. Potentially forever, or until you do a full system upgrade to a newer OS version. This is true of deb and rpm based distros.

I'm still having trouble wrapping my head around this.

Not all packages, of course. Just kernels and other critical packages.

@adz @fribbledom in Debian and Ubuntu, the kernel (linux-image) is just an empty metapackage, which points to the latest kernel package, each being a different package. Arch just uses the same linux package with different version numbers.

It's a simpler approach from the distributor's PoV. The philosophy of Arch is a bit misunderstood - minimalism means simplicity for the maintainer.

It's the deleting of running-kernel modules that was spinning me out. Not the naming scheme or meta-packages.

@adz @fribbledom It doesn't explicitly delete, just overwrites with the new one. Since the kernel modules aren't guaranteed to be compatible with a different kernel version, it will refuse to load the new modules to the still running kernel.

I think the only issue with this approach is that the behavior isn't very obvious. You might wonder why some hardware suddenly doesn't work, and unless you look into dmesg, you might not realize you only need a reboot.

@uint8_t @adz

You could manually try and load a newer module with insmod/modprobe, but it wouldn't actually automatically load them, as it tries to find them in a non-existing directory, as the version is part of the path name, e.g. /lib/modules/5.1.6-arch1-1-ARCH

@adz @fribbledom Actually, apt and dnf based distributions retain the previous kernel package, so you have NOW and NOW-1 installed.

Removal of a package should always remove the package’s files. Otherwise the behavior is surprising and inconsistent.

Doesn’t bother me anyway: the first thing that happens after I update the kernel is start using it.

Yes, that's what I'm talking about. My head is exploding that this isn't what Arch does.

@adz @fribbledom It can be setup that way, but I honestly prefer it this way: my pre-upgrade snapshot will have the currently running kernel’s modules if I need them for some esoteric reason. That’s good separation of concerns, is what that is.

@SuperFloppies I agree with your preference. However, the fact that the other way is even an option (and appears to be the default). What possible benefit would it serve? To (temporarily) reduce hard disk usage by a couple of hundred megs? What if the new kernel doesn't boot for whatever reason? @fribbledom

I've been subscribed to the "versioned kernel packages" bug for a couple years now. They've halfway agreed to a couple different interim solutions but I can't tell if anyone is actually working on anything. Gonna try MX Linux on my wife's old Surface and if I like it and it supports ZFS I'll probably dump Arch, 50% because of this.

Frankly not being Debian is a huge handicap for a distro.

@fribbledom never had that happen to me. Probably i run so basic hardware that i require nothing special

@fribbledom You are supposed to add a hook that pacman runs on a new kernel image to add the extra modules on install. I had to do it with Nvidia drivers.

@fribbledom nothing like needing to reboot randomly at work to attract my office mates to linux

@fribbledom yeah manjaro has a pacman hook for this

you can steal it from their gitlab

@fribbledom I've never trusted the distro to supply a working kernel.


I think I gave up compiling my own kernels sometime around 2005 😂

@fribbledom @mansr crux is nice in that it's just your responsibility to handle downloading newer kernels, compiling them, and installing them

it's not managed by the package manager whatsoever
@fribbledom @mansr it's also, unsurprisingly, the only distro I've ever managed to get EFISTUB to work on

@pea @fribbledom Gentoo can easily be told to leave the kernel alone. As for EFI, all my PCs predate that nightmare.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!