You are not logged in.
I regularly run into a situation where pacman has updated my kernel and removed the kernel modules for my currently running kernel. Obviously this leads to confusing and undesirable behavior on my system until I reboot.
Would I have had to have done something to cause this behavior?
In either case, how do I stop this?
Is this caused by a configurable pacman hook?
I also have a seemingly related issue where when I reboot after pacman has updated the kernel, the kernel modules directory will be missing and boot will fail. If I then boot from a live media, arch-chroot, and run a pacman -Syyu, it will fix the problem, so it seems like my pacman hooks can at least fix the problems they cause. I'm hoping these are actually the same problem, but if not let's keep this thread on the topic of pacman removing kernel modules for a running kernel.
Last edited by khouli (2017-12-25 22:34:39)
Offline
I cannot really recommend any automated way to do this. It is not a matter in which running loaded modules are unloaded; rather it is a situation where if the kernel needs to load new modules, they are not available. In my case, I always check the packages to be installed and apply special care if it involves the kernel.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
after pacman has updated the kernel, the kernel modules directory will be missing and boot will fail
This usually means you forgot to mount the boot partition before the update and are still booting an old kernel.
As ewaller mentiond, the other condition is only a problem if you need to load re-modules (eg. when attaching new devices/filesystems), it has no impact on a static HW setup.
You could chattr the "old" module path immuatble or move away the modules around the update, but if you don't remember to tidy up after a reboot, you'll end up cluttering your system.
Offline
I also have a seemingly related issue where when I reboot after pacman has updated the kernel, the kernel modules directory will be missing and boot will fail.
Your /boot is not mounted when the upgrade is run.
Offline
It sounds like the boot partition is mounted when the update is performed, because things are normal after a reboot. I assume the 'problem' is that, after a kernel update and prior to rebooting, the kernel cannot load any additional modules; for example if a USB to serial converter were plugged in, the driver would not (could not) load.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
1) https://bugs.archlinux.org/task/16702
2) as mentioned above. If your bootloader expects to see the kernel located on the ESP, and therefore the ESP was mounted to /boot, then failure to keep it mounted via e.g. fstab or systemd's automounting *will* cause you to boot the old kernel after a pacman update extracts the new kernel and modules to your / partition...
Do you have the ESP configured with noauto in your fstab? If so that is tragically wrong.
Last edited by eschwartz (2017-12-25 20:35:20)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Thanks folks. I didn't realize the first issue was just the regular behavior of pacman when updating a package. It's obvious now, but since this was a kernel problem I guess my brain immediately jumped to thinking this must be some special and unusual pacman behavior. I understand what's going on now and how I can deal with it. I'll probably use seth's suggestion to prevent old modules from being deleted and also set up a systemd unit to either clean them up later or remind me to do so.
I don't quite have a grasp on the second problem yet but the fact that it's probably something to do with how I have my boot partition mounted is a good hint. I don't have noauto anywhere in my fstab but there's a good chance my fstab has some other problem. I'll post a second thread with an appropriate title for that problem if I can't figure it out.
Last edited by khouli (2017-12-26 01:11:57)
Offline
I regularly run into a situation where pacman has updated my kernel and removed the kernel modules for my currently running kernel. Obviously this leads to confusing and undesirable behavior on my system until I reboot.
A kernel update should rebuild the initramfs, that is very obvious in your pacman output. Always be prepared to doo a reboot if you start an upgrade and if the kernel is included, do it directly afterwards. You could add a hook that displays a message if the currently running kernel has been upgraded, but i don't think that adds much value for a single kernel. It helps if you are using multiple kernels, though.
https://bbs.archlinux.org/viewtopic.php … 0#p1699380
In order to prevent kernel updates with a missing boot partition, you can create a pacman hook that checks if your boot partition is mounted and aborts if it is missing. You could also build a hook that mounts /boot if required. Useful documentation would be hooks in /usr/share/libalpm/hooks/, the manpage "alpm-hooks" (especially AbortOnFail), and the manpage for "mountpoint".
Last edited by progandy (2017-12-25 22:46:45)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
A kernel update should rebuild the initramfs, that is very obvious in your pacman output.
I admit I haven't read all the docs I should have, but if you really are curious about why this isn't obvious to a newbie then the answer is simply that sometimes we run a pacman -Syyu and there's a flood of text that seems innocuous and run of the mill, sometimes we have a pacman -Syyu on a timer which means we don't even see the pacman output and we misguidedly expect that it won't break our system, and in the specific case of pacman removing kernel modules, sometimes the symptoms don't manifest until long after the cause which is confusing for anyone.
Offline
I admit I haven't read all the docs I should have, but if you really are curious about why this isn't obvious to a newbie then the answer is simply that sometimes we run a pacman -Syyu and there's a flood of text that seems innocuous and run of the mill
Generally speaking, Arch users should strive to read that "flood of text", as significant thought has gone into designing a package manager that avoids useless diagnostic messages.
pacman's output is cleanly divided into downloading packages, running PreTransaction hooks, installing packages, and running PostTransaction hooks. Each action is just one teeny little line, and the output of hooks and post_install scripts will very much stand out. I don't think it is unreasonable to keep an eye on that.
sometimes we have a pacman -Syyu on a timer which means we don't even see the pacman output and we misguidedly expect that it won't break our system
At this point, you might as well be running Manjaro. Arch is not made with this in mind, and anyone foolish enough to run pacman -Syu on a timer deserves everything they have coming to them.
and in the specific case of pacman removing kernel modules, sometimes the symptoms don't manifest until long after the cause which is confusing for anyone.
The symptoms have the same meaning no matter when you see them, and the meaning is fairly unambiguous.
...
Aside: who told you the terrible advice to use a double -yy when running pacman -Syu?
Look at the manpage -- that option is specifically to ignore the date of locally downloaded sync databases and always download new ones regardless of whether there are legitimate updates or not. It's meant for when you e.g. switch to a historic repository snapshot at https://archive.archlinux.org, or when you are switching away from a mirror that is so broken it manages to totally corrupt the timestamps of all the mirrored files, or when you accidentally -Syu into some wifi network's captive portal and download dynamically generated HTML login splash pages instead of tarballed sync databases.
In the common case, the only thing -Syyu will do is waste the server bandwidth, and slow down your own updates by a few seconds too.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
At this point, you might as well be running Manjaro. Arch is not made with this in mind, and anyone foolish enough to run pacman -Syu on a timer deserves everything they have coming to them.
I understand why it's frowned upon but I don't think it's unreasonable if you know doing so will occasionally break things and you're willing to live with that. I wouldn't do this on a box where "surprise learning opportunities" were unacceptable. If I could in fact switch to a distro that was 100% identical to Arch but with automatic updates in mind, I guess I would, but Manjaro isn't that. :-P
I'll keep this in mind though and maybe switch to a timer that reminds me to update packages or at least restrict which packages I automatically update.
Aside: who told you the terrible advice to use a double -yy when running pacman -Syu?
Good question! This has been a habit for a while and I can't remember where it started. Thanks for pointing this out!
Offline
I understand why it's frowned upon but I don't think it's unreasonable if you know doing so will occasionally break things and you're willing to live with that. I wouldn't do this on a box where "surprise learning opportunities" were unacceptable. If I could in fact switch to a distro that was 100% identical to Arch but with automatic updates in mind, I guess I would, but Manjaro isn't that. :-P
In that case, 1) you are not a newbie, and 2) you're hopefully knowledgeable enough to be able to debug this yourself without posting support threads...
I'll keep this in mind though and maybe switch to a timer that reminds me to update packages or at least restrict which packages I automatically update.
Please do.
Aside: who told you the terrible advice to use a double -yy when running pacman -Syu?
Good question! This has been a habit for a while and I can't remember where it started. Thanks for pointing this out!
Dang! Foiled again.
This seems to be common advice somehow, but nobody has ever been able to tell me who first started spreading it so I can call them out for it. ![]()
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline