root filesystem fails to mount

On old kernel from breezy it dumps:

Begin: Waiting for root file system... ...
Segmentation fault

and then complaints about non-existing /dev/sda1

So, this affects (a) fresh installs, (b) system upgraded from Breezy, (c) Breezy's kernel with Dapper's userspace (the last of which isn't really supported anyway, but still); I doubt it's an installer bug. udev seems a more likely place to start.

Scott, can you check out whether this is a udev bug or whether it's somewhere else?

I have almost the exact same confiration at home (Asus A8N with nForce chipset) and it works for me.

Please provide output of "cat /proc/modules" at the ALERT" prompt, along with output of "ls /sys/bus/scsi*"

Thanks

I cannot give you all output of cat /proc/modules because I would have to write it down on a piece of paper ;-) I'll try to run it under Qemu or smth. although I never do that before. So, cat /proc/modules gives nothing relevant to scsi except:

sata_nv 125480 Life (many zeroes and f's after that)

cat /sys/bus/scsi gives nothing at all.

In dmesg I noticed an interesting message (about networking which also don't work):
forcedeth: probe of 0000:0a.0 failed with error -22

Later I'll try to provide with output of that commands from dapper - after I install deboostrap breezy and upgrade it to dapper.

No, please do as I asked; do not run this under qemu.

If you need to write down the module names on a piece of paper, please do exactly that.

Also I did not ask for "cat /sys/bus/scsi", I asked for "ls /sys/bus/scsi"

I need you to follow instructions precisely, trying to short-cut it means you will miss information out that I need. Do not assume that information is irrelevant, because if you knew how to fix this and what was relevant, you would not need my help to fix it.

At the ALERT prompt, please do the following commands, noting down the output precisely on a piece of paper, then provide it in this bug report:

cat /proc/modules (I only need the module names here)
ls /sys/bus/scsi/devices
ls /sys/class/scsi_device
ls /sys/block

Thanks

And please do this from a Dapper Flight 4 CD or LiveCD, not a breezy cd (where I'm not sure we had kernel support for this chipset)

OK, thx for your advices. If you don't mind I made couple of screen shots with my digital camera. Here you have output of cat /proc/modules:
http://img162.imageshack.us/img162/1779/p30300240gr.jpg
http://img45.imageshack.us/img45/2860/p30300250js.jpg
http://img162.imageshack.us/img162/466/p30300265cj.jpg
http://img45.imageshack.us/img45/1889/p30300278gj.jpg

output of the rest of commands is on
http://img45.imageshack.us/img45/4788/p30300289ph.jpg

And let me clarify that installer does not:
- detect network interfaces
- find harddrives connected to SATA interface
while presenting partitioning screen (no drives and partitions are presented)

An installed (upgraded from breezy) dapper system does not boot - it does not see /dev/sda1 and prints ALERT prompt.

Breezy works flawlessly and detects everything without fuss.

Scott, do you need any of my help? I would like to help you as much as I can to resolve this bug. It stops me from using dapper on my computer.

Ben, this looks like a kernel bug to me.

udev has correctly loaded sata_nv (where the user says their drive should appear), along with amd74xx (which is the Plain-old-ATA driver I'd expect for this motherboard).

No scsi devices are showing up, either under /sys/bus/scsi/devices (which exists, but is empty) or /sys/class/scsi_device (again exists but is empty).

I don't see a udev bug here because it's done everything it has been told to, and there's no evidence it's gone wrong. It looks like the driver isn't working correctly.

I also have this problem after upgrading on 2/13/06. If there is anything I can do to help with testing or showing output I would be more than glad to help.

i am not sure how to change the product but I think it is on the linux-source-2.6.15 kernel just as cayco reported. Please let me know if there is anything I can do to help.

I'm going to need dmesg output. Please boot a liveCD, and obtain the output of dmesg:

dmesg > dmesg.txt

Send me the dmesg.txt file. Easiest way to do this is to save it to a USB disk or similar, and reboot to where you can attach that file to the bug report.

Note, I have n nForce4 motherboard aswell, and a 300G SATA disk attached to it, and it is working fine (Athlon64).

So this is a rare case. What I'd like to know is, is the disk actually an SATA disk, or is it a normal PATA disk?

Dnia 23-03-2006, czw o godzinie 20:28 +0000, Ben Collins napisał(a):
> Public bug report changed:
> https://launchpad.net/malone/bugs/33269
>
> Comment:
> I'm going to need dmesg output. Please boot a liveCD, and obtain the
> output of dmesg:

I'll try to do some real screen shots with my digital camera

>
> dmesg > dmesg.txt
>
> Send me the dmesg.txt file. Easiest way to do this is to save it to a
> USB disk or similar, and reboot to where you can attach that file to the
> bug report.

This is not possible because USB doesn't work at all. Nothing works - no
HDs, no even floppy!

> So this is a rare case. What I'd like to know is, is the disk actually
> an SATA disk, or is it a normal PATA disk?

This is SATA disk connected with SATA connection.

It is not very rare problem - many people has experiencing it. You can
even read about it in Debian Bug:
http://lists.debian.org/debian-kernel/2006/03/msg00422.html

regards

Krzysztof Kajkowski

Good news - I am writing this comment from Dapper ;-)

I managed to boot it and run flawlessly by addind this options to kernel at boot:

acpi=off apm=on noapic

Dapper now works.

I've made some screen shots on messages appearing on non succesful boot. Do you still need them?

Screen shots from booting broken Dapper kernel:

http://img530.imageshack.us/img530/9080/p32900418po.jpg
http://img530.imageshack.us/img530/9615/p32900429sy.jpg
http://img82.imageshack.us/img82/2282/p32900430xq.jpg
http://img82.imageshack.us/img82/3143/p32900446ky.jpg
http://img82.imageshack.us/img82/4848/p32900454pg.jpg
http://img82.imageshack.us/img82/6847/p32900467og.jpg
http://img530.imageshack.us/img530/4871/p32900474vc.jpg
http://img530.imageshack.us/img530/4871/p32900474vc.jpg

I'm suffering from the same bug.

It seems to be PnP related tho, since disabling PnP in the bios of my motherboard solved most problems for me & Ruler (see link to ubuntuforums below).

The hardware is an Asus K8N4-E deluxe.

I have to use the following kernel parameters in grub to get it to boot:

"/boot/vmlinuz-2.6.15-21-386 root=/dev/sda2 ro quiet acpi=off irqpoll"

This is the list of pci devices in my system:

ochal@Fluffy:~$ lspci
0000:00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
0000:00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
0000:00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
0000:00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
0000:00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
0000:00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
0000:00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
0000:00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
0000:00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
0000:00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
0000:00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
0000:00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
0000:00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
0000:00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
0000:00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
0000:01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5b63
0000:01:00.1 Display controller: ATI Technologies Inc: Unknown device 5b73
0000:05:06.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
0000:05:06.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
0000:05:06.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01)
0000:05:06.4 FireWire (IEEE 1394): ALi Corporation M5253 P1394 OHCI 1.1 Controller
0000:05:07.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
0000:05:07.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
0000:05:08.0 RAID bus controller: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host Controller (rev 02)
0000:05:0a.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
0000:05:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)

-------------------------------

dmesg output:

d
[ 48.652775] nv_sata: Secondary device removed
[ 48.653770] nv_sata: Primary device added
[ 48.653772] nv_sata: Primary device removed
[ 48.653773] nv_sata: Sec...

i have a same problem
mobo:Asus K8N4.
i hop in Edgy its work fine

This bug may be fixed in the current edgy developement system. In an effort to track this bug to our latest distribution, it is being targeted for edgy.

Please confirm whether this bug exists in edgy. If not, then please re-attach all related output (e.g. dmesg, oops output) while under edgy.

Latest Edgy CD's can be downloaded from:

http://cdimage.ubuntu.com/releases/edgy/knot-1/

If this image does not boot from you, you can also download a current daily build from:

http://cdimage.ubuntu.com/daily-live/current/

Note that it may only be necessary to boot the LiveCD to see if your bug is fixed. In this case, you do not need to upgrade your installed system at all to confirm it. Certain bugs may require that you do an actual installation.

I am having a very similar problem. I am using a Pentium D 805 dual core on a ECS RC410L/800-Mv2.0, 3 IDE HDDs, 0 SATA devices, 1 IDE HDD. I have tried installing from both the 6.06 alternate install CD and the 6.06 desktop CD. In either case, the system works fine, but with only 1 CPU used. When I apt-get install linux-image-smp (and the associated restricted modules), the system will begin to boot, but stop at "mounting root file system..." and never respond again, even after long (multiple hour) waits.

I can boot back into the 386 uniprocessor kernel just fine, so it does not prevent me from using the system. I then tried doing a dist-upgrade to edgy; and, this also works with the default UP 386 kernel. But, apt-get'ing the 686 smp kernel again stops at the same place.

I tried using kpkg to build my own kernel and, again, had the same failure. I have tried dpkg-reconfigure udev before rebooting into the new kernel, to no avail.

Following is the dmesg output:
-------------------------------------------------
[17179569.184000] Linux version 2.6.17-6-386 (root@rothera) (gcc version 4.1.2 20060715 (prerelease) (Ubuntu 4.1.1-9ubuntu1)) #2 Fri Aug 11 22:05:08 UTC 2006
[17179569.184000] BIOS-provided physical RAM map:
[17179569.184000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[17179569.184000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[17179569.184000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
[17179569.184000] BIOS-e820: 0000000000100000 - 000000003bfd0000 (usable)
[17179569.184000] BIOS-e820: 000000003bfd0000 - 000000003bfde000 (ACPI data)
[17179569.184000] BIOS-e820: 000000003bfde000 - 000000003c000000 (ACPI NVS)
[17179569.184000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[17179569.184000] BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
[17179569.184000] 63MB HIGHMEM available.
[17179569.184000] 896MB LOWMEM available.
[17179569.184000] found SMP MP-table at 000ff780
[17179569.184000] On node 0 totalpages: 245712
[17179569.184000] DMA zone: 4096 pages, LIFO batch:0
[17179569.184000] Normal zone: 225280 pages, LIFO batch:31
[17179569.184000] HighMem zone: 16336 pages, LIFO batch:3
[17179569.184000] DMI 2.3 present.
[17179569.184000] ACPI: RSDP (v000 ACPIAM ) @ 0x000f87f0
[17179569.184000] ACPI: RSDT (v001 A M I OEMRSDT 0x02000615 MSFT 0x00000097) @ 0x3bfd0000
[17179569.184000] ACPI: FADT (v002 A M I OEMFACP 0x02000615 MSFT 0x00000097) @ 0x3bfd0200
[17179569.184000] ACPI: MADT (v001 A M I OEMAPIC 0x02000615 MSFT 0x00000097) @ 0x3bfd0390
[17179569.184000] ACPI: MCFG (v001 A M I OEMMCFG 0x02000615 MSFT 0x00000097) @ 0x3bfd0400
[17179569.184000] ACPI: OEMB (v001 A M I AMI_OEM 0x02000615 MSFT 0x00000097) @ 0x3bfde040
[17179569.184000] ACPI: HPET (v001 A M I OEMHPET 0x02000615 MSFT 0x00000097) @ 0x3bfd49d0
[17179569.184000] ACPI: DSDT (v001 RC410 RC410L 0x00000000 INTL 0x02002026) @ 0x00000000
[17179569.184000] ATI board detected. Disabling timer routing over 8254.
[17179569.184000] ACPI: PM-Timer IO Port: 0x808
[17179569.184000] ACPI: Local APIC address 0xfee00000
[17179569.184000] ACPI: LAPIC (acpi_id[0x01] lapic_i...

I having the same problem as justinchudgar after upgrading to edgy. The 386 kernel boots fine, but the generic hangs when it's unable to mount the root filesystem. It's a Asus A8N-E motherboard with a X2 4400+ CPU. After a while I'm dropped to a shell in the initrd image, and can see that the sata_nv module isn't loaded. I'm not sure if other modules are missing. Let me know what other info you need. I will try with some of the kernel parameters mentions above, and report if anyone helps.

(comment added to main bug description)

After opening question #7704 here: https://answers.launchpad.net/ubuntu/+question/7704 I was told that I have hit this bug, so here goes.

This concerns Xubuntu v7.04 alternate CD, with linux v2.6.20.

In summary, I have an old Toshiba Satellite 200CDS laptop, with P166 processor with 48Mb memory, a floppy, one 2Gb IDE HD, and a CD-ROM drive. I created a fresh partition table and partitions on the hard drive, and after several attempts, and finally by using these kernel options : acpi=off pci=biosirq ide=nodma idebus=66, I was able to sucessully install from the Xubuntu v7.04 alternate CD. However, upon reboot I found that it failed to mount the root filesystem. When I looked in /dev, there were no /dev/hd* or /dev/sd* devices.

Not sure if this is relevant, but: when I booted from another linux live CD (DSL) and checked the hard disk, I could see that /dev/hda, /dev/hda1, etc all existed as they should, but there was no /dev/disks directory where the uuid links to the partitions are supposed to be. I reinstalled grub, and that fixed the missing links, but it didn't solve the main problem of being able to boot from the HD.

Thanks,
- Steve

[Expired for linux-source-2.6.17 (Ubuntu) because there has been no activity for 60 days.]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Now that the 7.10 Gutsy Gibbon release of Ubuntu is out, we were wondering if you can still reproduce this issue. Could you please download and try the new version of Ubuntu from http://www.ubuntu.com/getubuntu/download and report back your results. If the issue is still present in the new release, please attach the following information:

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

Please be sure to attach each file as a separate attachment. For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

I'm sorry, I can no longer test this bug, I don't have the laptop any more.

- Steve

Leann Ogasawara wrote:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. Now that the 7.10 Gutsy Gibbon release of Ubuntu is out,
> we were wondering if you can still reproduce this issue. Could you
> please download and try the new version of Ubuntu from
> http://www.ubuntu.com/getubuntu/download and report back your results.
> If the issue is still present in the new release, please attach the
> following information:
>
> * uname -a > uname-a.log
> * cat /proc/version_signature > version.log
> * dmesg > dmesg.log
> * sudo lspci -vvnn > lspci-vvnn.log
>
> Please be sure to attach each file as a separate attachment. For more
> information regarding the kernel team bug policy, please refer to
> https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we
> appreciate your help and feedback.
>
> ** Changed in: linux-source-2.6.20 (Ubuntu)
> Status: New => Incomplete
>
>

I can't say for certain if this is the same issue - I upgraded to the gibbon yesterday, and upon a reboot the system would not come up. The recovery kernel (2.6.22-14-generic, I think) shows:

BEGIN: Waiting for root filesystem

and it never boots. The Edgy kernel, 2.6.20-16, boots fine. I thought this to be an issue with the initrd image, so I reinstalled the 2.6.22-14-generic kernel, which did rebuild the image, but the problem persists.

This is indeed a laptop, and it has a SATA drive that registers as /dev/sda. I only started experiencing this with the upgrade to gutsy, so that is why I can't say if it's related or should be a different bug.

I am experiencing the same problem after upgrading to Gutsy on Sun Fire x2200 server. The Feisty kernel boots fine. Gutsy gets stuck at mounting the root filesystem and gives a BusyBox prompt.

I'm using Gutsy. I have created (qcow) qemu images from Feisty alternate installer, Gutsy alternate installer and Gutsy JeOS. All these images fail to mount the root filesystem.

I have attached a screenshot where booting the feisty image fails (I booted without quiet splash).

I was able to boot the Fedora 7 image I downloaded from oszoo.org :
http://www.oszoo.org/wiki/index.php/Fedora7.img

I'm experiencing the same problem with kqemu,qemu and kvm :
qemu -m 512 feisty.img -no-acpi -snapshot -std-vga -no-kqemu
qemu -m 512 feisty.img -no-acpi -snapshot -std-vga
kvm -m 512 feisty.img -no-acpi -snapshot -std-vga

I had to use this workaround to be able to create the qemu images :
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/120316/comments/7

IMHO the following bugs might be related :
https://bugs.launchpad.net/ubuntu-jeos/+bug/163113
https://bugs.launchpad.net/ubuntu/+bug/163140
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/120316
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/33269

Hi All,

There hasn't been any recent activity in this bug for a while and we were just wondering if this issue still exists in the latest Hardy Alpha release? The Hardy Heron Alpha series contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ .

Also note that we'll keep this report open against the actively developed kernel bug against 2.6.20, 2.6.17, and 2.6.15 this will be closed. Thanks.

I'm not even sure that my comment on this bug relates to the original issue
- but as far as I know yes, this still exists, at least with the latest
available Gutsy Kernel.... Anything 2.6.22 or newer fails to boot on my
laptop, complaining that it can't mount the root filesystem. 2.6.20 or older
works fine. It is a bit frustrating, as there is nothing unusual about this
laptop (Acer with an intel board, i915), but yet I seem to be one of the
only people experiencing this issue. Google searches have turned up a few
other people with the same problem, but it doesn't appear to be wide spread
enough that anyone has fixed it.

Randall

On Mon, Mar 3, 2008 at 8:43 PM, Leann Ogasawara <email address hidden> wrote:

> Hi All,
>
> There hasn't been any recent activity in this bug for a while and we
> were just wondering if this issue still exists in the latest Hardy Alpha
> release? The Hardy Heron Alpha series contains an updated version of
> the kernel. You can download and try the new Hardy Heron Alpha release
> from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to
> then test the new kernel via the LiveCD. If you can, please verify if
> this bug still exists or not and report back your results. General
> information regarding the release can also be found here:
> http://www.ubuntu.com/testing/ .
>
> Also note that we'll keep this report open against the actively
> developed kernel bug against 2.6.20, 2.6.17, and 2.6.15 this will be
> closed. Thanks.
>
> ** Also affects: linux (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Changed in: linux (Ubuntu)
> Status: New => Incomplete
>
> ** Changed in: linux-source-2.6.15 (Ubuntu)
> Status: Incomplete => Won't Fix
>
> ** Changed in: linux-source-2.6.20 (Ubuntu)
> Status: Incomplete => Won't Fix
>
> --
> root filesystem fails to mount (sata_nv module is loaded)
> https://bugs.launchpad.net/bugs/33269
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Randall

I replaced the machine with said controller for some new kit, can't test if this issue still exist.

I have just experienced the "waiting for root file system" bug after upgrading from Gutsy to Hardy. I can fix the bug by booting the 386 kernel instead of the generic kernel (2.6.24-12). So it seems to be specific to SMP, consistent with earlier reports, and is NOT fixed in Hardy. Any tips would be appreciated!

(For the record, I am running Hardy on a HP xw4600, with two SATA drives, booting off the first drive, not using RAID, the problem does not appear to be a volume_id issue, it's that the drives are not being detected or the module is not being loaded).

I've got the same problem:

Athlon64, VIA-Mainboard, SATA-Harddrive, Hardy Alpha6

lspci (done with gutsy):
00:00.0 Host bridge: VIA Technologies, Inc. K8T890 Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. K8T890 Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. K8T890 Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. K8T890 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. K8T890 Host Bridge
00:00.5 PIC: VIA Technologies, Inc. K8T890 I/O APIC Interrupt Controller
00:00.7 Host bridge: VIA Technologies, Inc. K8T890 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
00:02.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.1 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.2 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.3 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:0f.0 IDE interface: VIA Technologies, Inc. VT8251 AHCI/SATA 4-Port Controller
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8251 PCI to ISA Bridge
00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 7c)
00:13.0 PCI bridge: VIA Technologies, Inc. VT8251 Host Bridge
00:13.1 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCI Bridge
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
02:00.0 VGA compatible controller: ATI Technologies Inc Unknown device 94c3
02:00.1 Audio device: ATI Technologies Inc Unknown device aa10
07:00.0 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
07:00.1 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
07:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio Controller

Gentoo runs perfectly ;-)

appending pci=nomsi to the kernel-options in grub.conf works for my setup, at least on the 32bit-system, reinstalling the 64bit-version right now.

Running "update-initramfs -k 2.6.24-12-generic -u" fixed the problem for me. Anyone who can run the 386 kernel but not the generic kernel should try that; not sure why it isn't done automatically when the kernel is upgraded.

By the way, how to unsubscribe from a bug? My inbox is overflowing :)

I ran into this bug after upgrading from Gutsy to Hardy last night. mikeday's suggestion (run "update-initramfs -k 2.6.24-12-generic -u") fixed the problem for me.

I just encountered the same problem as Barrakketh and miekday after updating from 7.10 to 8.04 beta.
Means I could only boot Ubuntu with the i386 kernel using only one core of my Intel Q6600 Quadcore machine.

Updating initramfs fixed the problem for me, too.

Thanks mikeday!

Experiencing the same symptoms in a 64bit system based on ASUS A8V-E Deluxe, with two identical SATA 250 Gb disks set as RAID1 and partitioned so that /, /boot, /home and swap are on separate partitions after upgrade from Gutsy to Hardy (on April 7th). Loading, please wait... (I've disabled the splash from boot) and then BusyBox: ALERT! /dev/md2 does not exist (= root partition). This only happens when I let it boot to system based on kernel 2.6.24-15, but if I choose 2.6.22-based kernel from GRUB menu, the problem does not show up.

I am also experiencing difficulties booting 2.6.24-15.

ASUS P5K-E with 3 SATA drives in RAID-1 containing root and boot. 2.6.22-14 (and lower) boot fine. I have tried 2.6.24-12 through 2.6.24-15 and always get the following message:

"checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd"

I have tried "update-initramfs -k 2.6.24-15-generic -u" but I still get the message above.

I am able to boot from a desktop/live CD (2.6.24) and install mdadm then mount the RAID successfully, but I can't seem to boot 2.6.24 in any other way.

Confirmed the problem still exists for me on 2.6.24-16.

  "checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd"

Nobody else seems to be getting the above message -- I am attaching my image to this comment.

For more information, the machine is a Core2 Duo and I am running the 64-bit version of Hardy.

I have tried appending the following at boot: acpi=off irqpoll apm=on noapic

I note that this thread appears similar to that of bug #32123. Based on that discussion, I have also tried "sudo dpkg-reconfigure linux-image-2.6.24-16-generic" with no success.

Is there something else I should try?

I have a similar issue which I added here https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/201483. I'm not sure how close this issue is but I get trapped in BusyBox after I update to latest in Hardy. This seems to be a more active bug so I'm going to keep my status here.

Amazingly I was able to find a fix after scouring this site. The answer was in bug #75055. If I added pci=nomsi to my kernel line in the menu.lst file I was able to get past BusyBox. Unfortunately all is not well. I can't seem to get Hardy to recognize my ipod and it freezes occasionally. I'm going to turn off compiz effects and see if that is the source of the freezes.

Thanks for the suggestion. "pci=nomsi" does not work for me. I am going to try generating a new 2.6.22 image to see if that works (I don't think I have created a 2.6.22 since the move to hardy) - this should tell me whether the problem is in creating the images or if the problem is in loading them.

In my test, 2.6.22 was re-created fine.

I compiled a custom 2.6.24 kernel to get around the "bad gzip magic numbers" problem I was having. Unfortunately, I still can not use 3d acceleration or sound with this new compiled kernel - I guess I'll be watching for 2.6.24-17 generic. Hardy releases in 3-days ... really?

I am leaving this thread now to look for solutions for my new 3d and sound issues - but I will be happy to provide test results or other information if someone is interested in the 2.6.24-16 issues.

Hello Dwayne,

you are not alone, I run into the initramfs problem as well. Just a question, are you by any chace using lilo (as I do)? Just asking due to this http://lkml.org/lkml/2006/9/24/50

Cheers,
Bernd

Thanks for the link, Bernd.

Yes, I am running lilo.

It is worth noting that the file I've been using since building my kernel (shows up as 2.6.24.3) is actually quite large. It probably shouldn't be, but even the 2.6.22 files are over 8 megabytes:

-rw-r--r-- 1 root root 8564557 2008-04-18 00:52 initrd.img-2.6.22-14-generic
-rw-r--r-- 1 root root 8562568 2008-04-01 07:20 initrd.img-2.6.22-14-generic.bak
-rw-r--r-- 1 root root 8943650 2008-04-22 01:33 initrd.img-2.6.24-16-generic
-rw-r--r-- 1 root root 8872726 2008-04-19 11:13 initrd.img-2.6.24-16-generic.bak
-rw-r--r-- 1 root root 44920220 2008-04-22 07:21 initrd.img-2.6.24.3
-rw-r--r-- 1 root root 44919345 2008-04-21 19:11 initrd.img-2.6.24.3.bak

The 2.6.24-16 files above don't work -- all the others do.

Hello Dwayne,

I also had to read Denis' posting several times - it was a bit confusing to read. But I think not the size of initramfs is important, but the size of the kernel. Well, 2.6.24-15-generic is still well below the 3MB limit of Denis' findings, but 2.6.24 is definitely larger than 2.6.22 and until we figure out the root of the problem we don't know what is causing this limit at all...

Cheers,
Bernd

Hi,

I believe I am having a similar problem, although I do not have RAID on my system. Booting my custom built 2.6.22 works fine, but booting the current kernel (2.6.24-16 I believe) results in a shell and being told that the disk cannot be mounted because the device or resource is busy. I have put a bit more detail here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/220358

Rob

Bernd, Dwayne,
yours seems to be a different bug:
https://bugs.launchpad.net/ubuntu/+source/lilo/+bug/221664

Thanks, Michael (and Bernd). Confirming that adding "large-memory" to lilo.conf does resolve the issue for me.

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

I seem to have similar problems please check out.

https://bugs.launchpad.net/ubuntu/+bug/284774

I am using kubuntu 8.10

I've just upgraded from hardy to 8.10 via the dist-upgrade and received this problem.

I unplugged all hard disks I didn't need and then tried to install 8.10 from CD, that worked just fine... except, the whole point of the machine is the RAID file share, so I plugged the drives back in, and it hangs on boot, intramfs error, says a UUID doesn't exist.

I have upgraded to the latest 2.6.27 kernel that's in the 8.10 updates, and that was no help.

Can anyone tell me how to manually use the old working kernel? I originally thought it was an upgrade problem, so I did a fresh install, and now grub no longer shows older kernels that i'd upgraded from. I believe it may work again if I go back to the way things were, but I'd rather just temporarily back down the kernel than reinstall hardy. The background image in intrepid is so much cooler. ;)

well, if i wait long enough at the intramfs screen i can type return or exit and that seems to kick me into gdm, and then everything works as i need it to... except, i still don't have mdadm recognizing the drives. fdisk -l shows all the drives, but mdadm won't assemble the array, even manually.

I've just upgraded from 8.04 to 8.10 and know I have this problem. My computer is Athlon X2, nforce (don't know which version). I'll try to boot using older kernel, but it looks like I might have to reinstall the system. :(

okay, i had several things to blame when this problem occured... I was assuming it was related to the SATA RAID array, because when I unplug that array it boots just fine. But, the actual error gives a UUID of the IDE disk in my system. The UUID is correct for the boot partition, /boot/grub/menu.lst and /etc/fstab match, and everything works fine if don't have the SATA drives plugged in. But, if I plug in the SATA drives, then it gets the intramfs prompt and hangs for at least an actual minute, probably more like three minutes. After it's done hanging, it displays a message about md0 being made active. Then I have to type anything on the keyboard and hit return and the system will continue booting normally.

My RAID-6 is made up of SATA disks, twelve 750GB disks, and totals 7501GB. I previously had to upgrade to mdadm v2.6.7 in hardy to allow me to grow/expand the array, to add more space without destroying it. My guess, is that in my particular problem, the system is for some reason needing the array to be active before it can see the boot partition.

I did want to fix this, and I had dual-boot with windows on this machine just in case I needed a windows machine I wanted to have one, even though I never use it... and I was reading that wubi seem linked to a similiar problem, so I did reformat this machine and installed hardy server 8.04, everything worked fine there, and then i installed the GUI because i couldn't figure out how to do a dist-upgrade without the gui, because intrepid is not a LTS release i had to turn it on in the gui, anyway, then i upgraded to intrepid, and this intramfs problem returned. So I can say in my instance, it has nothing to do with windows partitions, and nothing to do with any radical linux software betas i'd played around with on this machine, it has everything to do with the machine not being able to initially see the IDE disk if I have this other 7TB software partition plugged in at boot.

This is very annoying when i need to reboot, and somewhat scary, and i'm handing over administration of this box soon to a less technical person. So I hope this information can help someone figure out a solution. Let me know if you need me to try something or post some logs.

1) http://ubuntuforums.org/showthread.php?t=968424 - here is a thread on ubuntuforums.org about it
2) people get the error even if they reinstall
3) only SATA drives are causing the problem
4) one person reported that plugging in SATA drives to all SATA slots resolved the problem
The problem is still in 8.10 (I had this problem with 8.04 occasionally - not always - when I had additional SATA disc), the newest kernel should be probably added to the list above.
(sorry for my English)

Definitely - I am having a similar problem on the 2.6.27-7-generic kernel, whereas the 2.6.24-19-generic works fine.
 The details are in

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/294123

It doesn't seem to be quite the same, though, so I think it wouldn't be fair to mark one or the other bug as a duplicate...

It's probably the same bug. You can start your system if you wait in the busybox for sata drives to be loaded (check dmesg from time to time) and then write "exit", hit enter and the system will start. I use main that way actually. Today's update to the kernel didn't help.

(of course I meant "mine" not "main", sorry for my English)

Sorry, but I still don't think it's exactly the same as in #294123. I did exactly what you proposed, with waiting for the drives up to 5 minutes, but they never showed up, no output in dmesg, no device nodes under /dev...
However, booting with the all_generic_ide option works, but disk access seems to be much slower than it was back in 2.6.24 with the ata_piix driver (the bug occurs for me only under kernels version 2.6.27, earlier versions work OK).

@Kissell, it sounds like you have something more similar to bug 290153. Does the workaround mentioned there (using the rootdelay boot option) work for you?

From what I understand, I have the same problem. I added bug #305714 which may be a duplicate of this one.
I have tried more or less all the different boot options suggested. I have two perhaps interesting details regarding this problem:

1) my system worked for two weeks before failing to find the hard drive. I didn't do anything to the system during that time (famous last words; I accepted the upgrade to 2.6.27-9 from 2.6.26-7, used synaptic to add development tools, added one (working) udev rule for a USB device but nothing that seems dangerous).

2) when booted from USB, the hard drive appears (but needs clicking in the desktop to mount, before that df says an error about /disk/media but clicking probably does some (re?-)mounting).

I collected some links in #305714, but most of them are also mentioned in this bug (here).
If you want me to try anything, just tell me. I have tried everything I can think of. I'm desperate.

Tested all the boot options suggested here and in related bugs (have a link list in bug #305714); nothing helps.
Tested (almost) all BIOS settings and physical connectors; nothing helps.
When the kernel boot from grub, it stops waiting for the disk after what looks like a healthy "pre-boot". Since the previously working 2.6.27-7 doesn't boot either, I suspect the problem is in some other updated sw like a driver. How do I find out the exact diff between "-7" and "-9"?
Please note that this bug appears in a lot of bug reports and in a lot of forum discussions. Each thread has similair discussions but perhaps tying it all together would help finding the solution. I think this a very severe problem affecting may people.

Reinstalled 2.6.27-7 from a 8.10 LiveCD I burned oct 29.
Worked smoothly and system started from HDD after that.
Then repeated "dangerous things":
1) install NVIDIA v177 driver: rebooted ok.
2) upgrade to 2.6.27-9 by accepting all 158 updates available is next up: rebooted ok.

I'm 100% clueless to what caused the problem before. The previous installation was made by the store where I bought the computer and I noticed a few minor differences; the grub menu doesn't appear now, it just boots (or is shown so fast I don't see it) and also the "noaperture" boot param which I needed to get rid of "aperture too small ..." seems to be there already since the "aperture beyond 4GB" message is already there.

The previous installation worked for a couple of weeks until refusing to boot. If the problem reappear I'll report back.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

No updates for 5 months and the last post said this issue was gone since Intrepid. So close it.

-Bryan

This bug report is being closed because we received no response to the previous inquiry for information. Please reopen if this is still an issue in the current Ubuntu release, Jaunty Jackalope 9.04 - http://www.ubuntu.com/getubuntu/download. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

-Bryan

I have a similiar problem here on Ubuntu Karmic Beta:
- Athlon 64 with ASRock N68PV-GS Mainboard and nForce 630 Chipset
- 2 SATA (no raid)
  - sda1: root
  - sdb1: my data

When trying to boot Ubuntu Karmic, after a few seconds it drops to a BusyBox shell with the message:

"Gave up waiting for root device. Common problems:
  - Boot args (cat /proc/cmdline
     - Check rootdelay= (did the system wait long enough?)
     - Check root= (did the system wait for the right device?)
  - Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/34be7e11-58e0-4d7a-8b13-344abf1c85ee does not exist. Dropping to a shell!"

Setting rootdelay to 130 in grub doesn't work.

Output of "cat /proc/modules":

usbhid 38208 0 - Live 0xf8026000
forcedeth 54152 0 - Live 0xf805f000

Booting recovery mode works. But doing normal boot still doesn't work after installing all updates since beta-release (now kernel 2.6.21-14).

It's also booting if I remove the quiet-option from the grub kernel command line (but not the "set quiet=1" as in the recovery mode menu entry). Why is the system not booting with the quiet-option, but without?

Same problem here. First I did an upgrade from jaunty to karmic with karmic release candidate. After reboot there was a blank screen. Thereafter, I booted with the recovery option, which drops me into busybox. Then I did a fresh install ... same problem. And the official release live-cd does not recognize my partitions, too.

My system has 3 sata disks and a total number of 6 partitions. One of them (dev/sdc1) is listed by "cat /proc/partitions", which is a ntfs-partition. The command "ls /dev/sd*" lists /dev/sda, /dev/sdb, /dev/sdc and /dev/sdc1.

After upgrading from Ubuntu 9.04->9.10 today, I got this problem on my laptop (stock Acer Aspire 5500Z). Upgrading then rebooting, I was presented with a white splash screen, frozen. After some time, it timed out and dropped me into busybox.

There is some sort of odd bug where the kernel is unable to recognize UUID of my root partition. Strangely, it **does** recognize my swap partition.

The fix:
-When booting grub, I change "root=UUID=9626db86-cfb8-4a00-9e7f-xxxxxxxxxxxxxx" to "root=/dev/sda1"
-I changed my fstab in the same way.

Same here on karmic. Last kernel i can boot with is 2.6.31-4. All newer builds get stuck at mounting the root filesystem

@Mark: Doesn't work for me. If he change UUID to /dev/sda1 in grub and fstab, I get this message and then it drops me into BusyBox:

mount: mounting /sys on /root/sys failed: No such file or directory.
... (some more of these messages, but with other directories) ...
Target filesystem doesn't have /sbin/init.

Upgraded 9.04 to 9.10 via Synaptic and recieved the same error message, "root filesystem fails to mount". Was able to solve the issue by entering root passwd, change directory to /etc, make backup copy of fstab. When I edited fstab I noticed my root partition was mounted as my storage drive. By reediting fstab, this corrected my root mount problem.

I had the same problem after upgrading to Karmic from Jaunty. Always end up with BusyBox shell.
 /proc/modules contains the following infomation:

thermal
processor
fan
fuse
dm_mirror 27008 0 - live ..
dm_log 17924 1 dm_mirror, Live 0x...
dm_mod 63432 2 dm_mirror, dm_log, Live 0xxxx

I had a IBM Xseriers 235, two SCSI disks with no RAID setting.

refer to http://ubuntuforums.org/showthread.php?t=1335280 for more details.

I am also experiencing the same issue on karmic.

I really only have this problems with kernels greater than 2.6.31-4. Even 2.6.32 isn't able to mount the root filesystem.

I don't think it's a configuration problem but rather some filesystem-change or similiar. I am using ext4 btw. Have been using Karmic sind Alpha 6

Am Mittwoch, den 02.12.2009, 12:54 +0000 schrieb Kai Mast:
> I really only have this problems with kernels greater than 2.6.31-4.
> Even 2.6.32 isn't able to mount the root filesystem.
>
> I don't think it's a configuration problem but rather some filesystem-
> change or similiar. I am using ext4 btw. Have been using Karmic sind
> Alpha 6

Probably this is it, i had this problems with Alfa. Now i use clean
install and do not have this issue anymore.

Hm so is there a way to update the filesystem somehow. and have there reallly been any changes? Gnome tells me i have "ext4 v1.0"

The same issue has now affected me.

I fresh-installed 9.10 yesterday from the currently available .iso files.

Having let Update Manager do its job of updating to the latest kernel (etc), I am now unable to boot on that kernel. The error message is similar to #76 here, and references the UUID in my fstab which is my root drive. It appears to be comfortable about where my swap is.

My workaround (not a very valid one) is to choose the earlier kernel in the list presented by grub. That does work well.

It would be great to understand from Keith Jenkins what a sensible edit to my fstab would be; however, given that it does currently work on the older kernel, the workaround is probably most sensible for now.

(And bizarrely)

I've done two things on this computer.
sudo gedit /etc/fstab
... I edited this file, then decided against it, and deleted my change, then saved it (in effect, therefore, re-saving an unchanged file)

...and reported this bug on Launchpad.

Either one, or the other, appears to have fixed the problem, and the new kernel now works quite happily. This is possibly therefore not the most helpful bug report in the world, but thought it was worth adding this comment.

This error occurs on my laptop (Toshiba L30-134) with karmic, but is fixed with "noapic" kernel option.

Hi cayco,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/releases/karmic . If the issue remains, please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 33269

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

Thank you for taking the time to report this bug and helping to make Ubuntu better.
We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future.
To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New".

Closing as no information about what went wrong.