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): kernel-smp-2.4.22-1.2174 How reproducible: happened twice Steps to Reproduce: 1. set up a cron job with /usr/sbin/up2date -u 2. 3. Actual results: Most updates are done successfully, but when kernel-smp is involved, the system will freeze. Expected results: kernel-smp is updated Additional info: 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: ... Installing /var/spool/up2date/kernel-smtp-2.4.22-1.2174.nptl.i686.rpm 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 viable option. 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 in /boot/grub/grub.conf. 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.