http://bugzilla.opensuse.org/show_bug.cgi?id=921570 Bug ID: 921570 Summary: after dist upgrade system boots to emergency mode Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-maintainers@forge.provo.novell.com Reporter: steffen.hau@rz.uni-mannheim.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I've started upgrading systems from openSUSE 13.1 to 13.2. Virtual machines without special stuff like mdadm raid devices oder multipathed FC LUN's went fine. But systems (IBM HS22 Blades) with mdadm raid devices are booting to emergency mode. The systems have three raid 1 devices (swap, / and /srv or /home), swap and / are correctly assembled but the third md device is missing and it also does not appear in /proc/mdstat. Manually running "mdadm -A --scan" brings it up and "systemctl default" continues booting. To dig deeper into this issue, I've installed openSUSE 13.2 from scratch on a spare blade and here md2 is correctly assembled. This is the content of /etc/systemd/system/ of the upgraded system: /etc/systemd/system/dbus-org.opensuse.Network.AUTO4.service /etc/systemd/system/dbus-org.opensuse.Network.DHCP4.service /etc/systemd/system/dbus-org.opensuse.Network.DHCP6.service /etc/systemd/system/dbus-org.opensuse.Network.Nanny.service /etc/systemd/system/default.target /etc/systemd/system/default.target.wants/sysstat.service /etc/systemd/system/default.target.wants/systemd-readahead-collect.service /etc/systemd/system/default.target.wants/systemd-readahead-replay.service /etc/systemd/system/getty.target.wants/getty@tty1.service /etc/systemd/system/multi-user.target.wants/acpid.service /etc/systemd/system/multi-user.target.wants/apache2.service /etc/systemd/system/multi-user.target.wants/auditd.service /etc/systemd/system/multi-user.target.wants/cron.service /etc/systemd/system/multi-user.target.wants/dsmc.service /etc/systemd/system/multi-user.target.wants/irqbalance.service /etc/systemd/system/multi-user.target.wants/mcelog.service /etc/systemd/system/multi-user.target.wants/ntpd.service /etc/systemd/system/multi-user.target.wants/postfix.service /etc/systemd/system/multi-user.target.wants/remote-fs.target /etc/systemd/system/multi-user.target.wants/smartd.service /etc/systemd/system/multi-user.target.wants/sshd.service /etc/systemd/system/multi-user.target.wants/syslog-ng.service /etc/systemd/system/multi-user.target.wants/wicked.service /etc/systemd/system/network-online.target.wants/wicked.service /etc/systemd/system/network.service /etc/systemd/system/sysinit.target.wants/multipathd.service /etc/systemd/system/syslog.service /etc/systemd/system/system-update.target.wants/systemd-readahead-drop.service /etc/systemd/system/timers.target.wants/logrotate.timer /etc/systemd/system/wickedd.service.wants/wickedd-auto4.service /etc/systemd/system/wickedd.service.wants/wickedd-dhcp4.service /etc/systemd/system/wickedd.service.wants/wickedd-dhcp6.service /etc/systemd/system/wickedd.service.wants/wickedd-nanny.service /etc/systemd/system/wicked.service.wants/wickedd.service I've made the scratch system identical to the problematic system (identical installed packages, conf files in /etc, active systemd services, and so on) and it still assembles md2. I've no more ideas where to search for possible causes. Please let me know what kind of information I should provide in order to help you to find the cause. -- You are receiving this mail because: You are on the CC list for the bug.