From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Description of problem: When I run 'up2date -uf' so it installs the kernel patch it installs it find, but when I reboot it not longer loads just hangs. I ran this on a server a while back and it worked fine (same kernel patch number). I then took that server, formated the harddrive and installed everything from scratch as it was not going to be a dedicated firewall. The only thing changed in the server is I took out 1x3com NIC and replaced it with 3xeepro100 NIC. I ran this on a seperate new server about a month ago and it took that patch fine. I just bought a brand new system and over the past couple days it will not accept this patch. It doesn't mess up lilo.conf as everything works okay. The only setting I have in the lilo.conf that I have changed is in the global section that says vga="795". This was the same on all of the servers that I've done this patch too where when it was done at least a couple weeks ago they worked. Any attempts since then do not work. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Run 'up2date -u' getting all patches but kernel (as they are in skip list) 2.reboot system (optional) 3.run 'up2date -uf' to get kernel updates 4.reboot system and let it default to new kernel (or select new kernel) Actual Results: kernel loads (the message with the expanding ...'s looks normal) and then it says kernel uncompressed, booting kernel and then: 1...if I have the line vga="795" in lili.conf the screen goes blank (as it changes to vga mode) and then system hangs with no hdd activity. 2...if I remove vga="795" from lilo.conf the system just hangs (screen doesn't change to vga mode obviously). Expected Results: It should of (either in VGA mode or not) started to show the text that is normal while booting showing hard drive mounts, dameons started etc. Additional info: Just the fact that when I ran this patch at least two weeks ago it ran fine. But on systems now it will not run (most importantly that one of which is the same server that I ran it on before and now it does not work - the only thing changed on that server was the NIC cards from a 3com to eepro100 cards) This patch is listed as highly recommended in your errata thus I feel it's important to have it work again. (Maybe your file got compramized or something as it worked before).
Hmm, very odd. It sounds like that system might actually be having problems with the new kernel, since it seems like it is loading the new kernel. I assume the old kernel still works? Which version of the kernel is it that is causing problems?
The new kernel is: 2.4.9-31 the previous one is 2.4.7-10 The old kernel still works. And what is odd is the system that refused to run with it this time worked a few weeks ago when I tried it. But I redid system since then. I have another machine running fine with it but it was upraded a few weeks ago. This is very odd. The only thing I can think of is I have different NIC cards (eepro100 now). And I also am installing less as this server will be out on a DMZ network.
Havent ever seen other reports like this, so I'm going to assume it's a kernel issue with that particular hardware.
An update since I first reported this bug. I bought 3 new servers of the exact same hardware (Asus P4B, P4/1.8Ghz 512k, ATI Rage 128, 2xMaxtor HDD,2xIntel Etherpro100 NIC, 1GB ECC 133MHz SDRAM). I ran the installations exactly the same, (same partitions, same packages, only the IP addresses were different). Again when I ran up2date -uf to get the updated kernel one servers would not boot on the new kernel, one would but wouldn't let me add the vga=795 option and the other booted perfectly. Redhat 7.3 was out at that time so I erased everything and started from scratch with a brand new installation (not upgrade). These went fine when I upgraded the kernel...no problems. I never did find out why 7.2 gave me the grief it did with kernel updates.