Mailinglist Archive: opensuse-bugs (3177 mails)

[bugzilla_noreply@xxxxxxxxxx]

https://bugzilla.novell.com/show_bug.cgi?id=763314

https://bugzilla.novell.com/show_bug.cgi?id=763314#c2


Robert Munteanu <robert.munteanu@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW
       InfoProvider|robert.munteanu@xxxxxxxxx   |

--- Comment #2 from Robert Munteanu <robert.munteanu@xxxxxxxxx> 2012-05-23 
19:26:21 UTC ---
(In reply to comment #1)
> If you remove the line
>    64-md-raid.rules \
>
> from /lib/mkinitrd/scripts/setup-dev.sh
> and run
>    mkinitrd
> again, then reboot, does that make a difference?

(assuming it's setup-udev.sh )

Yes, that does make a difference. The error messages no longer appear and I can
remove the 'noauto' option from /etc/fstab . Previously the array would be
partially assembled ( 3/4 disks ) and would stop booting. I failed to mention
that, but that bothered me the most, not the error messages.

It's interesting to see that in the dmesg output the first three partitions are
bound way ahead of the fourth

[   11.948857] md: bind<sdc1>
[   11.951483] md: bind<sdb1>
[   11.959807] md: bind<sdd1>
....
[   13.538173] md: bind<sda2>
[   13.564037] md: raid10 personality registered for level 10

Anyway, for the immediate term this is fixed.

> As your md array is not required for boot, the initrd should not try
> to assemble it, and because it doesn't need to assemble it, it doesn't contain
> mdadm.  However it does containt the udev script, hence the error messages.
>
> So the error messages are not good, but not indicative of a serious problem.
>
> The 85 second delay is more worrying.  However there is no evidence that that
> is caused by md.
> Can you try booting with "debug=yes" on the kernel command line? I think it is
> fairly easy to edit the command line with grub2.
> That should print on the console which script is being executed so you should
> be able to see better where the delay is.

Booting with debug=true ( in the grub2 linux ..... line ) still does not give
me any clue. The gap is still 

[   16.723360] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts:
(null)
[   96.562483] vboxdrv: Found 4 processor cores.

Unfortunately the scripts are not retained in the dmesg output but IIRC the
last print was something like 93-boot.sh . I'll attach the full dmesg log
shortly.

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.