Well, after I scripted the installation the other day, I tried installing SLES11.1-Updates to the freshly installed systems. Guess what ? The thing broke. Initially (it was late Friday afternoon – like 6 PM – before my one week vacation) I didn’t have much time to debug the issue, so I sat down last week and looked at the issue.
During the installation, when first starting multipath via command line, the scsi-mpatha device appears, and each and every occurance of this is subsequentially being used (and other stuff replaced by this actually) during the whole installation phase.
But what is this multipath-tools update doing ? No clue what exactly, however after installing the update the system is bricked. The system is basically looking for /dev/scsi/by-id/scsi-disk-mpatha and waiting for this device to appear. But since the update robbed the device, the system is no longer starting.
So I went ahead and digged around in the /dev/disk/by-id directory. Turns out /dev/disk/by-id/scsi- is actually pointing to the right device, and thus I ended up using it. So I rewrote all my scripts (profile and chroot/post-chroot adjustments) as you can see below, and for now at least, I have a working installation that lets you install updates! (careful it gots electrolytes)
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 | #!/bin/bash cat << EOF > /etc/multipath.conf defaults { 	user_friendly_names		no 	bindings_file			/etc/multipath_bindings } devices { 	device { 		vendor			"NETAPP" 		product			"LUN" 		getuid_callout		"/lib/udev/scsi_id -g -u --device=/dev/%n" 		features		"1 queue_if_no_path" 		hardware_handler	"1 alua" 		path_checker		tur 		path_selector		"round-robin 0" 		path_grouping_policy	group_by_prio 		failback		immediate 		rr_weight		uniform 		rr_min_io		128 		prio			alua 		max_fds			max         } } EOF sleep 1 # Disable the resume kernel sed -e "s,resume=/dev/mapper/.*_part[0-9],noresume,g" -i  	/etc/sysconfig/bootloader /boot/grub/menu.lst  # Figure out the multipath ID MD_ID="$( /sbin/multipath -l | head -n1 | cut -d  -f1 )" # Fix wrong root-path in /etc/fstab sed -i "s/mapper/.*_part/disk/by-id/scsi-${MD_ID}-part/" /etc/fstab # Fix grub root-path and wrong root-partition sed -i -e "s/mapper/.*_part/disk/by-id/scsi-${MD_ID}-part/"  	-e "s,scsi-${MD_ID}-part2,scsi-${MD_ID}-part3," /boot/grub/menu.lst # Fix the device.map echo -e "(hd0)t/dev/disk/by-id/scsi-${MD_ID}" > /boot/grub/device.map sleep 1 mkinitrd -f multipath | 
Now what’s left to do for tomorrow is “fixing” the already (previous to those changes) installed systems, so we can install security updates on those too!