Bug 218308

Summary: initramfs /init dies on machine with slow SATA controller
Product: [Fedora] Fedora Reporter: Will Woods <wwoods>
Component: LiveCDAssignee: David Zeuthen <davidz>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dcantrell, mclasen
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-05 17:50:29 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:
Bug Depends On:    
Bug Blocks: 217945    
Attachments:
Description Flags
screenshot of waiting for rootfs
none
"screenshot" of some kernel messages leading to init bug none

Description Will Woods 2006-12-04 16:06:43 UTC
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 16:25:06 UTC
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 21:34:16 UTC
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 17:12:57 UTC
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 18:10:14 UTC
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-07 00:55:18 UTC
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 20:37:18 UTC
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 20:38:48 UTC
Messages after the "please be patient" one are the same as above.

Comment 8 David Zeuthen 2006-12-08 04:16:24 UTC
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 17:50:29 UTC
Will and Bill told me this is fixed now so closing.