I guess this happend due to the urpmi bug: run-parts: /etc/cron.weekly/remove-old-kernels.cron exited with return code 1 $uname -a Linux vvv 6.6.14-server-2.mga9 #1 SMP PREEMPT_DYNAMIC Tue Jan 30 16:12:58 UTC 2024 x86_64 GNU/Linux $ls -1 /boot/vm* /boot/vmlinuz@ /boot/vmlinuz-6.6.22-server-1.mga9 /boot/vmlinuz-6.6.28-server-1.mga9 /boot/vmlinuz-server@
> I guess this happend due to the urpmi bug Do you mean Bug 31799 - urpme --auto-orphans would remove the current kernel if a newer is installed CC remove-old-kernels maintainer
CC: (none) => fri, zen25000
I don't see how it could. remove-old-kernels gets the current running kernel version and specifically excludes it. Was this during an automated cleanup? If so what is in the rok log? rok -l
thanks for rok - didn't know this. Looks like auto-orphans has removed the running kernel :(
So the culprit was not remove-old-kernels, but urpme --auto-orphans. Was a newer one installed? Comment 1 looks right. This bug is probabaly a duplicate of Bug 31799.
CC: (none) => lewyssmith
Moreover, remove-old-kernels (rok) when run, would exit with a FATAL error message if it detected that the running kernel had been removed during the current session by another utility since last boot. Was urpme --auto orphans run manually at some point? rok does not invoke it.
that is, how I found the problem.
So it looks as if this comes from 'urpme --auto orphans', and bug 31799 looks relevant. But you do need to say whether when you ran 'urpme --auto orphans', and it removed the running kernel, there was a more recent kernel installed - which is the key to that other bug.
Looks like this is the case. *** This bug has been marked as a duplicate of bug 31799 ***
Status: NEW => RESOLVEDResolution: (none) => DUPLICATE