Bug 218308 - initramfs /init dies on machine with slow SATA controller
initramfs /init dies on machine with slow SATA controller
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: LiveCD (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
David Lawrence
:
Depends On:
Blocks: FC6LiveCDTracker
  Show dependency treegraph
 
Reported: 2006-12-04 11:06 EST by Will Woods
Modified: 2013-03-05 22:48 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-05 12:50:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot of waiting for rootfs (567.47 KB, image/png)
2006-12-06 19:55 EST, David Zeuthen
no flags Details
"screenshot" of some kernel messages leading to init bug (67.83 KB, image/jpeg)
2006-12-07 15:37 EST, Will Woods
no flags Details

  None (edit)
Description Will Woods 2006-12-04 11:06:43 EST
My Dell PowerEdge SC430 has a SATA controller that takes ~30sec to start - it
fails to reset the secondary controller (which has nothing attached), the kernel
waits a bit, and then it moves on.

Unfortunately this delay seems to cause the initramfs /init to die, saying:

"Bug in initramfs /init detected. Dropping to a shell. Good luck!"
Comment 1 David Zeuthen 2006-12-04 11:25:06 EST
I think I know what the problem is here; saw it on OLPC a month or two back...
but am probably not using sources that includes this fix... give me a few hours
to do a LiveCD respin with this bugfix.
Comment 2 David Zeuthen 2006-12-05 16:34:16 EST
Please try build3 available from here this machine on the RH intranet

 http://172.16.83.66/~davidz/

Thanks.
Comment 3 Will Woods 2006-12-06 12:12:57 EST
No love. Here's the relevant kernel messages (with quiet turned off):

ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE12 bmdma 0xFEA0 irq 225
ata2: SATA max UDMA/133 cmd 0xFE20 ctl 0xFE32 bmdma 0xFEA8 irq 225
scsi0 : ata_piix
ata1.00: ATA-7, max UDMA/133, 488281250 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 8
ata1.00: configured for UDMA/133
scsi1 : ata_piix
ata2: port is slow to respond, please be patient
ata2: port failed to respond (30 secs)
ata2: SRST failed (status 0xFF)
ata2: SRST failed (err_mask=0x100)
ata2: softreset failed, retrying in 5 secs
Bug in initramfs /init detected. Dropping to a shell. Good luck!

bash: no job control in this shell
bash-3.1# 
ata2: SRST failed (status 0xFF)
ata2: SRST failed (err_mask=0x100)
ata2: softreset failed, retrying in 5 secs
ata2: SRST failed (status 0xFF)
ata2: SRST failed (err_mask=0x100)
ata2: reset failed, giving up

I'm guessing that /init is not honoring the kernel's request to "please be
patient". heh.
Comment 4 David Zeuthen 2006-12-06 13:10:14 EST
Does it write

 no root yet, udev rule will write symlink...
 waiting up to 60 seconds before dropping to emergency shell

Getting all the messages would be useful... any chance you can hook up a serial
console and use console=ttyS0,115200 on the commandline (without quiet). Or any
chance you can hook up one of those fancy devices so I can VNC into it? Thanks!
Comment 5 David Zeuthen 2006-12-06 19:55:18 EST
Created attachment 143012 [details]
screenshot of waiting for rootfs

If you can take a picture of the screen, much like the attached (where I
changed the CDLABEL on purpose), it would be useful. I'm also curious if the
system waits at all. Thanks.
Comment 6 Will Woods 2006-12-07 15:37:18 EST
Created attachment 143087 [details]
"screenshot" of some kernel messages leading to init bug

I get the 'waiting for system to settle' message, but not the "no root yet...
waiting up to 60 seconds" one.

The failure seems to happen after the first 30-second wait for ata2. Here's a
screenshot with a bit more context (before the messages listed in comment #3).
Comment 7 Will Woods 2006-12-07 15:38:48 EST
Messages after the "please be patient" one are the same as above.
Comment 8 David Zeuthen 2006-12-07 23:16:24 EST
Mmm... this is very weird. Tell me, what is the output of 'ls -l /dev/root' when
you get the emergency shell? Thanks.
Comment 9 David Zeuthen 2007-01-05 12:50:29 EST
Will and Bill told me this is fixed now so closing.

Note You need to log in before you can comment on or make changes to this bug.