iSCSI related issues with SLES11sp3 x86

SUSE Product Topics SLES Install-Boot
1

These issues seemed to have started recently “out of the blue”

  1. On boot, unless I comment out 2 entries in /etc/fstab it stops at “checking file systems…” until I hit ctrl+c, then it prompts to give root password for maintenance. When I give it root password it drops me to “(repair filesystem)”. My / is mounted, but /var is not, & neither are any of the other systems. If I comment out /media/iscsi & /media/ entries in fstab (those are shown below) I am then able to boot up fully, it properly mounts /, /var, /reload.

  2. On reboot it gets stuck at “Stopping iSCSI initiator service: done” & the reboot goes no further. If I hit ctrl+c it drops me back to the command prompt, & can type reboot again & it reboots almost instantly at that point. (minor issue, but would be nice to have resolved if at all possible)

How do I tell what partition it actually wants fsck run against, & if it is the iscsi, how do I run it on those? If I try to run it against /dev/sdc1 or /dev/sdb1 it says they are busy, but df -h doesn’t show them mounted.

/etc/fstab contents: - commented entries allow system to boot
/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0-part2 / ext3 acl,user_xattr 1 1
/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0-part6 /reload ext3 acl,user_xattr 1 2
/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0-part5 /var ext3 acl,user_xattr 1 2
/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0-part1 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
#/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:1:0-part1 /media/disk ext3 noatime,acl,user_xattr 1 2

#/dev/disk/by-id/scsi-1SYNOLOGYiSCSI_Storage:2ec552bf-0383-39c4-88f0-d75ce96b70e3-part1 /media/iscsi ext3 acl,user_xattr,nofail 1 2

Server is a Gwava reload server, so im guessing the 2 #commented out paths point to an iscsi mount. If I go into yast/iscsi initiator it shows connected targets none, however under discovered targets I can select 10.1.1.57 & it mounts iqn.2000-1.com/synology.diskstation.target-1.2xxxx with startup onboot, under discovered targets it shows connected true. I can then manually mount both /dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:1:0-part1 /media/disk & /dev/disk/by-id/scsi-1SYNOLOGYiSCSI_Storage:2ec552bf-0383-39c4-88f0-d75ce96b70e3-part1 /media/iscsi without it prompting me to fsck them.

Thanks!

2

I removed all entries under iscsi initiator, cleanly restarted server, readded the iscsi initiator & then I was finally able to get it to fsck -v -C /dev/sdc1 & sdb1 (boy that took ages, overnight even). That said, when restarting the server it shuts down a few services & hangs at iscsi -
"Stopping iSCSI initiator service: Logging out of session [sid: 2, target: iqn.2000-01.com.synology:diskstation.target-1.2cxxxxxxx, portal: 10.1.1.57:3260] Logout of [sid: 2, target: iqn.2000-01.com.synology:diskstation.target-1.2cxxxxxxx, portal: 10.1.1.57:3260] successful. “done” in green. I can leave it there for hours & it will never finish a reboot on its own. If I just hit enter it drops me back to the command prompt. If I reissue the shutdown -r now command it reboots immediately (and I assume note very cleanly).

With those 2 iscsi mounts fsck’ed I uncommented the 2 entries under /etc/fstab, & ran “mount -a”, no issues, checked “df -h” & it shows the two of them mounted. I attempt to restart the server…still gets stuck at the iscsi above. Bringing it back up after a powercycle at least it still mounts everything without dropping to the repair console. So, how to stop the server from basically dying when restarting?

It is sles11sp3 x86, fully patched (minus sp4).

3

Hi kkbas,

So, how to stop the server from basically dying when restarting?

well, technically speaking it’s not dying, but hangs in some init script (which are invoked on shutdown. too). So as you even have a command prompt during that phase, you ought to check the process list for hanging scripts. Look for command invocations with a parameter “stop”, and then check sub-processes to that. Feel free to take a look at the according init script to see where it may be hanging.

Out of curiosity: If you manually unmount the iSCSI file systems before issuing the reboot command, does the server then shut down properly?

Regards,
Jens