Bug 475943

Summary: Boot message: Could not detect stabilization, waiting 10 seconds
Product: Red Hat Enterprise Linux 5 Reporter: Traxtopel <traxtopel>
Component: mkinitrdAssignee: Peter Jones <pjones>
Status: CLOSED DUPLICATE QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: alsadi, am, arancherinnebraska, bdwheele, bruno, bugzilla.redhat.com, carloraudino, cenomanien, chris, cj, d.bz-redhat, dchapman, dennisml, dextro, drwilken, dshaw, fedora, florian.a.jung, germanp1982, ghost2097, gnafu_the_great, hdegoede, hitboxx, hlingler, honeybeenet, honza, humpf, jaroslav.sykora, joachim.backes, jochen.wiedmann, john5342, john.brown009, john.ellson, joropo, jrodary, kamilpe, katzj, kernel-maint, krnlbg, lejocelyn, lsof, mail, marek78uk, mavit, moneta.mace, mosonkonrad, mwc, netllama, nexor, nick.stumpos, phil, pjmtavares, pjones, quintela, ralston, rc040203, red, red, rmj, rosset.filipe, russ+bugzilla-redhat, sameer.subscriptions, sangu.fedora, sean, sergejx, sindrepb, torsten, turchi, walovaton, wtogami, yaneti
Target Milestone: beta   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-11 09:47:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Traxtopel 2008-12-11 07:50:12 UTC
+++ This bug was initially created as a clone of Bug #470628 +++

Description of problem:

I am seeing the same warning message "could not detect stabilization, waiting 10 seconds" with el5.3 beta kernel 125.el5 & 126.el5.

Is there a mkinitrd update planned for 5.3?


The precise message is:
Could not detect stabilization, waiting 10 seconds. 

I do not think, the boot procedure is not truly delayed 10 seconds, first you see only the cursor blinking, then the message appears, then you see LVM reading the volumes.

Afterwards everything seems to be normal. I get this error on an HP 2133. Output of lspci attached. HP 2133 has a SATA Harddrive, not SSD (at least my model)

What the hack is this anyway for???

Version-Release number of selected component (if applicable):

2.6.27.4-79

How reproducible:

Every time when you power up the machine

--- Additional comment from linuxbenutzer on 2008-11-07 21:36:06 EDT ---

Created an attachment (id=322923)
lspci on HP 2133

--- Additional comment from lejocelyn on 2008-11-08 11:20:05 EDT ---

I've got the same problem here, on a eeePC 900a. If I can provide any useful info, let me know.

--- Additional comment from dr.diesel on 2008-11-08 18:47:33 EDT ---

Same here, 11/8/08 Rawhide:

Could not detect stabilization, waiting 10 seconds.

  Reading all physical volumes.  This may take a while...

  Found volume group "VolGroup00" using metadata type lvm2

  2 logical volume(s) in volume group "VolGroup00" now active

Doesn't seem to cause any problems, not sure what else to add, can't find anything related in any log file.

--- Additional comment from mosonkonrad on 2008-11-10 05:56:04 EDT ---

I have the same problem on ASUS A9RP. I don't have LVM.

--- Additional comment from trausche on 2008-11-10 07:04:04 EDT ---

(In reply to comment #0)
> I do not think, the boot procedure is not truly delayed 10 seconds, first you
> see only the cursor blinking, then the message appears, then you see LVM
> reading the volumes.

As far as I can say it is really doing nothing for 10 seconds after the message appears.

I don't use LVM. Drives are only attached to the PATA Controller. The SATA controller is not used.

# lspci | grep IDE
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)

For me this waiting phase is slowing down the boot process by one fourth!

--- Additional comment from red on 2008-11-11 11:07:56 EDT ---

I can confirm this issue on my Asus EeePC 1000H.

$ lspci | grep IDE
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)

--- Additional comment from nick.stumpos on 2008-11-11 11:11:47 EDT ---

same here on a compaq presario v6000 it definitely seems to be stalling for at least 10 seconds
$lspci | grep IDE
00:06.0 IDE interface: nVidia Corporation MCP67 IDE Controller (rev a1)
00:09.0 IDE interface: nVidia Corporation MCP67 AHCI Controller (rev a2)

--- Additional comment from mosonkonrad on 2008-11-11 15:44:12 EDT ---

my ASUS A9RP:
$$ lspci | grep IDE
00:14.1 IDE interface: ATI Technologies Inc IXP SB400 IDE Controller (rev 80)

this is hardware independent i think

--- Additional comment from dextro on 2008-11-12 11:40:14 EDT ---

I can confirm this happens to me using kernel 2.6.27.4-79.fc10.x86_64 and with the following result out of "lspci | grep IDE":
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)

--- Additional comment from germanp1982 on 2008-11-12 16:43:53 EDT ---

Confirmed in latest kernel update 2.6.27.5-94.fc10.x86_64 (ASUS P5GDC Deluxe)

--- Additional comment from dennisml on 2008-11-12 20:23:51 EDT ---

Same here:

kernel-2.6.27.5-94.fc10.i686
ASRock ALiveNF6G-VSTA

lspci |grep IDE:
00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2)
00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:08.1 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)

This doesn't show up when I boot: kernel-2.6.27.4-58.fc10.i686

--- Additional comment from drwilken on 2008-11-14 11:52:24 EDT ---

Same here:

[drwilken@xpc ~]$ uname -a
Linux xpc.tux-power.dk 2.6.27.5-94.fc10.x86_64 #1 SMP Mon Nov 10 15:19:36 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
[drwilken@xpc ~]$ lspci | grep IDE
00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

--- Additional comment from cenomanien on 2008-11-14 13:31:39 EDT ---

Hello,

I still get the same message with 2.6.27.5-109.fc10.x86_64; see below extract from /var/log/boot.log :

Loading /lib/kbd/keymaps/i386/azerty/fr-latin9.map <--- using French keyboard
Could not detect stabilization, waiting 10 seconds.
                Welcome to Fedora
                Press 'I' to enter interactive startup.
Starting udev: OK 
... and so on ... business as usual

No problem running 2.6.27.5-109.fc10.x86_64 besides this «warning» message.

Laptop is Asus F3JC, no LVM, only one «/» partition ext3.

--- Additional comment from mmoneta on 2008-11-14 16:26:11 EDT ---

Seeing this here too, on every boot.

Supermicro C2SEA, kernel-2.6.27.5-109.fc10.x86_64, drives are all SATA (2xHD, 2xDVD), and there's also a USB flash reader.

lspci -vvv for the SATA controllers:

00:1f.2 IDE interface: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE 
Controller (prog-if 8f [Master SecP SecO PriP PriO])
        Subsystem: Super Micro Computer Inc Device b880
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin B routed to IRQ 19
        Region 0: I/O ports at bc00 [size=8]
        Region 1: I/O ports at b880 [size=4]
        Region 2: I/O ports at b800 [size=8]
        Region 3: I/O ports at b480 [size=4]
        Region 4: I/O ports at b400 [size=16]
        Region 5: I/O ports at b080 [size=16]
        Capabilities: [70] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [b0] PCIe advanced features <?>
        Kernel driver in use: ata_piix
        Kernel modules: ata_generic, pata_acpi

00:1f.5 IDE interface: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE 
Controller (prog-if 85 [Master SecO PriO])
        Subsystem: Super Micro Computer Inc Device b880
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin B routed to IRQ 19
        Region 0: I/O ports at ac00 [size=8]
        Region 1: I/O ports at a880 [size=4]
        Region 2: I/O ports at a800 [size=8]
        Region 3: I/O ports at a480 [size=4]
        Region 4: I/O ports at a400 [size=16]
        Region 5: I/O ports at a080 [size=16]
        Capabilities: [70] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [b0] PCIe advanced features <?>
        Kernel driver in use: ata_piix
        Kernel modules: ata_generic, pata_acpi

--- Additional comment from dennisml on 2008-11-16 00:20:02 EDT ---

I think this bug is relevant for the "faster startup" feature of F10:
http://fedoraproject.org/wiki/Features/30SecondStartup

--- Additional comment from gnafu_the_great on 2008-11-16 15:31:21 EDT ---

I am experiencing the exact same behavior on a Compaq F572US with the last several kernels.

[root@gidux-laptop-rawhide ~]# lspci
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:05.0 VGA compatible controller: nVidia Corporation MCP51 PCI-X GeForce Go
6100 (rev a2)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0a.3 Co-processor: nVidia Corporation MCP51 PMU (rev a3)
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev f1)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address
Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
03:00.0 Network controller: Broadcom Corporation BCM4311 802.11b/g WLAN (rev
02)

--- Additional comment from carloraudino on 2008-11-18 03:57:50 EDT ---

same problem here. I have kernel 2.6.27.5-113

the message appears after:
pata_amd 0000:00:08.0: power state changed by ACPI to D0


lspci:

00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)
00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management (rev a1)
00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0 Controller (rev a2)
00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2)
00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA Controller (v2.5) (rev a2)
00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA Controller (v2.5) (rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI Bridge (rev a2)
00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AS [Radeon 9550]
01:00.1 Display controller: ATI Technologies Inc RV350 AS [Radeon 9550] (Secondary)
02:06.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)

--- Additional comment from gnafu_the_great on 2008-11-19 20:39:09 EDT ---

I am still receiving the message and a 10-second wait with today's update.

kernel.x86_64                               2.6.27.5-117.fc10

--- Additional comment from john.brown009 on 2008-11-21 00:00:00 EDT ---

This bug has been triaged

--- Additional comment from arancherinnebraska on 2008-11-25 08:50:28 EDT ---

Same here, x86_64 , all updates current as of this post.


00:00.0 Host bridge: nVidia Corporation C55 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:00.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:00.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:00.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:00.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a2)
00:00.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:00.7 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:01.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:01.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:01.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:01.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:01.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:01.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:01.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:02.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:02.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:02.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
00:03.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)
00:06.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)
00:07.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600 GT (rev a1)

--- Additional comment from marek on 2008-11-25 18:53:35 EDT ---

I've just installed Fedora 10 on Dell Latitude D620, getting the same error.

[marek@d620 Desktop]$ lspci | grep IDE
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 01)

--- Additional comment from fedora-triage-list on 2008-11-26 00:01:32 EDT ---


This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from jesse_kahtava on 2008-11-26 11:36:42 EDT ---

I, too, am getting this error on a Thinkpad T40. It seems to be adding 10 seconds to the boot sequence. I counted to 10 after grub finishes and just after the 10 second mark the password box for disk encryption appears.
Here's my Smolt profile:
http://www.smolts.org/client/show/pub_52d7367e-80d0-479c-bb50-e5218741cf0c

--- Additional comment from rosset.filipe on 2008-11-27 06:15:55 EDT ---

I've found this bug on a Toshiba M45S2693 Pentium M 1.73Ghz and this error adding 10 seconds to the boot process.

--- Additional comment from kamilpe on 2008-11-27 08:56:37 EDT ---

I have the same on abit AN52:

00:08.0 PCI bridge: nVidia Corporation MCP65 PCI bridge (rev a1)
00:09.0 IDE interface: nVidia Corporation MCP65 IDE (rev a1)
00:0a.0 IDE interface: nVidia Corporation MCP65 SATA Controller (rev a1)

--- Additional comment from hitboxx on 2008-11-28 03:33:38 EDT ---

I am having the same problem on x86_64 of Fedora 10 updated from rawhide but only during single user mode (runlevel 1). I get the same stabilization message and it hangs at Udev..

PC is a C2D, 2gigs RAM, nVidia Quadro gfx card, 3 SATA hard disks.

I DON'T use LVM or any RAID configurations.

[hitboxx@Mothership ~]$ lspci
00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 02)
04:00.0 VGA compatible controller: nVidia Corporation G73GL [Quadro FX 560] (rev a1)
05:01.0 Multimedia controller: Philips Semiconductors SAA7130 Video Broadcast Decoder (rev 01)
05:02.0 Multimedia audio controller: Creative Labs [SB Live! Value] EMU10k1X

[hitboxx@Mothership ~]$ uname -a
Linux Mothership 2.6.27.5-117.fc10.x86_64 #1 SMP Tue Nov 18 11:58:53 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

--- Additional comment from cj on 2008-11-28 06:50:20 EDT ---

I have this issue too on a Dell XPS m1330 (f10 x86_64)

Perhaps the nash fixes from https://bugzilla.redhat.com/show_bug.cgi?id=466607 actually broke the stabilized call instead of fixing it?

I've removed the stabilized call from mkinitrd entirely on my system and it still boots fine (just 10 seconds faster, obviously!), so I assume the sata scan is already complete and /proc/scsi/scsi is already stable.

--- Additional comment from jesse_kahtava on 2008-11-28 07:24:38 EDT ---

I, too, was able to boot quicker and without the message after commenting out:

stabilized --hash --interval 250 /proc/scsi/scsi

within mkinitrd's init file. Everything seems to be working fine without it. Perhaps this is necessary with certain scsi/sata devices, but my computer doesn't have any so I don't see why it should be enabled.

--- Additional comment from jesse_kahtava on 2008-11-28 07:30:13 EDT ---

on a related note: is there an init template file I could change so future mkinitrd rebuilds have it commented out by default?

--- Additional comment from dennisml on 2008-11-28 08:17:37 EDT ---

(In reply to comment #29)
> on a related note: is there an init template file I could change so future
> mkinitrd rebuilds have it commented out by default?

I guess somebody put that line in there for a reason so I would rather like to see someone knowledgeable with these things address this properly.
What was the reason for putting that line in there or alternatively what was the reason for changing the timing so that now a lot of people get this 10s delay?
Is the timing just slightly too aggressive?
Is this only a safety kludge for some chipsets which could better be handled by a black-/whitelist?

--- Additional comment from am on 2008-11-30 03:01:58 EDT ---

I have this issue on an Acer Aspire One with SSD hard-drive and on a computer with Intel's P35 motherboard.

--- Additional comment from joachim.backes.de on 2008-12-01 05:18:09 EDT ---

Having the same issue on a MSI K7N2 Delta board (based on NVIDIA nForce 2) and AMD Athlon XP processor, with 2 IDE disk drives and 2 USB-2 disk drives.

The message appears immediately after the USB drive detection.

00:00.0 Host bridge: nVidia Corporation nForce2 IGP2 (rev c1)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1)
00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio Controler (MCP) (rev a1)
00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
02:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)

--- Additional comment from sameer.subscriptions on 2008-12-02 09:33:01 EDT ---

I too have the same issue.
Intel GM695 Mobile Graphic Media Accelerator.

--- Additional comment from sean on 2008-12-02 10:05:33 EDT ---

I also have the same issue.  Dell Latitude D820:

# lspci | grep IDE
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 01)

--- Additional comment from netllama on 2008-12-02 16:22:07 EDT ---

Same here with an old VIA chipset based mobo:

00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

--- Additional comment from wtogami on 2008-12-03 17:16:51 EDT ---

/sbin/mkinitrd:

        # some of these aren't modules any more, but that 
        # generally makes them so much more likely to win
        # the race that we haven't seen cases where it matters
        # yet.  Nevertheless:
        # XXX PJFIX: we need a better mechanism here.
        if [ 1 -eq 0 \
                -o "ahci" == "$module" \
                -o "ata_piix" == "$module" \
                -o "ibmvscsic" == "$module" \
                -o "BusLogic" == "$module" \
                -o "mptbase" == "$module" \
                -o "pata_" == "${module::5}" \
                -o "qla" == "${module::3}" \
                -o "sata_" == "${module::5}" \
                ]; then
            wait_for_scsi="yes"
        fi
    done
    if [ "$wait_for_scsi" == "yes" ]; then
        emit "echo Waiting for driver initialization."
        emit "stabilized --hash --interval 250 /proc/scsi/scsi"
    fi

It is failing to use either scsi_wait_scan (because no scsi_mod) and stabilized in cases where the disk controller module is not listed in this hard-coded list.   One example of a driver not covered by this list is megaraid*.  If the controller is not fully up by the time it tries to use them, we see failures like not finding the disks.

--- Additional comment from krnlbg on 2008-12-05 10:57:26 EDT ---

Same bug:
[krnlbg@localhost ~]$ cat /var/log/boot.log
Loading /lib/kbd/keymaps/i386/qwerty/us.map
Could not detect stabilization, waiting 10 seconds.
mdadm: /dev/md2 has been started with 2 drives.
mdadm: /dev/md1 has been started with 2 drives.
		Welcome to Fedora 
		Press 'I' to enter interactive startup.

lspci:
[krnlbg@localhost ~]$ lspci
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:07.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04)
01:07.1 Input device controller: Creative Labs SB Audigy Game Port (rev 04)
01:07.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04)
01:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)
05:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2)

--- Additional comment from gc.fr on 2008-12-08 13:46:48 EDT ---

One more:

00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)

--- Additional comment from hdegoede on 2008-12-08 14:07:47 EDT ---

Hello world (aka all in the CC list)

First of all apologies for not responding to this bug for so long, we've been swamped with other stuff. We understand this is an very annoying bug (luckily it does not completely break things).

I've prepared a mkinitrd build, which we believe fixes this, you can find it here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=73912

To give this version a try you need to download the
mkinitrd-6.0.71-3.fc10.XXXX.rpm
nash-6.0.71-3.fc10.XXXX.rpm

Files for your architecture and then as root do:
rpm -ivh mkinitrd-6.0.71-3.fc10.*.rpm nash-6.0.71-3.fc10.*.rpm
mkinitrd -f /boot/mkinitrd-$(uname -r).img $(uname -r)

Warning this *could* leave your system non bootable, so you may want to do:
mkinitrd /boot/mkinitrd-$(uname -r).img2 $(uname -r)

Instead, but then you need to edit your boot commands in grub during boot to make grub use the new initrd (append a "2" at the end of the initrd line) to see if this fixes things.

Please let us know if this fixes things for you (and also, especially even, if the mkinitrd causes the boot of your system to fail).

If this update helps people, I will push it to updates-testing and eventally to the regular updates repository.

--- Additional comment from bruno on 2008-12-08 14:09:38 EDT ---

I tried out mkinitrd-6.0.71-3.fc10.x86_64 on my work machine and i no longer get the stablization message or pause. I'll be trying it on my i686 machine at home tonight.

--- Additional comment from mmoneta on 2008-12-08 14:39:39 EDT ---

This corrected the issue here as well.  By the way, I think the command above should have been:

mkinitrd /boot/initrd-$(uname -r).img2 $(uname -r)

--- Additional comment from mmoneta on 2008-12-08 14:49:58 EDT ---

Correction, there's no need for the img2 suffix either, right?

mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

--- Additional comment from jesse_kahtava on 2008-12-08 15:11:15 EDT ---

Yep, the fix works fine

--- Additional comment from trausche on 2008-12-08 15:30:45 EDT ---

Yes, this fixes it on my system.

--- Additional comment from alsadi on 2008-12-08 16:37:14 EDT ---

it worked for me
I renamed the old initrd and made a new one

mv /boot/initrd-$(uname -r).img /boot/initrd-$(uname -r).img.old
mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

--- Additional comment from sindrepb on 2008-12-08 21:04:23 EDT ---

Does indeed fix the issue. Thanks.

--- Additional comment from bruno on 2008-12-08 21:23:29 EDT ---

This seems to have fixed things on my home machine as well. It was slow enough that I could see a short pause (about 2 seconds) at the check for stablization and then it continued on without the error message.

--- Additional comment from joachim.backes.de on 2008-12-09 01:24:49 EDT ---

I tried to install the rpms, but ..................

 rpm -ivh mkinitrd-6.0.71-3.fc10.*.rpm nash-6.0.71-3.fc10.*.rpm
Preparing...                ########################################### [100%]
	file /lib/bdevid/ata.so from install of nash-6.0.71-3.fc10.i386 conflicts with file from package nash-6.0.71-2.fc10.i386
	file /lib/bdevid/scsi.so from install of nash-6.0.71-3.fc10.i386 conflicts with file from package nash-6.0.71-2.fc10.i386
	file /lib/bdevid/usb.so from install of nash-6.0.71-3.fc10.i386 conflicts with file from package nash-6.0.71-2.fc10.i386
	file /sbin/nash from install of nash-6.0.71-3.fc10.i386 conflicts with file from package nash-6.0.71-2.fc10.i386
	file /usr/lib/libbdevid.so.6.0.71 from install of nash-6.0.71-3.fc10.i386 conflicts with file from package nash-6.0.71-2.fc10.i386
	file /usr/lib/libnash.so.6.0.71 from install of nash-6.0.71-3.fc10.i386 conflicts with file from package nash-6.0.71-2.fc10.i386
	file /sbin/grubby from install of mkinitrd-6.0.71-3.fc10.i386 conflicts with file from package mkinitrd-6.0.71-2.fc10.i386
	file /sbin/mkinitrd from install of mkinitrd-6.0.71-3.fc10.i386 conflicts with file from package mkinitrd-6.0.71-2.fc10.i386

I'm not sure to install with --nodeps ??

--- Additional comment from nick.stumpos on 2008-12-09 01:31:07 EDT ---

try -Uvh
also i needed the libbdevid-python rpm
the fix appears to fix the message and the 10 second pause here, although there is now what seems to be an unusually long pause between "mounting root device" message and starting udev. probably a completely separate bug now though. Ill get to experimenting.

--- Additional comment from joachim.backes.de on 2008-12-09 01:51:00 EDT ---


 rpm -U mkinitrd-6.0.71-3.fc10.i386.rpm  nash-6.0.71-3.fc10.i386rpm 
error: Failed dependencies:
	nash = 6.0.71-2.fc10 is needed by (installed) libbdevid-python-6.0.71-2.fc10.i386

--- Additional comment from hdegoede on 2008-12-09 03:21:48 EDT ---

(In reply to comment #50)
>  rpm -U mkinitrd-6.0.71-3.fc10.i386.rpm  nash-6.0.71-3.fc10.i386rpm 
> error: Failed dependencies:
>  nash = 6.0.71-2.fc10 is needed by (installed)
> libbdevid-python-6.0.71-2.fc10.i386

Yes you need to use -U (or -Uvh) not -i, my bad. And on some systems you might need to also download and upgrade libbdevid-python.

--- Additional comment from hdegoede on 2008-12-09 03:29:06 EDT ---

Hello world (aka all in the CC list) again

I've made some errors in the usage instructions of the updated mkinitrd packages, apologies. Here is a fixed set of instructions:

To give this version a try you need to download the:
mkinitrd-6.0.71-3.fc10.XXXX.rpm
nash-6.0.71-3.fc10.XXXX.rpm
libbdevid-python-6.0.71-3.fc10.XXXX.rpm
Files for your architecture from:
http://koji.fedoraproject.org/koji/buildinfo?buildID=73912

And then as root do:
rpm -Uvh mkinitrd-6.0.71-3.fc10.*.rpm nash-6.0.71-3.fc10.*.rpm libbdevid-python-6.0.71-3.fc10.*.rpm
mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

Warning this *could* leave your system non bootable, so you may want to do:
mkinitrd /boot/initrd-$(uname -r).img2 $(uname -r)

Instead, but then you need to edit your boot commands in grub during boot to
make grub use the new initrd (append a "2" at the end of the initrd line) to
see if this fixes things.

Please let us know if this fixes things for you (and also, especially even, if
this mkinitrd causes the boot of your system to fail).

--- Additional comment from joachim.backes.de on 2008-12-09 04:33:25 EDT ---

Great, problem now solved on my box.

--- Additional comment from drwilken on 2008-12-09 06:03:24 EDT ---

Problem solved on x86_64 117 kernel... ;)

--- Additional comment from rosset.filipe on 2008-12-09 07:31:29 EDT ---

Problem solved on i686 Toshiba M45S2693 Pentium M 1.73Ghz
:)

--- Additional comment from gc.fr on 2008-12-09 10:42:42 EDT ---

It works for me. 

00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev
01)

--- Additional comment from sergejx on 2008-12-09 10:59:04 EDT ---

Works for mee, too.

I'm using SATA drive and no LVM/RAID.

$ lspci | grep IDE
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)

--- Additional comment from davej on 2008-12-09 14:11:14 EDT ---

*** Bug 473832 has been marked as a duplicate of this bug. ***

--- Additional comment from davej on 2008-12-09 14:12:19 EDT ---

*** Bug 473305 has been marked as a duplicate of this bug. ***

--- Additional comment from krnlbg on 2008-12-09 14:54:39 EDT ---

It works for me! Thank you!

--- Additional comment from davej on 2008-12-09 15:00:30 EDT ---

*** Bug 454663 has been marked as a duplicate of this bug. ***

--- Additional comment from davej on 2008-12-09 15:01:52 EDT ---

*** Bug 474796 has been marked as a duplicate of this bug. ***

--- Additional comment from dextro on 2008-12-09 17:26:36 EDT ---

Works for me too :)

--- Additional comment from coldfusionpc on 2008-12-09 18:57:09 EDT ---

Worked for me.

--- Additional comment from coldfusionpc on 2008-12-09 19:01:43 EDT ---

(In reply to comment #64)
> Worked for me.

Although I feel like noting that if, like me, you had to go back to a previous kernel because the system would not boot at all, "uname -r" will not be an appropriate value and you should specify the version instead.

--- Additional comment from dennisml on 2008-12-09 22:31:22 EDT ---

Yup, works for me too (MCP61 chipset).

--- Additional comment from sameer.subscriptions on 2008-12-10 01:28:36 EDT ---

I got it working but not without changes in my /etc/fstab.
I use LVM partitions for my F10 installation and this is what my /etc/fstab looked like

tmpfs           /dev/shm        tmpfs   defaults        0       0
devpts          /dev/pts        devpts  gid=5,mode=620  0       0
sysfs           /sys    sysfs   defaults                0       0
proc            /proc   proc    defaults                0       0
/dev/dm-0       /       ext3    defaults                1       1
/dev/dm-1       /opt    ext3    defaults                1       2
/dev/dm-2       /home   ext3    defaults                1       2
/dev/dm-3       swap    swap    defaults                0       0
UUID=2cebc311-55ce-4670-ae4c-1163aca1db05       /boot   ext3    defaults                1       2

this file was created by the fedora system, not by me, notice the /dev/dm-* devices. these apparently are lvm logical volumes.

so when i followed the steps specified, the system would not boot throwing the following messages

Unable to access resume device /dev/dm-3
mount: error mounting /dev/root on /sysroot as ext3: No such file of directory

i figured this is due to the fstab file and made the following changes

tmpfs               /dev/shm                tmpfs   defaults        0       0
devpts              /dev/pts                devpts  gid=5,mode=620  0       0
sysfs               /sys                    sysfs   defaults        0       0
proc                /proc                   proc    defaults        0       0
/dev/primary/root   /                       ext3    defaults        1       1
/dev/primary/opt    /opt                    ext3    defaults        1       2
/dev/primary/home   /home                   ext3    defaults        1       2
/dev/primary/swap   swap                    swap    defaults        0       0
/dev/sda9           /boot                   ext3    defaults        1       2

theb i recreated the initrd image and only then it works perfectly.

So i believe theres a bug in the mkinitrd tool that needs fixing.

Regards
~Sameer

--- Additional comment from sameer.subscriptions on 2008-12-10 01:34:08 EDT ---

I think i should also mention that a few days back i installed an ndiswrapper modules enabled kernel using the fedora/rpmfusion yum repositories and that kernel too would not boot throwing the same message

Unable to access resume device /dev/dm-3
mount: error mounting /dev/root on /sysroot as ext3: No such file of directory

I did not worry about it (thinking that there could be an error in the kernel) and just got rid of the ndiswrapper enabled kernel. But now i see where the problem came from.

Regards
~Sameer

(In reply to comment #67)
> I got it working but not without changes in my /etc/fstab.
> I use LVM partitions for my F10 installation and this is what my /etc/fstab
> looked like
> 
> tmpfs           /dev/shm        tmpfs   defaults        0       0
> devpts          /dev/pts        devpts  gid=5,mode=620  0       0
> sysfs           /sys    sysfs   defaults                0       0
> proc            /proc   proc    defaults                0       0
> /dev/dm-0       /       ext3    defaults                1       1
> /dev/dm-1       /opt    ext3    defaults                1       2
> /dev/dm-2       /home   ext3    defaults                1       2
> /dev/dm-3       swap    swap    defaults                0       0
> UUID=2cebc311-55ce-4670-ae4c-1163aca1db05       /boot   ext3    defaults       
>         1       2
> 
> this file was created by the fedora system, not by me, notice the /dev/dm-*
> devices. these apparently are lvm logical volumes.
> 
> so when i followed the steps specified, the system would not boot throwing the
> following messages
> 
> Unable to access resume device /dev/dm-3
> mount: error mounting /dev/root on /sysroot as ext3: No such file of directory
> 
> i figured this is due to the fstab file and made the following changes
> 
> tmpfs               /dev/shm                tmpfs   defaults        0       0
> devpts              /dev/pts                devpts  gid=5,mode=620  0       0
> sysfs               /sys                    sysfs   defaults        0       0
> proc                /proc                   proc    defaults        0       0
> /dev/primary/root   /                       ext3    defaults        1       1
> /dev/primary/opt    /opt                    ext3    defaults        1       2
> /dev/primary/home   /home                   ext3    defaults        1       2
> /dev/primary/swap   swap                    swap    defaults        0       0
> /dev/sda9           /boot                   ext3    defaults        1       2
> 
> theb i recreated the initrd image and only then it works perfectly.
> 
> So i believe theres a bug in the mkinitrd tool that needs fixing.
> 
> Regards
> ~Sameer

--- Additional comment from hdegoede on 2008-12-10 03:07:59 EDT ---

(In reply to comment #68)
> I think i should also mention that a few days back i installed an ndiswrapper
> modules enabled kernel using the fedora/rpmfusion yum repositories and that
> kernel too would not boot throwing the same message
> 
> Unable to access resume device /dev/dm-3
> mount: error mounting /dev/root on /sysroot as ext3: No such file of directory
> 
> I did not worry about it (thinking that there could be an error in the kernel)
> and just got rid of the ndiswrapper enabled kernel. But now i see where the
> problem came from.
> 


Ok, so this bug is present in the previous version of mkinitrd, which makes sense as the changes in the new version are completely unrelated to your fstab problem. Please file a new bug against mkinitrd for this issue, thanks!

--- Additional comment from updates on 2008-12-10 03:35:53 EDT ---

mkinitrd-6.0.71-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/mkinitrd-6.0.71-3.fc10

--- Additional comment from winfrid.tschiedel on 2008-12-10 04:12:30 EDT ---

My problem is solved ( f10 kernel with megaraid_sas did not boot )

Thank you,

Winfrid

--- Additional comment from sameer.subscriptions on 2008-12-10 07:47:34 EDT ---

ok just did, located at 
https://bugzilla.redhat.com/show_bug.cgi?id=475773

(In reply to comment #69)
> (In reply to comment #68)
> > I think i should also mention that a few days back i installed an ndiswrapper
> > modules enabled kernel using the fedora/rpmfusion yum repositories and that
> > kernel too would not boot throwing the same message
> > 
> > Unable to access resume device /dev/dm-3
> > mount: error mounting /dev/root on /sysroot as ext3: No such file of directory
> > 
> > I did not worry about it (thinking that there could be an error in the kernel)
> > and just got rid of the ndiswrapper enabled kernel. But now i see where the
> > problem came from.
> > 
> 
> 
> Ok, so this bug is present in the previous version of mkinitrd, which makes
> sense as the changes in the new version are completely unrelated to your fstab
> problem. Please file a new bug against mkinitrd for this issue, thanks!

--- Additional comment from notting on 2008-12-10 10:46:23 EDT ---

*** Bug 473305 has been marked as a duplicate of this bug. ***

--- Additional comment from florian.a.jung on 2008-12-10 11:39:43 EDT ---

works for me on a dell inspiron 9100 (i686), but i wasn't able to update these packets via yum.
i had to download and install them manually.

--- Additional comment from davej on 2008-12-10 15:27:03 EDT ---

*** Bug 466534 has been marked as a duplicate of this bug. ***

--- Additional comment from davej on 2008-12-10 15:28:28 EDT ---

*** Bug 473092 has been marked as a duplicate of this bug. ***

--- Additional comment from arancherinnebraska on 2008-12-10 16:00:33 EDT ---

Works fine.

--- Additional comment from hlingler on 2008-12-10 23:00:36 EDT ---

Seeing this same bug (I think) on [pre]upgrade F8=>F9. Can't re-build mkinitrd SRPM due to failed deps. Can anything be done to salvage these installs?

REF: http://forums.fedoraforum.org/showthread.php?t=203692

Output:
[...]
vgchange     Wiping internal VG cache
Trying to resume from /dev/VolGroup00/LogVol01
Unable to access resume device (/dev/VolGroup00/LogVol01)
Creating root device.
Mounting root filesystem.
mount: error mounting /dev/root on /sysroot as ext3: No such file or directory
Setting up other filesystems.
Setting up new root fs
setuproot: moving /dev failed: No such file or directory
no fstab.sys, mounting internal defaults
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
Mount failed for selinuxfs on /selinux: No such file or directory
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
switchroot: mount failed: No such file or directory
Booting has failed.

Thanks and Regards,
VJS

Comment 1 Hans de Goede 2008-12-11 09:47:28 UTC
This message and the 10 second boot delay is caused by a fix in RHEL 5.3 which causes us to not wait long enough in certain cases (bug 464636). In some cases where the system is very quick with scanning the bus, this fix will cause us to not notice stabilization (because that already happened before we started checking), causing us to wait an additional 10 seconds to be sure.

Fixing this the way we've done in Fedora is not possible in RHEL 5. We've prepared a release note about the harmless 10 second boot delay this causes.

*** This bug has been marked as a duplicate of bug 464636 ***