Lucid: Gave up waiting for root device (mptsas) resolved by rootdelay

I didn't have this bug on a Dell PowerEdge 1950 (SAS1068 PCI-X Fusion-MPT SAS) also using the module mptsas (however, it was 32 bits Ubuntu 10.04LTS server, not 64 bits).

see LP #474207

https://bugs.launchpad.net/debian/+bug/474207

I am having the same problem, and waiting one or two minutes then typing exit the machine boots right up. I'm adding the GRUB_CMDLINE_LINUX_DEFAULT="rootdelay=120" line to my /etc/default/grub, we'll see if that fixes it or not.

Same problem here on two Dell R300 units (configured with three disks in a RAID 5). We had three machines (one R610 and two R300's) with virtually identical ubuntu 64bit software configurations and when they rebooted one day, due to a power outage the R300's never came back up but the R610 (running a newer, better SAS controller) recovered fine. Our Dell R300's have subsequently been removed from production due to this issue and are being replaced with HP units.

Discussed with dell and they says its the poor quality SAS controller in the lower cost hardware, like the R410 and R300.
They do something dodgy with the controllers to get the cost down.

Basically my understanding of the problem is this:
1. System starts boot process
2. Grub is loaded via BIOS routines (no problems)
3. Ubuntu kernal is bootscrapped into memory via BIOS routines and then run (no problems)
4. Ubuntu kernal loads and uses its the proper RAID driver to continue accessing the drives, however as it now has switched from BIOS routines to actual driver the RIAD is not ready for access, and hence everything dies.

According to dell CentOS probably caters for this issue in their driver. Ubuntu will need to do the same to cater for this fault in the Dell hardware.

The root delay trick works for us too, however we don't know what the root delay value should be to be confident with it for a production environment. We note the RAID slowed down over a period of a couple months, so a root delay of 120 might not be enough in the future... Just don't know enough about the poor quality dell gear to be sure. Dell had nothing further to offer on this, again usual comments about unsupported OS.

Anyway, the fix, it one can be found, needs to be tested on the dodgy SAS controllers installed in the R300's and other low cost series. Let me know if you need further technical details from our machines and I will post them up.

FYI, my machine is using an LSI 8888ELP controller with 32 Seagate 15K6 SAS drives connected.

It takes about 150 seconds for the exit after I get the error that the drives aren't ready for it to come up. Set the timeout to 180, hope that's enough.

As a side note, it takes 44 seconds to run "sudo lshw" on this machine, and almost all of that time is used to look up the SCSI subsystem.

On the server I had this issue, lshw takes only 3 seconds, so it doesn't look to be always related.

We are currently testing a way around this by using device independent paths:

Like found in Suse :

parts of /boot/grub/menu.lst

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
## kopt_2_6_8=root=/dev/hdc1 ro
## kopt_2_6_8_2_686=root=/dev/hdc2 ro

<<< NOTE THE CHANGE HERE
# kopt=root=/dev/disk/by-id/scsi-3600508e00000000046e7e17454e23c05-part1 ro vga=791

## ## End Default Options ##

title Debian GNU/Linux, kernel 2.6.26-2-amd64
root (hd0,0)
<<< NOTE THE CHANGE HERE
kernel /boot/vmlinuz-2.6.26-2-amd64 root=/dev/disk/by-id/scsi-3600508e00000000046e7e17454e23c05-part1 ro vga=791 quiet
initrd /boot/initrd.img-2.6.26-2-amd64

title Debian GNU/Linux, kernel 2.6.26-2-amd64 (single-user mode)
root (hd0,0)
<<< NOTE THE CHANGE HERE
kernel /boot/vmlinuz-2.6.26-2-amd64 root=/dev/disk/by-id/scsi-3600508e00000000046e7e17454e23c05-part1 ro vga=791 single
initrd /boot/initrd.img-2.6.26-2-amd64

### END DEBIAN AUTOMAGIC KERNELS LIST

And accordingly /etc/fstab

rebooting since this morning, so far it works

Hello
Is this problem present with the latest updates ?
Thanks
Fabio

It is a production server so I can't remove the rootdelay and reboot it without being physically beside the server. I will do it whenever I have an opportunity.

Hello
can someone run apport-collect 579572
Thanks
Fabio

do I need to upgrade to latest updates before running apport-collect 579572 ?

Hello Hussein
Yes, if you can, update, and if the issue is fixed with the latest kernel then there's no need to run apport-collect, just report here.
If the issue still present then run apport-collect 579572
Thanks
Fabio

Hi Fabio!

I can confirm that this is happening on the latest kernel release (linux-image-2.6.32-27-server 2.6.32-27.49) with an R410. I've tried running apport-collect but I am not able to proceed past the Launchpad Login Service. I can enter my username and password but the 'Continue' option is not a live link. I can only cancel out. Can I get this information to you another way?

Hey Fabio,

Seeing the same problem with a new install of Maverick

only way to get around it is to set rootdelay

Hussein Abdallah, thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 579572
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

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