FS#23809 - [pacman][kernel26] Do not remove modules of uninstalled kernel before reboot
Attached to Project:
Arch Linux
Opened by Tomas Mudrunka (harvie) - Sunday, 17 April 2011, 16:18 GMT
Last edited by Tom Gundersen (tomegun) - Saturday, 18 June 2011, 20:56 GMT
Opened by Tomas Mudrunka (harvie) - Sunday, 17 April 2011, 16:18 GMT
Last edited by Tom Gundersen (tomegun) - Saturday, 18 June 2011, 20:56 GMT
|
Details
Description:
When i upgrade kernel, i can't load new modules till the reboot I can imagine moving of old modules to /tmp or /dev/shm (and making symlink to it) - dead symlinks in /lib/modules can be removed during boot. maybe we can add some halt-time and boot-time hooks for pacman (similar to .install scripts in packages but executed later during (re)boot) Steps to reproduce: 1.) boot 2.) update kernel to newer version 3.) try to modprobe some module that is not in kernel yet |
This task depends upon
Closed by Tom Gundersen (tomegun)
Saturday, 18 June 2011, 20:56 GMT
Reason for closing: Won't fix
Additional comments about closing: tpowa, brain0: reopen if you disagree.
Saturday, 18 June 2011, 20:56 GMT
Reason for closing: Won't fix
Additional comments about closing: tpowa, brain0: reopen if you disagree.
I want it to manage packages in smart way
> If your feature request is to have parallel installable kernel versions (which is perfectly legitimate)
Why should i need such thing? I just want to be able to use my system in it's full power even between kernel upgrade and reboot. Sometimes i just can't reboot, but i accidentally upgrade kernel with other packages without proper modules loaded and then i can't use those modules till the reboot (i don't want to add kernel to IgnorePkg). Modules are part of a kernel and so we should keep them while the old kernel is (booted) in memory.
It can screw with your head sometimes. eg.: i've been trying to mount remote NFS after kernel upgrade (without nfs module loaded) and mount said something like "device unavailable" or "access denied" (i can't remember). i was checking, fixing and restarting the remote server for 15 minutes till i've found that i just don't have module and it can't be loaded automaticaly by mount.nfs
Parallel installation of multiple kernel versions is a common way of dealing with the problem you describe (like they do at Debian's). You are really not expected to upgrade the kernel if you are not going to reboot the system.
-1 from me as well.
for example:
pre_install() {
test -L /lib/modules/$pkgversion-ARCH && rm /lib/modules/$pkgversion-ARCH
}
pre_remove() {
mkdir -p /dev/shm/lib/modules/
cp -rf /lib/modules/$pkgversion-ARCH /dev/shm/lib/modules/
}
post_remove() {
ln -s /dev/shm/lib/modules/$pkgversion-ARCH /lib/modules/
}
or we can implement some (eg.) /tmp/delete_on_boot directory which will get deleted by init each time to fix cases where /dev/shm is not ramdisk
If you upgrade a program that is running, and it is not able to re-execute itself, weird things might happen. The kernel is one such program, but I'm sure there are others (I seem to remember that upgrading KDE causes "everything" to crash). I think the only sensible solution is to not do an upgrade if you are not prepared to reboot.
(Stuff like udev and dbus might be able to elegantly reexecute themselves, so a reboot is not necessary, but others will not.)