Hi List, I am running a 64 bit 5.3 kernel on an intel mb and all has been well. Today I thought it would be okay to reboot so that the latest kernel was running - i.e move from 128.2.1 to 128.4.1 release. The system passes POST fine, grub passes control to the 128.4.1 kernel and the boot process is under way. after some 30 secs the system starts beeping - continuously. After I hooked up a monitor I find that udev does not come up with OK and thats when the system starts the beep beep beep ...... No logs to see ...... using grub to select 128.2.1 boot fine Any ideas? Thanks in advance for your words of wisdom and advice. Rob
Rob Kampen wrote:
Hi List, I am running a 64 bit 5.3 kernel on an intel mb and all has been well. Today I thought it would be okay to reboot so that the latest kernel was running - i.e move from 128.2.1 to 128.4.1 release. The system passes POST fine, grub passes control to the 128.4.1 kernel and the boot process is under way. after some 30 secs the system starts beeping - continuously. After I hooked up a monitor I find that udev does not come up with OK and thats when the system starts the beep beep beep ...... No logs to see ...... using grub to select 128.2.1 boot fine Any ideas? Thanks in advance for your words of wisdom and advice. Rob _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Still no joy with the latest kernel - fails at initialization of udevd with beep beep beep ....... I have tried a new version of the rr174x raid controller device driver, new make and make install but still the same issue. Not sure if this module is looked at by udev or not - I'm way out of my depth here.
Currently server is functioning fine on Linux obfuscated.example.com 2.6.18-128.2.1.el5 #1 SMP Tue Jul 14 06:36:37 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux but I'm perturbed why a simple update of the kernel kills my server - not what I expected from CentOS / RHEL. What tests / things should I check? I see no files in /etc with dates after Jul 21 (date I installed 128.2.1 kernel) that appear to contain any device related changes Any help appreciated. Rob
On Thu, Aug 20, 2009 at 10:41:55PM -0400, Rob Kampen wrote:
Rob Kampen wrote:
Hi List, I am running a 64 bit 5.3 kernel on an intel mb and all has been well. Today I thought it would be okay to reboot so that the latest kernel was running - i.e move from 128.2.1 to 128.4.1 release. The system passes POST fine, grub passes control to the 128.4.1 kernel and the boot process is under way. after some 30 secs the system starts beeping - continuously. After I hooked up a monitor I find that udev does not come up with OK and thats when the system starts the beep beep beep ......
...
Still no joy with the latest kernel - fails at initialization of udevd with beep beep beep ....... I have tried a new version of the rr174x raid controller device driver, new make and make install but still the same issue. Not sure if this module is looked at by udev or not - I'm way out of my depth here.
Currently server is functioning fine on Linux obfuscated.example.com 2.6.18-128.2.1.el5 #1 SMP Tue Jul 14 06:36:37 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux but I'm perturbed why a simple update of the kernel kills my server - not what I expected from CentOS / RHEL. What tests / things should I check? I see no files in /etc with dates after Jul 21 (date I installed 128.2.1 kernel) that appear to contain any device related changes
The changelog from 2.6.18-128.2.1.el5 to 2.6.18-128.4.1.el5:
* Fri Jul 24 2009 Don Howard dhoward@redhat.com [2.6.18-128.4.1.el5] - [fs] ecryptfs: check tag 11 packet literal data buffer size (Eric Sandeen ) [512862 512863] {CVE-2009-2406} - [fs] ecryptfs: check tag 3 packet encrypted key size (Eric Sandeen ) [512886 512887] {CVE-2009-2407} - [misc] personality handling: fix PER_CLEAR_ON_SETID (Vitaly Mayatskikh ) [511173 508842] {CVE-2009-1895} - [xen] HV: remove high latency spin_lock (Chris Lalancette ) [512311 459410]
* Tue Jul 14 2009 Jiri Pirko jpirko@redhat.com [2.6.18-128.3.1.el5] - [pci] quirk: disable MSI on VIA VT3364 chipsets (Dean Nelson ) [507529 501374] - [char] tty: prevent an O_NDELAY writer from blocking (Mauro Carvalho Chehab ) [510239 506806] - [misc] hrtimer: fix a soft lockup (Amerigo Wang ) [418061 418071] {CVE-2007-5966} - [misc] hrtimer: check relative timeouts for overflow (AMEET M. PARANJAPE ) [510018 492230]
Do you see anything relevant to your hardware?
Since you mention that udev has started, we can rule out the kernelbooting/initrd stage.
Tru
Tru Huynh wrote:
On Thu, Aug 20, 2009 at 10:41:55PM -0400, Rob Kampen wrote:
Rob Kampen wrote:
Hi List, I am running a 64 bit 5.3 kernel on an intel mb and all has been well. Today I thought it would be okay to reboot so that the latest kernel was running - i.e move from 128.2.1 to 128.4.1 release. The system passes POST fine, grub passes control to the 128.4.1 kernel and the boot process is under way. after some 30 secs the system starts beeping - continuously. After I hooked up a monitor I find that udev does not come up with OK and thats when the system starts the beep beep beep ......
...
Still no joy with the latest kernel - fails at initialization of udevd with beep beep beep ....... I have tried a new version of the rr174x raid controller device driver, new make and make install but still the same issue. Not sure if this module is looked at by udev or not - I'm way out of my depth here.
Currently server is functioning fine on Linux obfuscated.example.com 2.6.18-128.2.1.el5 #1 SMP Tue Jul 14 06:36:37 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux but I'm perturbed why a simple update of the kernel kills my server - not what I expected from CentOS / RHEL. What tests / things should I check? I see no files in /etc with dates after Jul 21 (date I installed 128.2.1 kernel) that appear to contain any device related changes
The changelog from 2.6.18-128.2.1.el5 to 2.6.18-128.4.1.el5:
- Fri Jul 24 2009 Don Howard dhoward@redhat.com [2.6.18-128.4.1.el5]
- [fs] ecryptfs: check tag 11 packet literal data buffer size (Eric Sandeen ) [512862 512863] {CVE-2009-2406}
- [fs] ecryptfs: check tag 3 packet encrypted key size (Eric Sandeen ) [512886 512887] {CVE-2009-2407}
- [misc] personality handling: fix PER_CLEAR_ON_SETID (Vitaly Mayatskikh ) [511173 508842] {CVE-2009-1895}
- [xen] HV: remove high latency spin_lock (Chris Lalancette ) [512311 459410]
- Tue Jul 14 2009 Jiri Pirko jpirko@redhat.com [2.6.18-128.3.1.el5]
- [pci] quirk: disable MSI on VIA VT3364 chipsets (Dean Nelson ) [507529 501374]
- [char] tty: prevent an O_NDELAY writer from blocking (Mauro Carvalho Chehab ) [510239 506806]
- [misc] hrtimer: fix a soft lockup (Amerigo Wang ) [418061 418071] {CVE-2007-5966}
- [misc] hrtimer: check relative timeouts for overflow (AMEET M. PARANJAPE ) [510018 492230]
Do you see anything relevant to your hardware?
Since you mention that udev has started, we can rule out the kernelbooting/initrd stage.
Tru
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thanks for the changelog Tru - I was looking for this. The mb is Intel S3000AH with I guess intel chipsets and only card is a rocketraid rr174x card running RAID 5 It runs a quad core X3220 Intel Xeon processor. As it is passing POST and kernel 128.2.1 functions fine I have confidence the hw is okay. I do not run encrypted fs nor xen, thus those items should not impact. No idea what personality handling refers to I think the pci VIA chip does not apply as this is an intel mb the [char]tty patch I do not understand that leaves only the [misc] hrtimer - but I'm out of my depth to know if this could apply. looking in dmesg output of 128.2.1 boot the timer lines read:
Calibrating delay using timer specific routine.. 4802.13 BogoMIPS (lpj=2401069) Using local APIC timer interrupts. Detected 16.667 MHz APIC timer. Calibrating delay using timer specific routine.. 4799.55 BogoMIPS (lpj=2399777) Calibrating delay using timer specific routine.. 4799.46 BogoMIPS (lpj=2399733) Calibrating delay using timer specific routine.. 4799.56 BogoMIPS (lpj=2399781) time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. PCI: Setting latency timer of device 0000:00:1c.0 to 64 PCI: Setting latency timer of device 0000:00:1c.4 to 64 PCI: Setting latency timer of device 0000:00:1c.5 to 64 PCI: Setting latency timer of device 0000:00:1e.0 to 64 PCI: Setting latency timer of device 0000:00:1c.0 to 64 PCI: Setting latency timer of device 0000:00:1c.4 to 64 PCI: Setting latency timer of device 0000:00:1c.5 to 64 PCI: Setting latency timer of device 0000:00:1d.7 to 64 PCI: Setting latency timer of device 0000:00:1d.0 to 64 PCI: Setting latency timer of device 0000:00:1d.1 to 64 PCI: Setting latency timer of device 0000:00:1d.2 to 64 PCI: Setting latency timer of device 0000:00:1d.3 to 64 PCI: Setting latency timer of device 0000:00:1f.2 to 64 PCI: Setting latency timer of device 0000:03:00.0 to 64
doesn't appear of much help. As mentioned, I updated to latest rocketraid software just in case this was a problem as the card is a little older, and re did the make and make install, this gives me a new initrd in /boot and I guess must be working as I get past this in the boot process. What's next? How do I get more info about the loading of devd? It does not appear in the normal /etc/init.d/ or /etc/rcX.d/Sxx...... thus I am unsure how it is initiated and looking at RH boot docs last night did not help.
Thanks Rob
Rob Kampen wrote:
I am running a 64 bit 5.3 kernel on an intel mb and all has been well. Today I thought it would be okay to reboot so that the latest kernel was running - i.e move from 128.2.1 to 128.4.1 release. The system passes POST fine, grub passes control to the 128.4.1 kernel and the boot process is under way. after some 30 secs the system starts beeping - continuously. After I hooked up a monitor I find that udev does not come up with OK and thats when the system starts the beep beep beep ...... No logs to see ...... using grub to select 128.2.1 boot fine Any ideas?
I just upgraded the kernel also, and I'm having the same problem (except that my screen goes blank).
I noticed that Interactive mode allows the system to boot.
So, I'm wondering how to revert to the penultimate kernel. I tried to find info - all I got was rpm -e kernel-oldversion Would that make the system drop to the next-to-most-recent?
I saw a few mentions of using grub - but I set the timeout to 0 (but I don't use that screen, so I don't even see it now). If this method is a permanent fix, should I set it so that it comes up on the next boot?
[mykolas@sr1220 ~]$ uname -r 2.6.18-128.4.1.el5 [mykolas@sr1220 ~]$ rpm -q kernel kernel-2.6.18-128.el5 kernel-2.6.18-128.1.16.el5 kernel-2.6.18-128.4.1.el5
Michael Klinosky wrote:
Rob Kampen wrote:
I am running a 64 bit 5.3 kernel on an intel mb and all has been well. Today I thought it would be okay to reboot so that the latest kernel was running - i.e move from 128.2.1 to 128.4.1 release. The system passes POST fine, grub passes control to the 128.4.1 kernel and the boot process is under way. after some 30 secs the system starts beeping - continuously. After I hooked up a monitor I find that udev does not come up with OK and thats when the system starts the beep beep beep ...... No logs to see ...... using grub to select 128.2.1 boot fine Any ideas?
I just upgraded the kernel also, and I'm having the same problem (except that my screen goes blank).
I noticed that Interactive mode allows the system to boot.
So, I'm wondering how to revert to the penultimate kernel. I tried to find info - all I got was rpm -e kernel-oldversion Would that make the system drop to the next-to-most-recent?
I saw a few mentions of using grub - but I set the timeout to 0 (but I don't use that screen, so I don't even see it now). If this method is a permanent fix, should I set it so that it comes up on the next boot?
[mykolas@sr1220 ~]$ uname -r 2.6.18-128.4.1.el5 [mykolas@sr1220 ~]$ rpm -q kernel kernel-2.6.18-128.el5 kernel-2.6.18-128.1.16.el5 kernel-2.6.18-128.4.1.el5
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Michael, My screen goes blank too. It shows that it is starting udev but never comes up with the [OK] - just blanks the screen and beeps..... You may need to edit /boot/grub/grub.conf as root or via sudo and alter timeout or set default=1 or whatever number kernel you want - remember grub counts from 0. I haven't tried interactive - will do that tonight. HTH Rob
Rob Kampen wrote:
Michael Klinosky wrote:
Rob Kampen wrote:
I am running a 64 bit 5.3 kernel on an intel mb and all has been well. Today I thought it would be okay to reboot so that the latest kernel was running - i.e move from 128.2.1 to 128.4.1 release. The system passes POST fine, grub passes control to the 128.4.1 kernel and the boot process is under way. after some 30 secs the system starts beeping - continuously. After I hooked up a monitor I find that udev does not come up with OK and thats when the system starts the beep beep beep ...... No logs to see ...... using grub to select 128.2.1 boot fine Any ideas?
I just upgraded the kernel also, and I'm having the same problem (except that my screen goes blank).
I noticed that Interactive mode allows the system to boot.
So, I'm wondering how to revert to the penultimate kernel. I tried to find info - all I got was rpm -e kernel-oldversion Would that make the system drop to the next-to-most-recent?
I saw a few mentions of using grub - but I set the timeout to 0 (but I don't use that screen, so I don't even see it now). If this method is a permanent fix, should I set it so that it comes up on the next boot?
[mykolas@sr1220 ~]$ uname -r 2.6.18-128.4.1.el5 [mykolas@sr1220 ~]$ rpm -q kernel kernel-2.6.18-128.el5 kernel-2.6.18-128.1.16.el5 kernel-2.6.18-128.4.1.el5
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Michael, My screen goes blank too. It shows that it is starting udev but never comes up with the [OK] - just blanks the screen and beeps..... You may need to edit /boot/grub/grub.conf as root or via sudo and alter timeout or set default=1 or whatever number kernel you want - remember grub counts from 0. I haven't tried interactive - will do that tonight. HTH Rob _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Never did get the 4.1 kernel to work but the 7.1 kernel works just fine ...... Go figure
-
Michael Klinosky -
Rob Kampen -
Tru Huynh