On 06/22/2015 07:15 PM, Steffen Maier wrote:
On 06/22/2015 04:05 PM, Shumate, Scott wrote:
It fixes the issue permanently. But this has happened three times
after OS patching.
-----Original Message-----
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
Offer Baruch
Sent: Monday, June 22, 2015 12:02 AM
Maybe i didn't understand you correctly...
Did your procedure fix the problem permanently or just until the next
reboot?
On Jun 22, 2015 6:42 AM, "Offer Baruch" <offerbar...@gmail.com> wrote:
Is it possible that the zfcp module is not being loaded after the
reboot?
Can you issue this command after the reboot:
lsmod | grep fcp
Can you also make sure this udev rule is in place and send it content:
/etc/udev/rules.d/56-zfcp.rules
On Jun 22, 2015 12:38 AM, "Shumate, Scott" <scshum...@bbandt.com> wrote:
I was wondering if anyone out there is experiencing the same problem
we are facing. Our linux team is constantly losing SAN adapters
after they patch and reboot a RHEL5 server. The FCP adapters are
still attached to the guest but do not exist on the server side. If
they issue command lscss -t 1732/03,1732/04, nothing displays. I had
After having re-read this, all of my previous statement should even be
irrelevant.
If lscss does not show the FCP devices, they're not attached properly
(which you showed to be not the case) or they're ignored with
/proc/cio_ignore (what does this and /proc/cmdline look like?) or
there's an unlikely bug.
our linux team use the following commands to get the adapters back.
Any ideas to prevent this from happening? Any help would be greatly
appreciated.
1) verify new adapters with command lscss -t 1732/03,1732/04
2) bring new adapters online with command chccwdev -e
0.0.d500,0.0.d600,0.0.d700,0.0.f400
Now I'm puzzled, if the devices don't appear with lscss, I don't
understand how they could be set online.
3) verify adapters with command lszfcp -D
Do you mean "lszfcp -H"?
-D is for scsi_devices/LUNs, which you only seem to attach later on;
-H is for scsi_hosts/FCP-devices/vHBAs.
4) attach new luns with zfcpconf.sh script (script to attach wwpns to
the adpaters and add the luns to the adapters).
Do you IPL/boot from an FCP-attached SCSI disk?
Do you have your root file system on multipathed zfcp-attached SCSI
disk(s)? (Only this would require a proper initrd with zfcp.)
I agree with Offer Baruch regarding an entry in /etc/modprobe.conf.
With RHEL5 (not any longer since RHEL6, where udev does the magic both
in initramfs as well as after the root-fs was mounted),
we need to have a scsi_hostadapter alias entry for the system to load
the zfcp device driver, which in turn triggers via
/etc/udev/rules.d/56-zfcp.rules the configuration with /etc/zfcp.conf
and /sbin/zfcpconf.sh.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-s390info-zfcp.html
# cat /etc/modprobe.conf
alias eth0 qeth
options dasd_mod dasd=201,4b2e
alias scsi_hostadapter zfcp
If that's it, it would be interesting to find out why your original
entries are lost during patching.
Originally it's the anaconda installer which puts those entries in there
during installation (assuming you made zfcp luns known to the installer
during installation).
Among a lot of other things, /sbin/mkinitrd evaluates scsi_hostadapter
entries in /etc/modprobe.conf in order the find out if zfcp is needed in
the initrd. If it found a need for zfcp and /etc/zfcp.conf is there,
/sbin/mkinitrd generates a sequence of hardcoded nash instructions as
very first init process loading kernel device drivers and configuring
devices such as LUNs required to mount the root-fs in the initrd
environment (e.g. by writing to sysfs attributes) (in fact it just
activates all LUNs from zfcp.conf which is too much but also
sufficient). You can validate it by looking at the shell script text
file "init" within the initrd.
That documentation also mentions a few options to pass to mkinitrd (not
sure if all/any of them are really required or the automatism described
above suffices; even my dasd-only rhel5 system has scsi_mod and sd_mod
already in its default initrd):
# mkinitrd -v --with=scsi_mod --with=zfcp --with=sd_mod ... ...
5) run mkinitrd and zipl
Here is the output for q fcp from the servers.
--
Mit freundlichen Grüßen / Kind regards
Steffen Maier
Linux on System z Development
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
