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.
@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.
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.
@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 😂
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!