"Loading, please wait..." takes too long when recovery from software raid failure

Bug #325823 reported by marco.pallotta
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
usplash (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I installed an Ubuntu Hardy Heron from the 8.04.2 alternate CD as I implemented software raid with my 2 sata disks (I made 6 metadevices).
After installation (and after having installed grub in both disks) and the first reboot I tried to power off an hard disk to test software raid. The result is that the message "Loading, please wait" takes too long (some minutes) before the system started (in fact I thought the system hanged).
The same thing happened in 8.04.1 (in fact I downloaded 8.04.2 as I thought that it was a bug fixed in the last Hardy point release).

I have been using raid for a long time (always made with redhat or suse) and It's the first distro that I see that has this behavoir.

Revision history for this message
Id2ndR (id2ndr) wrote :

Did you tried to verbose the kernel output (by removing quiet from kernel line) ?

Revision history for this message
marco.pallotta (marco-pallotta) wrote :

ld2ndR the startup hangs up for some minutes at the step "waiting for root file system" after:

"loading essential drivers
running /scripts/init-premount
mounting root file system
running /scripts/local-top"

I made the test either with a real hardware or with a virtual hardware (to exclude hardware variables) and the results are always the same.
In both cases the tests were made with sata controller.

Revision history for this message
marco.pallotta (marco-pallotta) wrote :
Revision history for this message
Id2ndR (id2ndr) wrote :

Did you try with an other version of Ubuntu (9.04 or 9.10 alpha 3 for example).

Can you provide us the detail of you installation (desktop, alterate or server CD, configuration used for software raid with mount point) ?

Thanks

Revision history for this message
marco.pallotta (marco-pallotta) wrote :

ld2ndR I haven't yet tried the issue with other version of Ubuntu, however I can provide to you some info:

- the distro installed is desktop alternate
- I tested the issue with a simple configuration (two partitions: /boot/ /root) or more complex config (seven partitions: /boot /root /var /usr/ /home /tmp swap)

Revision history for this message
marco.pallotta (marco-pallotta) wrote :

ld2ndR, I also tried the issue with 9.04 (alternate desktop CD) and the results are that the system hangs up at the same step than it does on 8.04 (see my screenshot) but for "only" 30 seconds.
Maybe the things are acceptable now even if we should know if it's the expected wait time before marking it fixed (if I remembered well. when I was a Suse user I didn't wait any seconds in a similar situation)

Revision history for this message
Id2ndR (id2ndr) wrote :

Did you tried with different reason of linux kernel? (You can download some packages at http://kernel.ubuntu.com/~kernel-ppa/mainline).
Are you able to boot the system after the timeout of 30s ?
What hardware do you get (and is there any ata port) ?

Do you see the same behavior with latest version of SUSE ?

Revision history for this message
marco.pallotta (marco-pallotta) wrote :

ld2ndR:
1) I tried with the latest Jaunty kernel
2) after about 30s the system boots normally (obviously with degraded RAID)
3) as I already sayd in one of my previous comment I made tests either with real hardware (acer aspire 5920g) and with virtual hardware (virtualbox). In both cases the disks were sata disks. The only ata device was a cd-rom drive.

I didn't make any tests with distros other than Ubuntu after having reported the issue.

Revision history for this message
marco.pallotta (marco-pallotta) wrote :

Confirmed what I remembered: tested the issue with OpenSuse 11.1 (same hardware config than Jaunty) and the problem is not present in that distro (no boot delay after you remove the first boot disk)

Moreover, in Jaunty, only first boot, after you remove the first boot disk, is affected by the issue. Next reboots haven't any problems.

At this point I think it may be a real bug.

Revision history for this message
Id2ndR (id-2ndr) wrote : Re: [Bug 325823] Re: "Loading, please wait..." takes too long when recovery from software raid failure

> Confirmed what I remembered: tested the issue with OpenSuse 11.1 (same
> hardware config than Jaunty) and the problem is not present in that
> distro (no boot delay after you remove the first boot disk)
>
What was the kernel version used ?

> Moreover, in Jaunty, only first boot, after you remove the first boot
> disk, is affected by the issue. Next reboots haven't any problems.
>
Sorry I'm not sure to understand. You just unpluged the first hard drive
to get the system running correctly ?

Revision history for this message
marco.pallotta (marco-pallotta) wrote :

> What was the kernel version used ?

OpenSuse kernel is 2.6.27.7-9 while Jaunty kernel is 2.6.28-15
I remembered to you that also with Hardy (so with an older kernel than the one I use on opensuse and Jaunty) I have the issue.

>Sorry I'm not sure to understand. You just unpluged the first hard drive
>to get the system running correctly ?

I installed the system and configured correctly the RAID. Then (with system powered off) I unplugged the first sata disk and powered on the system. At first boot with the remaining disk I notice the issue but at next reboot (always with the same remaining disk) the issue seems to disappear. I say again that with OpenSue I have no issue.

Revision history for this message
shankao (shankao) wrote :

I forgot the package changed since karmic

affects: ubuntu → xsplash (Ubuntu)
affects: xsplash (Ubuntu) → usplash (Ubuntu)
Revision history for this message
Phillip Susi (psusi) wrote :

The usplash package has been superseded by plymouth and has been removed from the Ubuntu archive. Closing all related bugs.

Changed in usplash (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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