Description of problem:
The system is frozen when up2date is launched from a cron job.
It is later found that the kernel-2.4.22-1.2174.nptl was
successfully mounted, but not kernel-smp-2.22-1.2174.nptl.
Version-Release number of selected component (if applicable):
How reproducible: happened twice
Steps to Reproduce:
1. set up a cron job with /usr/sbin/up2date -u
Actual results: Most updates are done successfully, but
when kernel-smp is involved, the system will freeze.
Expected results: kernel-smp is updated
We use up2date to keep our FC1 box updated every day in a cron job.
Most often, the job completes successfully without trouble.
But when kernel-smp is involved, somehow the system will get locked up
and no activity will be allowed.
The cron job log will show:
and stops there.
The /var/log/up2date.1 will show
[Sat Feb 21 04:16:50 2004] up2date Creating rollback packages...
and stops there too.
It is noted that the kernel (kernel-2.4.22-1.2174) is successfully
updated on the system and reflected in /boot/grub/grub.conf as an
However, there is no such option for kernel-smp-2.4.22-1.2174.
Also, there is no /boot/initrd-2.4.22-1.2174.nptlsmp.img produced.
Under /var/spool/up2date, the kernel-smp-2.4.22-1.2174.nptl.i686.rpm
is successfully fetched.
Indeed, I can get the problem by forcing a rpm update:
rpm -force -Uvh kernel-smp-2.4.22-1.2174.nptl.i686.rpm
and the kit is successfully installed and reflected as a valid option
Hence, I suspect there is a bug here with up2date when handling
kenerl-smp update. I rank this as high priority as the system
is unusable when the problem strikes.
*** Bug 116600 has been marked as a duplicate of this bug. ***
Interesting. Off hand, I have no idea what would cause kernel-smp
to fail when kernel works fine. up2date handles them the same
(and all packages that "provide: kernel" for that matter).
It could be boot loader related, but it doesnt sound like it.
That generally would throw a traceback and a big error.
If you have "rollback" enabled, that might be an issue, since
thats a less tread code path. Can you duplicate this behaviour
with rollback disabled?
I've seen this as well. I think it's another case of Bug 109962 where
the smp kernel will hang when doing a umount.
Part of the kernel updating involves creating an initrd. This means
creating a small filesystem, loop-back mounting this filesystem, then
umounting this filesystem. In the above bug, the SMP kernel has been
shown to hang when doing a umount.
This should be fixed in the latest FC1 SMP kernel.