FS#73043 - Keep /lib/modules/ subdirectory for running kernel until reboot when upgrading kernel

Attached to Project: Arch Linux
Opened by Eduardo (ecruz) - Wednesday, 15 December 2021, 21:56 GMT
Last edited by Antonio Rojas (arojas) - Thursday, 16 December 2021, 07:19 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
When a "linux" kernel package upgrade is performed via pacman, the "/lib/modules/5.15.8-arch1-1" directory for the running kernel is deleted, and another modules subdirectory is created for the new upgraded kernel version.
This is problematic because we are left with an unstable system until reboot. Modules that are already loaded into memory works fine, but if an attempt is made to load a previously unloaded module, it will fail because the files containing the desired module no longer exist. This is not always obvious to the user, error messages may vary from application to application.

If we plug in a new device (USB pendrive, webcam, gamepad) while in this upgraded-but-not-yet-rebooted state, it will most certainly fail.

I think the running kernel's module directory should remain there while that kernel is still running and should be scheduled for deletion only after a reboot.

Additional info:
I'm currently on linux 5.15.8.arch1-1

Steps to reproduce:
1 - Wait for an upgrade to "linux" package to be available.
2 - Upgrade your kernel, pacman -Syu
3 - Take note of your running kernel version, uname -r
4 - $ ls /lib/modules
5 - Realize there is no subdirectory for the running kernel. There is only the upgraded kernel subdirectory, which will only run after a reboot
6 - Plug in a USB pendrive
7 - Realize you can't mount it (unless you had successfully mounted it before the upgrade on the same boot)
This task depends upon

Closed by  Antonio Rojas (arojas)
Thursday, 16 December 2021, 07:19 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#16702 
Comment by Magnus Boman (katt) - Thursday, 16 December 2021, 00:11 GMT Comment by Eduardo (ecruz) - Thursday, 16 December 2021, 03:43 GMT
Hi, thanks for pointing that out! Even though that should fix it for me, it is a workaround: users shouldn’t have to go through the process of experiencing the problem and then research for a solution and hopefully find that package and install it to fix it. It should just work by default. I'm not aiming to solve only my own use case, I really wish to improve Arch usability in general with my bug report. So I think that behavior should belong to the “linux” package, or maybe that package should be adopted into the “base” package group... I don’t know. Some transparent solution must be achieved in order to have a more stable and usable operating system out of the box,

Loading...