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: