Fails to find boot device in Intel D945Gnt

Bug #290153 reported by Scott Kitterman
174
This bug affects 19 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Invalid
Undecided
Unassigned
busybox (Ubuntu)
Invalid
High
Unassigned
Intrepid
Invalid
High
Unassigned
Jaunty
Invalid
High
Unassigned
Karmic
Invalid
High
Unassigned
initramfs-tools (Ubuntu)
Invalid
Undecided
Unassigned
Intrepid
Invalid
Undecided
Unassigned
Jaunty
Invalid
Undecided
Unassigned
Karmic
Invalid
Undecided
Unassigned
linux (Ubuntu)
Won't Fix
High
Unassigned
Intrepid
Won't Fix
High
Unassigned
Jaunty
Won't Fix
High
Unassigned
Karmic
Won't Fix
High
Unassigned

Bug Description

The machine in question is built around an Intel D945Gnt motherboard. It worked fine in Hardy with Kubuntu KDE3. dist-upgraded today using the kubuntu.org recommendations. After upgrade, was dropped to an initramfs shell and the boot device was not found, "Gave up waiting for root device." Root device is a SATA hard drive.

After waiting a minute or two, I exited the initramfs shell and the boot process continued normally.

Adding rootdelay=90 to the current kernel line in menu.list gets a good boot. It's at least a work around.

Changed in linux-meta:
importance: Undecided → High
description: updated
Revision history for this message
KimOlsen (kimfolsen80) wrote :

Have a similar problem. I have windows on two sata drives (in a nvraid) and intrepid on a third drive (non raid). When I boot it drop to the busybox and initramfs, but if I exit then it boots. But when I log in, my raid is not present and my /dev/mapper/ only shows control.

Revision history for this message
KimOlsen (kimfolsen80) wrote :

Forgot to mention that I do not have the Intel D945, but an abit nforce4 ultra. And since I have the raid issue, mine might not be related.

Revision history for this message
Scott Kitterman (kitterman) wrote :

Specific error message after initramfs appears:

ata4: SRST failed (errorno=-16)
ata4: SRST failed (errorno=-16)
ata4: reset failed, giving up

description: updated
Changed in busybox:
importance: Undecided → High
Revision history for this message
KimOlsen (kimfolsen80) wrote :

Adding my dmesg file after a boot (That I have to force to continue by exit in initramfs). Have not tried the rootdelay yet, and still not sure if mine is related. But some things are similar.

Revision history for this message
Scott Kitterman (kitterman) wrote :

Proposed release note:

Boot failures on systems with Intel D945 motherboards have been reported. If this failure occurs, the system will drop to a busybox initramfs shell with a "Gave up waiting for root device." error. Wait a minute or two and then exit the initramfs shell by typing 'exit'. Booting should proceed normally. If it doesn't wait a bit longer and try again. Once the system boots, edit /boot/grub/menu.lst and add rootdelay=90 to the kernel stanza for your current kernel.

Revision history for this message
KimOlsen (kimfolsen80) wrote :

Found that my problem might be related to bug #33269 instead. So will try a few suggestions from there

Revision history for this message
KimOlsen (kimfolsen80) wrote :

Could get it to boot without any interaction in the initramfs with a rootdelay=130, but still no raid... Proposed workarounds in bug #33269 did not seem to work.

Revision history for this message
mirhciulica (mirhciulica) wrote :

I have D945GNT, one sata and one external hard drive, and I don't have any problem. So this problem is related to raid.

Revision history for this message
Scott Kitterman (kitterman) wrote : Re: [Bug 290153] Re: Fails to find boot device in Intel D945Gnt

Mine is two SATA HD and ATAPI CD. No RAID. So it's not just RAID. You're
running Intrepid?

Revision history for this message
mirhciulica (mirhciulica) wrote :

Yes, I'm running Intreprid. I didn't mention the SATA optical drive in my first post, because I think that it has no relevance. I don't have any problems. Maybe this is related to distro upgrade.

Revision history for this message
Robbie Williamson (robbiew) wrote :

Updated release notes with text from Comment #5.

Changed in ubuntu-release-notes:
status: New → Fix Released
Revision history for this message
Fabri Velas (fabrivelas) wrote :

I have the same problem with an Intel SATA controller 82801GBM/GHM (ICH7 Family) on a Hitachi ATA Disk (HTS541010G9SA00), see bug #288388.

Revision history for this message
Scott Kitterman (kitterman) wrote :

Did the workaround work for you?

Revision history for this message
brazzmonkey (brazzmonkey) wrote :

i've got similar issue since kernel 2.6.27-6 (intrepid beta), 2.6.27-5 works fine (this is the one i currently use).
my system is an acer 9814 featuring an intel mobo, kubuntu is 64-bit edition. i have a fakeraid 2-disk setup with stripped / and mirrored /home.

waiting longer or setting longer boot delay doesn't work for me. traditional "kernel alive, kernel really alive" message is not displayed either. i just end up with the initramfs shell with an error message saying that my /dev/mapper/my_root_raid_partition_here is not found ; the only workaround i found is booting kernel 2.6.27-5.

this computer has been using ubuntu since edgy (6.10) mostly with 32-bit editions, and no raid. i never came across this issue before.
i gave a try to opensuse 11.0 (which actually is how i set up my raid configuration) and didn't have this issue either.

i'm not sure if my issue is actually related to this bug, but if it is, something must have changed between kernels 2.6.27-5 and 2.6.27-7 and this "something" could be the cause of my issue.

Revision history for this message
Fabri Velas (fabrivelas) wrote :

@Scott: Yes, the workaround worked. I put a delay of 60 seconds into my menu.lst.

Revision history for this message
Tom Bott (tombott) wrote :

Same issue here, but workaround worked.

Board:

ASUS PSGV-MX
HD's

1 x Sata (Boot)
1x IDE (Fat32 Data)

Ubuntu 8.10 - Clean install.

Revision history for this message
qwerty (escalantea) wrote :

I have a D865PERL (Intel), and the message in the /var/log/dmesg is :

[ 4.543880] sd 2:0:0:0: [sdb] Attached SCSI disk
[ 34.820043] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 34.820101] ata3.00: cmd c8/00:07:de:32:56/00:00:00:00:00/e7 tag 0 dma 3584 in
[ 34.820104] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 34.820201] ata3.00: status: { DRDY }
[ 34.820257] ata3: soft resetting link
[ 34.992358] ata3.00: configured for UDMA/133
[ 34.992371] ata3: EH complete

The SATA HD is frozen for 30 seconds and It freezes one more time (another 30 seconds) after i write the userid and password in the login screen.

[ 102.493418] NVRM: loading NVIDIA UNIX x86 Kernel Module 173.14.12 Thu Jul 17 18:11:36 PDT 2008
[ 132.392040] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 132.392120] ata3.00: cmd c8/00:08:3d:8b:46/00:00:00:00:00/e2 tag 0 dma 4096 in
[ 132.392123] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 132.392257] ata3.00: status: { DRDY }
[ 132.392322] ata3: soft resetting link
[ 132.564355] ata3.00: configured for UDMA/133
[ 132.564368] ata3: EH complete

I have tried rootdelay=90, it solves the first freezing, but the second freezing remains.

Revision history for this message
qwerty (escalantea) wrote :

Just in case ... my lspci :

Revision history for this message
qwerty (escalantea) wrote :

I solved the problem with my SATA HD by disabling (Bios) the option "PCI IDE Bus Master".

I guess the problem could be a flag (Bios?? or Linux module??), but there is another "interesting effect" that I got by disabling "PCI IDE Bus Master" in my Intel D865PERL Bios:

I also have an IDE HD which was working at UDMA2 (33.3 MB/s) and now is now working at UDMA5 (100 MB/s).

Revision history for this message
Sandro Mani (sandromani) wrote :

I am also experiencing the same problem with a Asus p4p800-se (i865pe chipset). I get the "gave up waiting for root device" as well as constant "SRST failed (errorno=-16)" messages (the harddrives are SCSI, the only ATA devices are two cd roms). Bug #278176 is possibly related.

Tried disabling PCI IDE Bus Master, as well as changing IDE Modes (Compatibility / Enchanced), without any luck.

Revision history for this message
Tanzbaer (tanzbaer) wrote :

I got the same problem with my MSI MS-6577 v4.0 GL6E.

Revision history for this message
Tanzbaer (tanzbaer) wrote :

The bootdelay option does NOT work for me.

Revision history for this message
Tanzbaer (tanzbaer) wrote :

And I get a similar problem when trying to boot the liveCD...

Revision history for this message
Scott Kitterman (kitterman) wrote :

>The bootdelay option does NOT work for me.

90 seconds worked for me. It may need to be bigger in some cases. If you haven't, try a
substantially larger value and then if it works, experiment with how far you can reduce it.

Changed in linux:
assignee: nobody → ubuntu-kernel-team
status: New → Triaged
Revision history for this message
ivanmara (aesthete2005) wrote :

I got the same problem with my Supermicro X5DE8-GG (Serverworks GC-SL Chipset) motherboard with scsi drives on Ubuntu server 8.10 ... The rootdelay=90 workaround work for me ... on 8.04 everything was OK

Revision history for this message
FernanAguero (fernan-ciudad) wrote :

I have the same problem, and adding rootdelay=90 didn't solve the problem.

My system:
Dell Optiplex 740n
CPU: AMD 64 Athlon X2 Dual 3800+ 2.00 GHz
HD: WDC WD800JD-75MSA3 (80 Gb, SATA)
I believe the system uses an nVidia nForce chipset

The problem started happening after upgrading to 8.10. I have now intrepid installed but have to boot the system with the 2.6.24-21-generic kernel (the 2.6.27-7-generic produces the error).

If I type 'exit' at the initramfs shell, booting continues normally, and I can even get a graphical display login. However both before typing 'exit' and after that (i.e. at all times) the system emits error/warning messages at 5-7 second intervals (see attached dmesg/kernel.log). During these intervals the system seem to do some checks on the drives (the light on the CD/DVD drive turns on and off, and I can hear a noise, similar to the one during a normal boot when the drive is checked for media).

Revision history for this message
FernanAguero (fernan-ciudad) wrote :
Revision history for this message
FernanAguero (fernan-ciudad) wrote :
Revision history for this message
FernanAguero (fernan-ciudad) wrote :
Revision history for this message
POIRIER David (poirier-david2) wrote :

i have repported this problems in Bug #294377

rootdelay=90 is ok for my computer:

fujitsu-siemens celsius 610 serverboard
motherboard is TYAN Srverboard Thunder i7505 (S2665)
fsb chipset( northbridge) intel i705
scsi adaptec 7902 dual channel

thanks

Revision history for this message
SpinningAround (spinningaround-deactivatedaccount) wrote :

Have the same problem tried adding rootdelay=200 but no sucess, it stoped at SD 6.0.0.0 (comment unsure) SCSI

Revision history for this message
SpinningAround (spinningaround-deactivatedaccount) wrote :
Revision history for this message
SpinningAround (spinningaround-deactivatedaccount) wrote :

Forgot to mention, above files are from LiveCD

Revision history for this message
POIRIER David (poirier-david2) wrote :

Hie,

For my system adding rootdelay=90 solve the problem

after adding in the menu.lst in the kernel line
rootdelay=90
have you update grub ?
You must make it for change the boot option ( apply the change)

in a terminal
sudo update-grub

 i have an other computer which the system( a few older)

Motherboard Asus a7n8x-x
chipset fsb (northbridge) nvidia force2

I have a problem like your,(see attached dmseg/kernel.log) for boot
ubuntu 8.10 intrepid ibex kernel 2-6-27-7

boot options without quiet splash solve the problem

Le samedi 08 novembre 2008 à 17:32 +0000, FernanAguero a écrit :
> I have the same problem, and adding rootdelay=90 didn't solve the
> problem.
>
> My system:
> Dell Optiplex 740n
> CPU: AMD 64 Athlon X2 Dual 3800+ 2.00 GHz
> HD: WDC WD800JD-75MSA3 (80 Gb, SATA)
> I believe the system uses an nVidia nForce chipset
>
> The problem started happening after upgrading to 8.10. I have now
> intrepid installed but have to boot the system with the
> 2.6.24-21-generic kernel (the 2.6.27-7-generic produces the error).
>
> If I type 'exit' at the initramfs shell, booting continues normally, and
> I can even get a graphical display login. However both before typing
> 'exit' and after that (i.e. at all times) the system emits error/warning
> messages at 5-7 second intervals (see attached dmesg/kernel.log). During
> these intervals the system seem to do some checks on the drives (the
> light on the CD/DVD drive turns on and off, and I can hear a noise,
> similar to the one during a normal boot when the drive is checked for
> media).
>
>
> ** Attachment added: "dmesg (Dell Optiplex 740, 2.6.24-21-generic)"
> http://launchpadlibrarian.net/19493286/dmesg-2.6.24-21-generic.out
>

Revision history for this message
Marcel Ibes (mibes-avaya) wrote :

I believe this issue also relates to bug: #256637

Revision history for this message
Scott Kitterman (kitterman) wrote :

That one was fixed before this problem came up. so it's certainly not the same issue.

Revision history for this message
Marcel Ibes (mibes-avaya) wrote :

What makes you say that that issue was fixed?

It still occurs even in the latest kernel release: 2.6.27-8

This was acknowledged and the issue is still being worked on. See also the linked bug in the kernel bug tracker: http://bugzilla.kernel.org/show_bug.cgi?id=11445

Revision history for this message
Scott Kitterman (kitterman) wrote :

Because it was marked Fix Released. If it's not that should be corrected.

Revision history for this message
FernanAguero (fernan-ciudad) wrote :

> Because it was marked Fix Released. If it's not that should be
> corrected.
>
> --
> Fails to find boot device in Intel D945Gnt
> https://bugs.launchpad.net/bugs/290153

Scott,

the bug was marked as affecting both the 8.10 Release Notes,
and probably other components (busy box, initramfs, linux
kernel).

Only the part of the bug that affects the '8.10 Release
Notes' was marked as 'Fixed'.

The part that affects the linux kernel was triaged and
assigned to the kernel team.

Hope that makes it clearer,

fernan

PS: I'm still waiting for a fix, 2.6.27-8 didn't help

Revision history for this message
Scott Kitterman (kitterman) wrote :

Ah. That's what I get for reading too fast. Thanks.

Changed in ubuntu-release-notes:
status: Fix Released → Confirmed
Andy Whitcroft (apw)
Changed in linux:
assignee: ubuntu-kernel-team → apw
status: Triaged → In Progress
Changed in busybox:
status: New → Invalid
status: New → Invalid
Changed in initramfs-tools:
status: New → In Progress
status: In Progress → Invalid
status: New → Invalid
Changed in linux:
assignee: nobody → apw
status: New → In Progress
Andy Whitcroft (apw)
Changed in linux:
status: In Progress → Fix Released
Changed in linux:
status: Fix Released → Confirmed
Andy Whitcroft (apw)
Changed in linux:
status: Confirmed → In Progress
Andy Whitcroft (apw)
Changed in linux:
status: In Progress → Incomplete
Steve Langasek (vorlon)
Changed in linux (Ubuntu Jaunty):
milestone: none → jaunty-updates
Changed in linux (Ubuntu Jaunty):
status: Incomplete → Confirmed
100 comments hidden view all 180 comments
Revision history for this message
Andy Whitcroft (apw) wrote :

Based on Scott's feedback here on Jaunty I am going to close the Jaunty task fixed, as the device is found there without need for modification of the boot configuration. I suspect Karmic is also fixed but is as yet untested.

Changed in linux (Ubuntu Jaunty):
status: Confirmed → Fix Released
Revision history for this message
d2globalinc (shane-2710studios) wrote :

I still have this issue in Jaunty (2.6.28-11) x86_64 when I place my sata dvd drive on the same channels as my sata (not sata2) hard drives.. So I dont know why this is being marked as fixed..

Revision history for this message
davidyu (yuyich) wrote : David YC Yu work in the customer site

I will be out of the office starting 05/03/2009 and will not return until
05/11/2009.

I'll check email daily

Revision history for this message
Scott Kitterman (kitterman) wrote : Re: [Bug 290153] Re: Fails to find boot device in Intel D945Gnt

I think fixed is too strong a term as it still takes a very long time for
the device to turn up. I think the consequences of this bug are reduced
(slow boot instead of failed boot), but the underlying defect is still
present.

Revision history for this message
Richard Kleeman (kleeman) wrote :

Fixed for me in version 2.6.28-12 of the kernel. Relative to the old kernels in 8.04 the boot time is now much faster as well.

Thanks for fixing this!

Revision history for this message
Andy Whitcroft (apw) wrote :

@Scott -- possibly yes. I was basing that on both your feedback and that of @Morgan who seems to note things improving over time. However looking at his feedback I am not sure his kernel is configured correctly. @Richard just throws more confusing in as he is now working.

@Morgan -- I notice that your later two kernels are reporting the disks as hdX devices but the 2.6.27.10 kernel reported them as scsi devices. I presume you have used some different options to compile those so that it is using different drivers to handle them.

@Richard -- could you indicate which version prior to this did not work, and if possible could you attach dmesg output for boots with both of those two for comparison.

Revision history for this message
Andy Whitcroft (apw) wrote :

@Scott -- actually could you also attach a current dmesg output from your working but very slow boot for me.

Revision history for this message
Morgan Jones (maclover201) wrote :

Hmm, I don't think I configured those kernels differently. Let me check to see if the new 2.6.29.3 works.

Revision history for this message
Morgan Jones (maclover201) wrote :

2.6.29.3 still gives those SRST failed messages.

In summary, here's what each kernel version does for me.

2.6.24-21-generic: Boots right up
2.6.27.10: SRST failed
2.6.28-rc6: SRST failed
2.6.28: SRST failed
2.6.28-11-generic: SRST failed, but boots up after 60 seconds
2.6.28.4: SRST failed
2.6.28.5: SRST failed
2.6.28.6: SRST failed
2.6.29: SRST failed
2.6.29.1: Better, but CPU sometimes stalls and I do get the SRST failed messages.
2.6.29.2: Regressed to problems of 2.6.29, with SRST failed messages
2.6.29.3: SRST failed

This is evidence of an ongoing problem. @Andy, how can I check what kind of device each kernel reports my HD as?

Attached: 2.6.29 dmesg output

Revision history for this message
Andy Whitcroft (apw) wrote :

you will find you have /dev/sd* or /dev/hd* for these kernels. and the same strings should be reported in the dmesg.

Revision history for this message
Forest (foresto) wrote :

I'm using 2.6.28-11-generic on Jaunty, and the bug is still present. (It first appeared for me with one of the Intrepid kernels; never happened with earlier releases.)

Of note, I do not have any drives on the motherboard's SATA bus. My boot device is a 3ware hardware RAID card whose driver is part of the generic kernel. Please let me know if more information from my system would help.

Changed in linux (Ubuntu Jaunty):
status: Fix Released → Confirmed
Revision history for this message
Jake (palmzealot-gmail) wrote :

I don't know if this helps or not, but I'll throw it in anyway. I had the same issue with 2.6.28-12-generic on the same Intel MB. When I tried to reinstall the kernel from the CLI, APT gave me a message about DPKG needing to be reconfigured. I followed the command it gave me (sudo dpkg --configure -a). It went through process of reconfiguring everything, including the kernel. From that point, I've been able to boot just fine, without a workaround.

Revision history for this message
gunbladeiv (gunbladeiv) wrote :

i still had the same issue after upgrade to karmic kernel of 2.6.30-10-generic. So i think the bug exist in karmic.
it does boot find when i exit the initramfs , and rootdelay=30 didnt work for me. will try to add another 30 to the rootdelay number.

Revision history for this message
Andy Whitcroft (apw) wrote :

@Morgan -- did you manage to figure out which configuration you were using for your various kernels. It might be worth do the same test with the kernels from the Mainline Kernel archive as we build those with the same options as we build the Ubuntu kernels.

@Jake -- thats rather wierd I would not expect that to make any difference at all. What version of the kernel are you running now (uname -a output).

Revision history for this message
Morgan Jones (maclover201) wrote :

@Andy- The tests I did were mainly with the mainline kernel. I got the same issues I had with the (-generic) kernels.
Two more updates here:
2.6.29.4 - SRST failed
2.6.30 - SRST failed
Still not fixed in 2.6.30, obviously. I think (in 2.6.29.4) my kernel sees my drive as an sda/sdb device. It doesn't work either way, unfortunately. I think the root of the issue is the kernel not being able to softreset the hard drive, which eventually results in a timeout and the kernel doing _something_ to manage to reset the HD and eventually boot the system.

Morgan

Revision history for this message
Andy Whitcroft (apw) wrote :

@Morgan -- would you be able to test the latest 2.6.31-rc4 mainline kernel (or later if its appeared) and post me a dmesg from that kernel. Thanks!

    https://wiki.ubuntu.com/KernelTeam/MainlineBuilds

Revision history for this message
Morgan Jones (maclover201) wrote :

Ok, I will do so when I get around to it. I am out of town until Saturday and will not be at the computer involved until Monday. I am running 2.6.30.3 mainline right now and this issue has not been fixed. But I will try.

Revision history for this message
Morgan Jones (maclover201) wrote :

This could be fixed in 2.6.31-rc4.

From the changelog:

libata: fix follow-up SRST failure path

ata_eh_reset() was missing error return handling after follow-up SRST allowing EH to continue the normal probing path after reset failure. This was discovered while testing new WD 2TB drives which take longer than 10 secs to spin up and cause the first follow-up SRST to time out.

I will actually remotely connect and start building 2.6.31-rc4 now. I will remote reboot and post the dmesg by the end of today. Ignore my previous message.

Revision history for this message
Morgan Jones (maclover201) wrote :

@Andy - Do you know of a boot param that increases dmesg buffersize? I can't get the full log from 2.6.31-rc4 as it is truncated.

Thanks! Morgan

Revision history for this message
Morgan Jones (maclover201) wrote :

Full dmesg output for kernel 2.6.31-rc4

Still get the SRST failed message... but it only probes interfaces for ~60 seconds which is better.

Steve Langasek (vorlon)
Changed in linux (Ubuntu Karmic):
milestone: jaunty-updates → none
Revision history for this message
Andy Whitcroft (apw) wrote :

@Morgan Jones -- the dmesg buffer size was upped by default in the latest karmic kernels, you can also dynamically change it using the log_buf_len=nnn (this needs to be a power of 2) kernel parameter. Would you also be able to test with the 2.6.31 based kernels in Karmic and let us know how this bug stands.

Revision history for this message
manicmike (mike-better-access) wrote :

I upgraded to Karmic last night (about 16 hours ago) and it wouldn't boot.
Haven't tried the delay, and can't access the machine now (because it wouldn't boot, of course).

Revision history for this message
Andy Whitcroft (apw) wrote :

There is a commit related to link init failures in the final karmic kernel which may be relevant. So it may be worth testing with 2.6.31-14.46:

  commit e827d71dd6d39b3e28a519cb0bace9634d42aa7d
  Author: Tejun Heo <email address hidden>
  Date: Tue Oct 6 17:08:40 2009 +0900

    libata: fix incorrect link online check during probe

    commit 3b761d3d437cffcaf160a5d37eb6b3b186e491d5 upstream.

    While trying to work around spurious detection retries for
    non-existent devices on slave links, commit
    816ab89782ac139a8b65147cca990822bb7e8675 incorrectly added link
    offline check logic before ata_eh_thaw() was called. This means that
    if an occupied link goes down briefly at the time that offline check
    was performed, device class will be cleared to ATA_DEV_NONE and libata
    wouldn't retry thus failing detection of the device.

Changed in linux (Ubuntu Karmic):
milestone: none → karmic-updates
status: Confirmed → Incomplete
Changed in linux (Ubuntu Jaunty):
assignee: Andy Whitcroft (apw) → nobody
Changed in linux (Ubuntu Intrepid):
assignee: Andy Whitcroft (apw) → nobody
status: In Progress → Confirmed
Revision history for this message
Pete Graner (pgraner) wrote :

@Scott K. can you please test per comment #163 and let us know if that patch fixed the issue.

Thanks

Revision history for this message
Scott Kitterman (kitterman) wrote :

I upgraded the affected box today and it seems similar to Jaunty. It does boot without the rootdelay workaround that I had to use in Intrepid, but is still very slow

[ 1.088696] sda: sda1 sda2 < sda5 >
[ 1.131086] sd 2:0:0:0: [sda] Attached SCSI disk
[ 5.944009] ata4: link is slow to respond, please be patient (ready=0)
[ 10.928009] ata4: device not ready (errno=-16), forcing hardreset
[ 16.124011] ata4: link is slow to respond, please be patient (ready=0)
[ 20.940009] ata4: SRST failed (errno=-16)
[ 26.136008] ata4: link is slow to respond, please be patient (ready=0)
[ 30.952009] ata4: SRST failed (errno=-16)
[ 36.148011] ata4: link is slow to respond, please be patient (ready=0)
[ 65.996009] ata4: SRST failed (errno=-16)
[ 71.024009] ata4: SRST failed (errno=-16)
[ 71.024013] ata4: reset failed, giving up

I'm attaching /var/log/dmesg. Please let me know if you need anything else.

Revision history for this message
Scott Kitterman (kitterman) wrote : Appears the problem still exists in Karmic
  • dmesg Edit (38.8 KiB, application/octet-stream; name="dmesg")

I upgraded the system that caused me to file this bug to Karmic today and
it appears similar to Jaunty. It takes forever to boot, but gets there
eventually without the root delay work around.

[ 1.088696] sda: sda1 sda2 < sda5 >
[ 1.131086] sd 2:0:0:0: [sda] Attached SCSI disk
[ 5.944009] ata4: link is slow to respond, please be patient (ready=0)
[ 10.928009] ata4: device not ready (errno=-16), forcing hardreset
[ 16.124011] ata4: link is slow to respond, please be patient (ready=0)
[ 20.940009] ata4: SRST failed (errno=-16)
[ 26.136008] ata4: link is slow to respond, please be patient (ready=0)
[ 30.952009] ata4: SRST failed (errno=-16)
[ 36.148011] ata4: link is slow to respond, please be patient (ready=0)
[ 65.996009] ata4: SRST failed (errno=-16)
[ 71.024009] ata4: SRST failed (errno=-16)
[ 71.024013] ata4: reset failed, giving up

/var/log/dmesg attached.

Changed in linux (Ubuntu Karmic):
status: Incomplete → Confirmed
Revision history for this message
Magnes (magnesus2) wrote :

In Karmic my problem went (almost) away. My dvd-rom works flawlessly (but I have to do more tests). System boots with every hard disk configuration. The only remaining problem: while booting there is a lot of text about "searching" for sda1, sda2 etc.under the white Ubuntu logo for a few seconds. But system boots fast - in 30 seconds.

Revision history for this message
woolysheep (woolysheep) wrote :

i've got similar issue since Ubuntu Karmic (tried Daily build/beta), I am using a VIA VT8237R/VT8237R Plus Chipset wich Supports dual channel native SATA controller up to 1.5Gb/s with RAID 0 or RAID 1. I am running "fake"raid 1 at the moment.

waiting longer or setting longer boot delay doesn't work for me, as well using options like all_ide_general (forgot the order now)

Installed Ubuntu 9.04 and it works perfectly again, will stick with this version for the moment. (also because i have problems with Grub 2 installing on my dmraid)

tags: added: iso-testing
Revision history for this message
davidyu (yuyich) wrote : David YC Yu not in office

I will be out of the office starting 11/01/2009 and will not return until
11/30/2009.

I'll check email daily

Revision history for this message
ginalfa (ginalfa) wrote :

I am also experiencing a similar problem on my Asrock P4i65GV (intel ICH5) chipset.
I know that in in intrepid and jaunty was necessary to blacklist intel_agp module to make that mobo working.
With karmik the only solution to make live CD bootable (and installable) is to expand inittramfs and squashfs filesystems and manually modify /etc/modprobe.d/blacklist.conf files in both images, (by adding intel_agp) recreate fs and the iso.
here attached my lspci output

Revision history for this message
Scott Kitterman (kitterman) wrote : Re: [Bug 290153] Re: Fails to find boot device in Intel D945Gnt

>I am also experiencing a similar problem on my Asrock P4i65GV (intel ICH5) chipset.

The problem described in this comment is a different bug. Please file a new bug for this.

tags: added: intrepid jaunty karmic
removed: regression-potential
Revision history for this message
Scott Kitterman (kitterman) wrote :

Since it worked in Hardy, isn't it still regression potential? I have one
box on Hardy due to this buh.

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

Thank you for reporting this bug to Ubuntu. Intrepid Ibex 8.10 reached EOL on 30 March 2010.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please feel free to report any other bugs you may find.
Thank you.

Changed in linux (Ubuntu Intrepid):
status: Confirmed → Won't Fix
Revision history for this message
Sergio Zanchetta (primes2h) wrote :

I've just realized I made a mistake, Intrepid Ibex 8.10 "will reach" EOL on 30 "APRIL" 2010.

Sorry for this.

Anyway, I think that one month doesn't make any difference now.

Revision history for this message
Loïc Minier (lool) wrote :

Closing this oldish release notes task; I understand that the scope of the problem is smaller now, since the systems actually boot albeit slowly; so I'm closing the task, but please reopen if it necessary.

Changed in ubuntu-release-notes:
status: Confirmed → Invalid
tags: added: cherry-pick kernel-uncat
Revision history for this message
Forest (foresto) wrote :

This problem went away for me in the more recent Karmic kernels, but after upgrading to Lucid, it has resurfaced. I am once again intermittently getting dumped to a busybox prompt instead of booting.

3ware 8006-2LP RAID controller
Intel P35 chipset

Revision history for this message
Scott Kitterman (kitterman) wrote :

Different Chipset. Different bug.

Andy Whitcroft (apw)
Changed in linux (Ubuntu):
assignee: Andy Whitcroft (apw) → nobody
Changed in linux (Ubuntu Karmic):
assignee: Andy Whitcroft (apw) → nobody
Revision history for this message
Brad Figg (brad-figg) wrote :

Jaunty is no longer supported.

Changed in linux (Ubuntu Jaunty):
milestone: jaunty-updates → none
status: Confirmed → Won't Fix
Revision history for this message
Seth Forshee (sforshee) wrote :

Karmic is no longer supported. Please test to see whether or not this problem still exists in natty. Thanks!

Changed in linux (Ubuntu Karmic):
milestone: karmic-updates → none
status: Confirmed → Won't Fix
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Brad Figg (brad-figg) wrote : Unsupported series, setting status to "Won't Fix".

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: Incomplete → Won't Fix
Displaying first 40 and last 40 comments. View all 180 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.