PPC64 system drops into emergency shell when rebooting first time after installation of SLES 12 SP2

SUSE Linux Enterprise Server 12 Service Pack 2 (SLES 12 SP2)

SUSE Linux Enterprise Server 12 Service Pack 2 (SLES 12 SP2) has been installed on a PPC64 system without any issues, yet the first reboot fails and the system drops into emergency shell with messages like:

[    2.412928] linux multipath[826]: sda: failed to get udev uid: Invalid argument
[    2.413062] linux multipath[826]: sda: failed to get udev uid: Invalid argument
...
[    5.794004] linux mount[947]: mount: /dev/sda2 is already mounted or /sysroot busy
[    5.794546] linux systemd[1]: sysroot.mount: Mount process exited, code=exited status=32
[    5.794740] linux systemd[1]: Failed to mount /sysroot.

Resolution varies upon the system's state.

1) Enable system updates during installation

This is the preferred solution as it installs a fixed sg3_utils package (minimum required is sg3_utils-1.43-12.1.ppc64le.rpm) right away.
Register the system during installation at a SMT, SUSE Manager or directly at the customer center.
The registration stack will ask if update repositories should be enabled. Allow that to install updates.


2) System is not yet installed, but will not have access to update servers

Copy the latest sg3_utils rpm (minimum requirement:  sg3_utils-1.43-12.1.ppc64le.rpm) from the update channels and install it on the system sometime during the installation.
Once YaST2 is running, there's a root shell available on console 2. Hit <ctrl>-<alt>-<F2> to get there.

Alternatively, during the installation  but way before the first reboot, copy a fixed version of  55-scsi-sg3_id.rules to /mnt/etc/udev/rules.d/ and recreate the initrd using "mkinitrd" command. Only after that it's save to reboot. Note: once the installation has finished and yast prepares for the reboot, the later root partition is unmounted, so there are some time constraints. Again, Solution #1 is preferred and strongly recommended. If Solution #2 fails, continue with Solution #3

A copy of a fixed 55-scsi-sg3_id.rules files can be downloaded here:  TID7018238-55-scsi-sg3_id.rules.tgz
Make sure to check md5sum before using!
# md5sum TID7018238-55-scsi-sg3_id.rules.tgz
5bab2d485cecef2fccd4df45089d3e51  TID7018238-55-scsi-sg3_id.rules.tgz

NOTE: This file must be removed after the sg3_utils package had been updated to the fixed version (sg3_utils-1.43-12.1.ppc64le.rpm or later). Also the initrd must be recreated then!

3) Installation is finished, system has rebooted and is stuck in emergency mode already

Reboot the system into a rescue system booted from the SLES 12 SP2 installation DVD

If necessary start multipath and network
mount the root partition to /mnt
mount /dev, sys, proc, run into the resp. directories below /mnt
then continue with the steps from 2)

Example (multipath enabled):

modprobe dm-multipath
systemctl start multipathd
mount /dev/mapper/<root-device> /mnt
for i in /sys /dev /proc /run ; do mount -o bind $i /mnt/$i ; done
chroot /mnt
mount -a
cp <wherever 55-scsi-sg3_id.rules is located> /etc/udev/rules.d/
mkinitrd
exit
reboot

The next reboot should complete as expected.

The Linux multipath daemon needs to determine the device WWID in order to set up multipath correctly. The virtual SCSI device "AIX VDASD" (sda in the example) on the IBM POWER Virtual SCSI controller (ibmvscsi) implements an old version of the SCSI protocol and specifically doesn't support the Vital Product Data (VPD) page 0x83, which is normally used to obtain the WWID. Therefore multipathd can't add this device correctly.
The change for the file 55-scsi-sg3_id.rules in the sg3_utils package constructs a fallback WWID from the data in VPD 0x80 (which the ibmvscsi devices support). This enables multipathd to set up the devices correctly.