https://bugzilla.novell.com/show_bug.cgi?id=763314 https://bugzilla.novell.com/show_bug.cgi?id=763314#c Jiri Srain changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Bootloader |Kernel AssignedTo|jsrain@suse.com |nfbrown@suse.com QAContact|jsrain@suse.com |qa-bugs@suse.de -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=763314 https://bugzilla.novell.com/show_bug.cgi?id=763314#c2 Robert Munteanu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|robert.munteanu@gmail.com | --- Comment #2 from Robert Munteanu 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.

https://bugzilla.novell.com/show_bug.cgi?id=763314 https://bugzilla.novell.com/show_bug.cgi?id=763314#c4 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #4 from Neil Brown 2012-05-24 01:36:32 UTC --- I've been learning more about systemd and find that the default timeout for mounting a filesystem is 90 seconds which is very close to the delay that you are seeing. So maybe systemd is waiting for something, but I'm not really sure what. Anyway I have some changes I'm exploring that make mdadm play better with systemd. If that works as I think it should I'll create an updated mdadm package for you to try. That should be ready by Monday at the latest. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=763314 https://bugzilla.novell.com/show_bug.cgi?id=763314#c6 --- Comment #6 from Robert Munteanu 2012-06-05 05:48:08 UTC --- I'll pick up the updated RPM later on today. What I want to mention is that I did get a mount failure with the fixes you suggested in comment #1 . Mounting by hand and then running telinit 5 completes the process succesfully but it seems there is a slight possibility of the raid array not being assembled in time. It is quite small ( happened once in three weeks ) but it's there. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=763314 https://bugzilla.novell.com/show_bug.cgi?id=763314#c8 --- Comment #8 from Robert Munteanu 2012-06-11 19:35:45 UTC --- (In reply to comment #5)

You should be able to grab an RPM from

https://build.opensuse.org/package/binaries?package=mdadm&project=Base%3ASystem&repository=openSUSE_Factory

which should fix the problem. It should turn in Factory and 12.2 in due course.

I've installed the updated RPM ( now at mdadm-3.2.5-61.2.x86_64 ) and with the patched /lib/mkinitrd/scripts/setup-udev.sh booting works fine and the delay is still there. However, once I've corrected the swap entry from /etc/fstab to point to an existing partition ( this was the first line in the file ) the boot delay is gone. -- 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.