2017-11-23 07:36 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004049CentOS-5kernelpublic2009-12-07 13:36
Reportermsz1959 
PrioritynormalSeveritycrashReproducibilityalways
StatusnewResolutionopen 
Product Version5.4 
Target VersionFixed in Version 
Summary0004049: system won't boot after update to 2.6.18-164.6.1 kernel
DescriptionA freshly installed CentOS 5.4 system was fully updated. The system won't boot into the new kernel, hanging after showing the following on the screen:
 Starting udev: Wait timeout. Will continue in the background [FAILED]
 Loading default keymap (us) [OK]
 Setting hostname: hostname [OK]
 No devices found
On the original kernel (2.6.18-128) it works fine.
Additional InformationThe machine is quite old, with two AMD Athlon MP CPUs on MSI MS-6501 (K7D Master) motherboard, 2GB of RAM, two WDC WD2000JB hard disks, Adaptec 29320ALP PCIx Ultra320 SCSI adapter (to which an external IDE-to-SCSI RAID array and an Ultrium LTO3 tape drive are connected).
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0010461

tru (administrator)

> A freshly installed CentOS 5.4 system was fully updated. (...)
> On the original kernel (2.6.18-128) it works fine.

The 5.4 kernel series is 2.6.18-164.
The 5.3 kernel series is 2.6.18-128.
Something is not consitent in your report. Is it 5.3 -> 5.4 upgrade?

~0010462

tru (administrator)

possibly related to https://bugzilla.redhat.com/show_bug.cgi?id=525353 ?
pam %post script not applied correctly?

~0010463

msz1959 (reporter)

Sorry, I must have made a mistake burning old (5.3) image to a DVD and marking it as 5.4. I was even surprised by the number of updates available for a not that-old system :) I will try the "pam" solution mentioned above and report.
The difference in my case is that the boot never continues after the timeout in udev is reported.
Still, I am surprised that pam configuration may break the system at such an early stage of boot.
Also, I supposed that the "No devices found" - the last message seen on the screen, is somewhat related to the problem. Later, however, I have seen it also during the successful boot with 2.6.18-128 kernel.

~0010467

msz1959 (reporter)

The hint from https://bugzilla.redhat.com/show_bug.cgi?id=525353 (changing
<console> 0600 <sound> 0660 root.audio
to
<console> 0600 <sound> 0660 root
) worked here, too, with the small modification that the file to modify is
/etc/security/console.perms.d/50-default.perms

It remains a mystery to my, however, how something like that can prevent a modern system from booting. My dear Linux, where are you going? :)
+Notes

-Issue History
Date Modified Username Field Change
2009-12-05 17:16 msz1959 New Issue
2009-12-05 20:35 tru Note Added: 0010461
2009-12-05 20:42 tru Note Added: 0010462
2009-12-05 22:02 msz1959 Note Added: 0010463
2009-12-07 13:36 msz1959 Note Added: 0010467
+Issue History