https://bugzilla.novell.com/show_bug.cgi?id=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c1 --- Comment #1 from Peter Maloney 2013-07-31 11:02:54 UTC --- Oh and by the way, maybe my fix would also fix this bug too: https://bugzilla.novell.com/show_bug.cgi?id=823125 -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c FeiXiang Zhang changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |mmarek@suse.com |ovo.novell.com | -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c4 Olaf Hering changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mmarek@suse.com AssignedTo|mmarek@suse.com |nfbrown@suse.com --- Comment #4 from Olaf Hering 2013-09-04 10:04:24 CEST --- I can not reproduce it. I installed a VM with two disk and the layout as described above. After install, the VM was shut down, one disk removed, and the system starts ok with just that one disk. I ran mkinitrd and compared the old and new initrd. There are no differences. mdadm.conf exists and did not change. In case you want to poke around, hammer175 is the VM, password is root. -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c6 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #6 from Neil Brown 2013-11-03 20:41:26 UTC --- (In reply to comment #0)

If your /boot is on a separate raid device from your /, mkinitrd does not add any information in the initrd to start the raid device, so boot will fail.

Hi Peter, I'm a bit confused by this part of the problem description. As I understand it, the initrd does not need to access the /boot filesystem at all. The boot loader (e.g. grub) does of course so that it can load the kernel and the initrd, But all the initrd need access to is the root filesystem and the swap partition. Once it mounts root, the scripts in there will take over to mount /boot and anything else. Clearly you are having a problem and it does seem to be related to the md device containing /boot, but I think it needs to be fixed in the regular boot scripts, not in the initrd. Handling freshly degraded arrays at boot is somewhat tricky with the dependency driven boot sequence that systemd uses. As devices are discovered, udev runs "mdadm -I $DEVICE" and mdadm incrementally assembles the arrays. Once all components are there the array is started. But if all components never arrive, the array will never be started with just that mechanism. To address this you can run "mdadm -IRs" which essentially says "all devices have arrived, time to start any remaining md arrays which are degraded". systemd need to do this when it times out waiting for a device. But I don't know how to tell it (not that I have really looked recently). The initrd does have a call to "mdadm -IRs" half way through timing out for the root device. This is why your boot works if you tell the initrd to assemble the boot device. But that isn't really the right fix. I'll do some reading about systemd and see if I can figure out how to give it an action to perform on timeout. -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c8 --- Comment #8 from Marco M. 2013-11-28 09:32:37 UTC --- Created an attachment (id=569482) --> (http://bugzilla.novell.com/attachment.cgi?id=569482) partition layout -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c10 --- Comment #10 from Andrey Borzenkov 2013-11-28 13:15:02 UTC --- (In reply to comment #9)

I don't know why you don't get a login prompt

See bnc#852021 -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c12 --- Comment #12 from Marco M. 2013-11-28 14:28:58 UTC --- (In reply to comment #10)

(In reply to comment #9)

...

I don't know why you don't get a login prompt

See bnc#852021

It looks very similar! I'm going to try the suggested patch as soon as possible and I'll let you know the result, thank you. -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c14 --- Comment #14 from Neil Brown 2013-12-02 04:29:51 UTC --- Created an attachment (id=569764) --> (http://bugzilla.novell.com/attachment.cgi?id=569764) mdadm RPM for testing Please test this rpm and confirm that it fixes the problem. If you boot with not all expected devices present there will be a 30 second delay waiting for device to appear, then any md arrays which can be started degraded will be. On subsequent boots the 30 second delay will not be needed as the other devices are not longer expected. -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c16 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |peter.maloney@brockmann-con | |sult.de --- Comment #16 from Neil Brown 2013-12-05 00:25:17 UTC --- Hi Peter, I've been approach this as an openSUSE-13.1 problem. However I just noticed that the affected "Product" at the top says "openSUSE-12.3". 12.3 works quite differently in this area and I think that it works correctly. Could you please confirm whether you we seeing this in 12.3 or in a 13.1 beta? Thanks. -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c18 --- Comment #18 from Peter Maloney 2013-12-05 02:46:20 UTC ---

Could you please confirm whether you we seeing this in 12.3 or in a 13.1 beta?

@Neil It was 12.3; I have not tested 13.1 at all yet. -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c20 --- Comment #20 from Neil Brown 2013-12-12 03:44:53 UTC --- Hi Peter, I've tried to reproduce this on 12.3 and I cannot. It always boots with /boot found and mounted happily. I can only assume that there is some detail in you configuration which is different to the way the installer sets things up. I would definitely advise having all the arrays listed in /etc/mdadm.conf, though I find it works even without that. Also it is best if /etc/fstab gives /dev/disk/by-id/md-uuid-..... devices rather than e.g. /dev/md127. Doing that latter could possibly confuse thing. So I'm going to focus on getting a good fix for this into 13.1 and leave it at that. -- 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=832501 https://bugzilla.novell.com/show_bug.cgi?id=832501#c22 --- Comment #22 from Swamp Workflow Management 2013-12-16 14:05:42 UTC --- openSUSE-RU-2013:1883-1: An update that has two recommended fixes can now be installed. Category: recommended (low) Bug References: 832501,851993 CVE References: Sources used: openSUSE 13.1 (src): mdadm-3.3-4.4.1 -- 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.

http://bugzilla.novell.com/show_bug.cgi?id=832501 --- Comment #24 from Marco M. --- Created attachment 610152 --> http://bugzilla.novell.com/attachment.cgi?id=610152&action=edit rdosreport.txt After a failed boot, taken from the emergency shell (initramfs phase) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=832501 --- Comment #26 from Marco M. --- Created attachment 610281 --> http://bugzilla.novell.com/attachment.cgi?id=610281&action=edit disk layout Just to clarify my partitions layout I attach a text file with: disks partition tables mdadm --detail of all raid array pvdisplay, vgdisplay and lvdisplay fstab I can't directly attach initrd file because it exceeds the max size allowed. I'm going to share the file with some other file sharing system. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=832501 --- Comment #30 from Marco M. ---

If I edit /etc/systemd/system.conf, uncomment #DefaultTimeoutStartSec=90s

and change it to 300s, and run "mkinitrd" then again the boot succeeds, but without the need to set rd.retry=80

This workaround has worked fine also for me. I did those two tests: 1) degraded raid1 device with root on it plus one data missing filesystem (a simple partition with a file system on it, no raid involved): root filesystem is mounted and the emergency shell appears. 2) degraded raid1 device with root on it, no other missing filesystem (there was a missing filesystem, but i marked it with the "nofail" tag in /etc/fstab): the system boots correctly in runlevel 5 ( in the systemd equivalent runlevel 5...) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=832501 http://bugzilla.novell.com/show_bug.cgi?id=832501#c33 Marco M. changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jjletho67-esus@ya | |hoo.it) | --- Comment #33 from Marco M. --- Hi, i have just removed the needinfo flag for my user, because i think i have provided the information requested. If you need something else of course I'm available, so please let me know @Neil: on the initramfs mailing list they've answered to you and are waiting for more info. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=832501 http://bugzilla.novell.com/show_bug.cgi?id=832501#c34 --- Comment #34 from Neil Brown --- Thanks... I did see that reply, sent the patches properly (in a different thread), they were eventually applied, and an updated 'dracut' was released for openSUSE about a week ago. Can you install dracut-037-17.12.1 and confirm that it fixes the problem? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=832501 http://bugzilla.novell.com/show_bug.cgi?id=832501#c36 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED Flags|needinfo?(trenn@suse.com) | --- Comment #36 from Neil Brown ---

some minutes more than normal

When booting with a newly degraded array I would expect an extra delay of 2 minutes. - there is a default timeout of 180 seconds and a magic factor of 2/3 applied. If you are seeing a longer delay, or a delay when the array was not newly degraded, then that might be a bug. Otherwise it is acting as expected. The yast installer/grub install issue is quite separate. Your best bet would be to open a new bug focusing on just that issue. Feel free to add me to 'cc', but I'm not likely to be the one to push it to resolution (I hope). Thanks for the positive report - I'll close this bug now on the assumption that the delays you see match expectations. If they don't and you want to pursue that issue, please re-open. -- You are receiving this mail because: You are on the CC list for the bug.