Re: Edit grub from 3270 console

[Steffen Maier]

On 5/5/23 02:14, Marcy Cortes wrote:

You can pass things to grub on the IPL command using the PARM statement.  I 
just had to do that when I needed to validate a systemd timing problem with a 
kernel parm.  It's tricky with the lower case stuff.


+1

e.g. 
https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=55

such as https://www.ibm.com/docs/en/linux-on-systems?topic=blz-from-scsi-1
or https://www.ibm.com/docs/en/linux-on-systems?topic=blz-from-dasd-1
or https://www.ibm.com/docs/en/linux-on-systems?topic=mode-booting-from-scsi
or https://www.ibm.com/docs/en/linux-on-systems?topic=zvm-from-dasd
etc.



Is that what you are trying to do?

-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Thursday, May 4, 2023 4:55 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Edit grub from 3270 console

I'm pretty sure they're asking about the ability of using grub itself to change 
things, when the grub menu is displayed. If so, then there is supposed to be a 
way to do it, but I never really dug into it well enough to figure it out 
properly. There are a couple of hints given on the screen about which keys to 
use, etc., but after that I wasn't initially able to get any further, and had 
to move on to other tasks.


Unfortunately, the links to older SLES release documentation are meanwhile 
broken in

https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=55
The new links would be:
https://documentation.suse.com/sles/15-SP4/html/SLES-all/cha-grub2.html#sec-grub2-menu-change
https://documentation.suse.com/sles/15-SP4/html/SLES-all/cha-grub2.html#sec-grub2-zseries
Note that it's quite tricky to use the grub menu editing as we're in a line 
mode terminal and the cursor position is not getting drawn, so the SLES docs 
suggest to temporarily(!) enter an underscore to see the cursor position, but 
one also needs to remove the underscore again with e.g. sending a backspace 
escape sequence so grub does not see the underscore which is regular user input 
for it.




If they're not talking about that, and are asking about using some form of 
editor to modify the config file itself, then you're correct. I really wish the 
old UTS editor that was made to work with 3270/3215 terminals had been open 
sourced before the company went under, but that never happened.


Mark Post


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU]On Behalf Of
Rich Smrcina
Sent: Thursday, May 04, 2023 5:55 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Edit grub from 3270 console


Victor,

The only options that I can think of are ed and sed. Your Unix people
should know how to use them.

Rich Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com <mailto:r...@velocitysoftware.com>



On May 4, 2023, at 4:04 PM, Victor Echavarry

 wrote:


Hello

Some of our Unix people asked is there a way to add or

modify the grub file at start up from a 3270 screen? Is there are
instructions for this?


Regards,

Víctor Echavarry
System Programmer
EVERTEC LLC


WARNING: This email and any files transmitted with it are

confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email in
error please delete it immediately.
Please note that any views or opinions presented in this email are
solely those of the author and do not necessarily represent those of
EVERTEC, Inc. or its affiliates. Finally, the integrity and security
of this message cannot be guaranteed on the Internet, and as such
EVERTEC, Inc. and its affiliates accept no liability for any damage
caused by any virus transmitted by this email.



--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: ClefOS will not come up

[Steffen Maier]

On 2/27/23 07:30, Neale Ferguson wrote:

- cp /etc/dasd.conf /etc/dasd.conf.save

- echo "0.0.0124" >>/etc/dasd.conf (and repeat for each address - NOTE the >>)
OR
- printf "0.0.0124\n0.0.0125\n0.0.0126\n0.0.0127\n" >>/etc/dasd.conf

- cat /etc/dasd.conf (to make sure it looks okay)


That's good and fixes the persistent device configuration on the root file 
system.
I think you can do that once you dynamically fixed up the active device
configuration on the dracut emergency shell to continue booting successfully.
After all this, a rebuild of the initramfs and the boot record are likely
required to have subsequent boots work correctly out of the box:
https://public.dhe.ibm.com/software/dw/linux390/docu/lgu5dd06.pdf#%5B%7B%22num%22%3A311%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C59.8677%2C697.459%2Cnull%5D
(https://www.ibm.com/docs/en/linux-on-systems?topic=bd-rebuild-initrd)

--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: How to force a Linux kernel dump....?

[Steffen Maier]

On 2/20/23 16:49, Dave Jones wrote:

I have a client with an unresponsive zLinux guest. The client wants to
(somehow) force a kernel dump; but does not have access to either the 370
console or an SSH logon prompt.
What can he do here?
I have suggested doing a FOR zlinux CMD VMDUMP   but that's not a
kernel dump.


I would think that should work and be good enough to get a Linux system dump
according to 
https://www.ibm.com/docs/en/linux-on-systems?topic=91-zvm-dump-vmdump.

--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: LUN ID addition to LVM Redhat

[Steffen Maier]

Hi Jake,

On 9/12/22 11:06, Jake Anderson wrote:

I must confess that I have little knowledge about Multipathing but still
based on my research below is what I understood

My storage team has given a LUN ID of 500g

So as per df -TH

I see
/dev/mapper/bradvg2-u03_lv is mounted on /u03

So similarly I have to create another mount point with /u04



So If my understanding is correct I need to run multipath -d to scan the
newly LUN added.


It depends on whether you are using zfcp automatic LUN scan or not.
https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=20
https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=21
https://www.ibm.com/docs/en/linux-on-systems?topic=devices-configure

If so (and the storage already mapped the volume to the host, of course),
you only need to trigger a LUN scan for Linux to dynamically find the new paths
to the volume. That can be "rescan-scsi-bus.sh -a" or more directly (I
typically prefer this):
https://www.ibm.com/docs/en/linux-on-systems?topic=scanning-trigger-lun-scan


Then do echo the new LUN ID to the device driver
The apply changes to /etc/zipl.conf


If you don't use zfcp automatic LUN scan, then you have to explicitly configure
multiple paths to the new volume presistently in Linux.
The volume usage sounds like it's a data volume, i.e. not part of the root file
system, so we don't touch /etc/zipl.conf, but only /etc/zfcp.conf.

https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=23
=>
https://www.ibm.com/docs/en/linux-on-systems?topic=devices-manually-configured-fcp-luns
=>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_8_installation/configuring-a-linux-instance-on-ibm-z_installing-rhel#fcp-luns-that-are-not-part-of-the-root-file-system_configuring-a-linux-instance-on-ibm-z

In either case, a running multipathd ensures the new LUN paths are
automatically assembled into a new multipath device representing your new 
volume.
https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=15
https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=16

You can then prepare the new volume as you did for your already existing LVM
PhysicalVolume(s) within VolumeGroup bradvg2, so likely something like pvcreate
on the new multipath device (or on a partition thereof).

LVM in recent Linux distributions automatically ignores individual single paths
to a volume and makes use of multipath devices instead when scanning
PhysicalVolumes.
Older distributions might need an explicit LVM filter to accomplish this.
https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=46

FYI: In case you happen to run RHEL 9.x, you would instead have to deal with
the new LVM device filter (different from above-mentioned LVM filter):
The RHEL installer "anaconda" disables auto PV scan by populating
/etc/lvm/devices/system.devices, so the user needs to add new PVs by means of
"lvmdevices --adddev ...".
https://bugzilla.redhat.com/show_bug.cgi?id=2002550#c0
https://sourceware.org/git/?p=lvm2.git;a=commit;h=83fe6e720f42711ff183a66909b690b726702f58


Then perform lv addition

Is my understanding correct? Could someone please be kind to share the
steps of adding the newly added LUN ID to an existing LV ?


Your above steps with a new separate mount point, do not sound like you would
add the new physical volume to an existing LVM VolumeGroup, which would be
another possibility.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_logical_volumes/index#modifying-the-size-of-a-logical-volume_configuring-and-managing-logical-volumes


--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: LUN ID - Filesystem

[Steffen Maier]

Hi Jake,

On 7/4/22 06:13, Jake Anderson wrote:

Is it possible to know the LUN ID where a specific filesystem is residing?


You can use lsblk to find out SCSI disk block device names backing the paths to
a specific mounted file system.
Then you can use e.g. lsscsi -xxtv
[https://www.ibm.com/docs/en/linux-on-systems?topic=devices-mapping-sysfs-representations]
to map individual paths to Fibre Channel addressing including the FCP LUN.

--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Dracut timeout

[Steffen Maier]

Hi Peter,

On 6/30/22 11:36, Peter wrote:

Still the zfcp shows the older FCP device under /etc/zfcp


Ideally, you dedicate the FCP devices with the same virtual devno to the guest 
in the DR site as to the guest in the main site.


If that's really not possible for you, you indeed probably would add the DR 
virtual FCP devnos to /etc/zipl.conf [designed method for the root-fs] and 
additionally to /etc/zfcp.conf. Re-create initramfs. Re-write zipl boot record. 
Would be easiest if you could do that while booted on the main site.

https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=23
https://www.ibm.com/docs/en/linux-on-systems?topic=devices-configure

The different storage WWPN and LUN in the DR site, should not be much of a 
problem as your FCP devices are NPIV-enabled and I assume you have a somewhat 
recent Linux distribution (such as RHEL 7 or later?), so zfcp auto lun scan 
would automatically discover paths in the DR site for you.

https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=21
https://www.ibm.com/docs/en/linux-on-systems?topic=devices-automatically-attached


The replicated volume still shows the older WWPN, FCPS

Not sure if I can update it from 3270 emulator logon ?

On Thu, Jun 30, 2022, 1:25 PM Dan Horák  wrote:

On Thu, 30 Jun 2022 13:11:55 +0400 Peter  wrote:

I tried bringing up the Linux service machine in our DR site after

updating

the guest user directory with FCP device, updating WWPN of Storage box ,
LUN and ran the exec from zVM and I received the below message. Not sure
what needs to be done. Any suggestions?

134.043109م dracut-initqueueم331ل: Warning: dracut-initqueue timeout -


The full console output is helpful (not necessarily sufficient, though) in such 
cases, especially the parts about "Kernel command line:". I usually spool the 
Linux console of my guests to get the full output later on.



this usually means that the storage device with the root filesystem
can't be found. Does the VM definitions match the Linux parameters?


--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: FCP device

[Steffen Maier]

Hi Peter,

On 6/28/22 11:03, Peter wrote:

How do we create WWPN or FBA device in DR site ?

As this is the first time we are planning to replicate Linux guest to DR
site.

Is there a way to assign or attach a FBA device to the Linux guest ?


What's replicated in the DR site? IBM Z CPC, storage (using e.g. PPRC), or both?

Which WWPN: initiator of the host, or target of the storage?
The host initiator WWPNs are managed by the machine and can e.g. be exported on
the SE (example for non-DPM machine):
https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=40

I suppose you use z/VM EDEV to represent multiple paths to an FCP-attached
volume as emulated FBA DASD to a guest as opposed to dedicated FCP devices? If
so, I think you would just use a different set of FCP devices on the DR CPC to
assemble the EDEV device and dedicate that resulting FBA DASD to the
"replicated" guest for use on cold failover, i.e. on IPL of the guest on the DR
CPC.

--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: [EXTERNAL] Re: Problem with SLES 15 SP3 Multipath

[Steffen Maier]

For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390data=05%7C01%7Calevy%40doitt.nyc.gov%7C968d74fea29549a1b3ee08da3db394d0%7C73d61799c28440228d4154cc4f1929ef%7C0%7C0%7C637890138762996776%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=cNw7WLi31P%2B8aupF94U%2FpLdHcZW8vKjK0J9NmejSpDU%3Dreserved=0

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390



--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Problem with SLES 15 SP3 Multipath

[Steffen Maier]

On 5/24/22 18:43, Levy, Alan wrote:

We cloned a SLES 15 SP3 server and defined SAN to it.

When we re-booted the server, we get "failed to mount /usr/xxx", which is the 
san device, and the server goes into emergency mode.

Based on some SUSE documentation and other recommendations, we ran the 
following commands afterwards to get the SAN working again:

multipath -T > /etc/multipath.conf
vi /etc/multipath.conf   # changed 
user_friendly_names to "yes"
rescan-scsi-bus.sh -a  # rescan scsi 
just in case
multipathd reconfigure # updates the 
bindings file after edit of /etc/multipath.conf
blkid  # 
get UUID of file systems
vi /etc/fstab# define 
file systems with UUID
dracut -f --add multipath
init 6

These commands allowed the system to boot successfully and we are able to see 
and use the san.

We then ran "zypper patch" to patch the system to the latest SP3 release which included a 
kernel update. When we rebooted the server again, the same problem occurred (failed to mount the 
san).  We then ran the "dracut -f --add multipath" command and rebooted which allowed the 
server to come up successfully.

Our question is - how do we make the dracut -f -add multipath command permanent 
such that subsequent kernel updates will include it?

We have a case opened with SUSE but they have not come up with any solutions.

Any suggestions from the linux community would be greatly appreciated.


I agree with Mark Post.

Does this happen to be the same as SUSE bug 1197570 /
https://github.com/systemd/systemd/issues/23208 ?
If so, that bug contains instructions for a persistent workaound.


--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: FCP disks and IOCDS

[Steffen Maier]

On 2/8/22 00:16, Robert J Brenneman wrote:

IODF devices for FCP do not point to disks - they are simply a hole to dump
frames into the network and pull frames out of the network with.  Its a lot
more like OSA devices than DASD.   the OSA device is not an endpoint in the
IP network that you are talking to, and neither is the FCP device in the
IODF.

you add device 4000 on chpid 40 , and 4100 on chpid 41 to your IODF as you
have drawn. each chpid plugs to a different switch, and each of those
switches in turn plugs to the storage device.

When you configure devices 4000 and 4100 online in linux, no storage
appears. All that happens is that the 2 pchids log in to the switch that
each is plugged to.
Once the devices have logged in to the switch - the SAN admin can create a
zone that permits the WWPN of the Z adapter to talk to the WWPN of the
storage box. A WWPN is kinda the SAN equivalent of an IP address - it
uniquely identifies this endpoint to the storage network. The FCP devices
on the Z have WWPNs, and the storage device ports also have WWPNs, and when
you create a zone in the storage network with one each of Host WWPN and
Storage WWPN the SAN will permit those two endpoints to talk to each other.
This is very different from FICON CUP network management where you permit
port 23 to talk to port 4D - the FICON method is a switch-port to
switch-port access control method. It does not care what is at the other
end of the port, just that this port can talk to that port - in the
switch.   A SAN WWPN zone is that "this end point WWPN" in the network can
talk to "that end point WWPN" in the network - no matter what physical
switch ports there are between them.

Once the zone is in place and active the linux OS will see the storage
controller - and now in the storage controller you have to tell it about
the WWPNs of the Linux host and what virtual disk it is allowed to use.
This is called lun masking or mapping, depending on whos storage you're
using.  Once you create a host definition on the storage controller that
lists the WWPNs of the Linux FCP devices, and maps a LUN to that host
definition, Linux will see scsi disk devices appear on the FCP channels.

you will see one /dev/sdXX device appear for each path to each lun.  for
example 1 LUN with 2 paths will show you /dev/sda and /dev/sdb.   The Linux
OS can see both paths to the disk - and now you need to enable the linux
multipath driver to manage those paths for you. It will create a new
/dev/mapper/ device for you to format or use for LVM or
whatever and the driver will handle spreading IO across /dev/sda and
/dev/sdb paths for you, as well as path recovery if you take a switch down
for maintenance.


well said


ref:
https://www.vm.ibm.com/education/lvc/LVC0924.pdf?cm_sp=dw-dwtv-_-linuxonz-_-PDF-for-3rdpartyhost-videos%20PDFs


just a little update with a more recent version:

https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf

On top, you might find this useful for zoning:
Exporting host WWPNs:
https://listserv.uark.edu/scripts/wa-uarkedu.exe?A2=IBMVM;3c30da04.2110


On Mon, Feb 7, 2022 at 5:37 PM Davis, Larry (National VM Capability) <
larry.dav...@dxc.com> wrote:


Cross posting to Linux for s390 and z/VM List Serves


We are looking at using a SAN and connect our z/VM system to it to allow
our Linux servers on z/VM to use it

We are having questions on Connectivity in the IOCP to backend LUN's in
the SAN

For FCP Channels you are not allowed to do Multi-Pathing like we normally
see on the Mainframe by having a control unit have multiple Path to the
same device.

If this is correct then two  SAN switch's that connect to the SAN disks
can map to the same LUN in the back end

Using this will allow 2 separate device addresses to be created that point
to the same backend LUN correct?


Then Linux Multi-pathing  will see 2 separate device addresses as a single
LUN and associate both addresses to the same SAN Device

CHPID 40 (CSS0) -> Switch A ->--

   | SAN  Devices   |
CHPID 41 (CSS0) -> Switch B ->--

CHPID 40, CU 4000, devices 4000-401F
CHPID 41, CU 4100, devices 4100-411F

If the Zone Fabric relates all the out link switch ports to the same
xx00-xx1F devices in the backend, does this allow for Linux Multi-pathing
and eliminate the single CHPID point of failure

Are there any documents that will clarify this possibly for me?


Larry Davis
Senior z/VM Systems Architect,
Leveraged Mainframe Team
DXC Technology

T +1.813.394.4240
larry.dav...@dxc.com<mailto:larry.dav...@dxc.com>




--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller
Sitz der Gesellschaft: Boeblingen
Re

Re: X Windows System setup on Ubuntu Server 18.04.

[Steffen Maier]

On 1/28/22 09:56, (K.K.Paradox)T.Kobayashi wrote:

I'm still investigating the issue.
There were some warnings in Xorg.0.log.
I did the following to clear them.

$ sudo apt-get install -y xserver-xorg-video-fbdev



s390x@s390x:/var/log$ cat Xorg.0.log



[   483.532] (II) FBDEV: driver for framebuffer: fbdev
[   483.536] (WW) xf86OpenConsole: setpgid failed: Operation not permitted
[   483.538] (WW) xf86OpenConsole: setsid failed: Operation not permitted
[   483.544] (EE) Fatal server error:
[   483.657] (EE) xf86OpenConsole: Cannot open virtual console 7 (No such file 
or directory)



[   483.727] (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
[   483.738] (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor
[   483.809] (EE) Server terminated with error (1). Closing log file.


IBM Z does not have a framebuffer / graphics-adapter (nor Linux Virtual 
Terminals), so Xorg, even with the fbdev module, cannot run.



If that doesn't work, I'll try Xvnc instead of Xorg.


I think that's the only way if you want an X server in Linux on IBM Z.


- Original Message -
From: "Steffen Maier" 
Sent: Friday, January 28, 2022 5:57 AM



On 1/27/22 10:06, (K.K.Paradox)T.Kobayashi wrote:



typical x86 desktop [VT7, fbdev]. If you want to go with this method of
starting up X, you probably need to teach it to use Xvnc instead of Xorg as
X
server. I haven't done such config since roughly 2 decades. Maybe:
https://manpages.ubuntu.com/manpages/bionic/en/man1/xdm.1.html#local%20server%20specification 



On Wed, Jan 26, 2022 at 4:09 AM (K.K.Paradox)T.Kobayashi <
kobaya...@paradox.jp> wrote:



I'm setting up X Windows System on Ubuntu Server 18.04.

I installed the some packages with the following command:

$ sudo apt-get -y install xserver-xorg
$ sudo apt-get -y install x11-apps
$ sudo apt-get -y install xdm
$ sudo apt-get -y install x11vnc


--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller, 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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: X Windows System setup on Ubuntu Server 18.04.

[Steffen Maier]

On 1/27/22 10:06, (K.K.Paradox)T.Kobayashi wrote:

Thank you for your advice. I haven't solved the problem, but I will continue
to investigate this problem.


You're welcome.

I suspect your setup [/usr/share/X11/xorg.conf.d/ ?] is some default for 
systems with a physical frame buffer and with whatever procedure you start xdm 
(some system service?), it tries to start something automatically like on a 
typical x86 desktop [VT7, fbdev]. If you want to go with this method of 
starting up X, you probably need to teach it to use Xvnc instead of Xorg as X 
server. I haven't done such config since roughly 2 decades. Maybe:

https://manpages.ubuntu.com/manpages/bionic/en/man1/xdm.1.html#local%20server%20specification

I'm not very familiar with Ubuntu so I could not find any more detailed 
documentation other than the Xvnc man page which briefly alludes to a few 
different setup variants:

http://manpages.ubuntu.com/manpages/bionic/man1/Xvnc4.1.html

You might be able to translate docs of other distros to your Ubuntu environment:

https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-vnc.html#sec-vnc-persistent
Vncpassword and vncserver is what I often use, but without a display manager.
The other doc parts seem to depend on YaST as config frontend which is SUSE 
specific.


https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/accessing-the-desktop-remotely_using-the-desktop-environment-in-rhel-8#remotely-accessing-the-desktop-as-multiple-users_accessing-the-desktop-remotely
This shows how to edit config files and parts of it might also apply to vnc 
server on Ubuntu.



- Original Message -
From: "Steffen Maier" 
To: 
Sent: Wednesday, January 26, 2022 11:01 PM
Subject: Re: X Windows System setup on Ubuntu Server 18.04.



On 1/26/22 14:11, Robert J Brenneman wrote:

you don't run the X server process on the remote system, the X Server
runs
on the system with the video card in it - which is generally the
workstation/pc/laptop you are looking at.   the programs running on the
remote server are the X Clients, and you tell them where the server is by
setting the DISPLAY variable.  Generally you also enable SSH X11
tunneling
on the remote server by setting it in the ssh_server.conf file and
restarting sshd, and when you ssh into the server you use the -X switch
on
the ssh command to tell the ssh client to create an X11 tunnel through
your
ssh session.


Workstation-local X server, optionally with ssh X11 forwarding, is one
option.

Running an X server on Z with the VNC backend, instead of a framebuffer,
is
another option. In that case the local workstation would run a VNC client
and
connect to the remote VNC server on the Z-side to show the virtual
framebuffer
of the remote X server. I prefer it when I need to access GUI over
anything
non-LAN, especially over long haul internet paths, because VNC over the
long
haul path behaves much better than the good old verbose X window protocol.
Usually that would be a setup without any X display manager (such as XDM,
GDM,
KDM, ...) in my case, but I've seen distros setup a full display manager
setup
with Xvnc on Z.

Unfortunately, I cannot tell from the given information why the latter did
not
work, despite having x11vnc installed.


On Wed, Jan 26, 2022 at 4:09 AM (K.K.Paradox)T.Kobayashi <
kobaya...@paradox.jp> wrote:


Hello,

I'm setting up X Windows System on Ubuntu Server 18.04.

I installed the some packages with the following command:

$ sudo apt-get -y install xserver-xorg
$ sudo apt-get -y install x11-apps
$ sudo apt-get -y install xdm
$ sudo apt-get -y install x11vnc

And rebooted the system.

But, the xdm and Xorg issued following messges:
(EE) xf86OpenConsole: Cannot open virtual console 7 (No such file or
directory)
[   530.421] (EE) Failed to load module "fbdev" (module does not exist,
0)

Is there a way to resolve this error?
The details of the xdm and Xorg logs are shown below.

$ cat xdm.log



(==) Using system config directory "/usr/share/X11/xorg.conf.d"



Please consult the The X.Org Foundation support
  at http://wiki.x.org
  for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for
additional information.



$ cat /var/log/Xorg.0.log



[   523.499] Markers: (--) probed, (**) from config file, (==) default setting,
   (++) from command line, (!!) notice, (II) informational,
   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.



[   526.423] (==) Using system config directory
"/usr/share/X11/xorg.conf.d"
[   526.626] (==) No Layout section.  Using the first Screen section.
[   526.627] (==) No screen section available. Using defaults.
[   526.628] (**) |-->Screen "Default Screen Section" (0)
[   526.630] (**) |   |-->Monitor ""
[   526.926] (==) No monitor specified for screen "Default Screen
Section".
 Using a default monitor c

Re: X Windows System setup on Ubuntu Server 18.04.

[Steffen Maier]

sing system config directory
"/usr/share/X11/xorg.conf.d"
[   526.626] (==) No Layout section.  Using the first Screen section.
[   526.627] (==) No screen section available. Using defaults.
[   526.628] (**) |-->Screen "Default Screen Section" (0)
[   526.630] (**) |   |-->Monitor ""
[   526.926] (==) No monitor specified for screen "Default Screen Section".
 Using a default monitor configuration.
[   527.011] (==) Automatically adding devices
[   527.012] (==) Automatically enabling devices
[   527.015] (==) Automatically adding GPU devices
[   527.016] (==) Automatically binding GPU devices
[   527.044] (==) Max clients allowed: 256, resource mask: 0x1f
[   527.325] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
exist.
[   527.329]Entry deleted from font path.
[   527.330] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not
exist.
[   527.356]Entry deleted from font path.
[   527.391] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not
exist.
[   527.427]Entry deleted from font path.
[   527.428] (WW) The directory "/usr/share/fonts/X11/Type1" does not
exist.
[   527.430]Entry deleted from font path.
[   527.432] (WW) The directory "/usr/share/fonts/X11/100dpi" does not
exist.
[   527.449]Entry deleted from font path.
[   527.451] (WW) The directory "/usr/share/fonts/X11/75dpi" does not
exist.
[   527.454]Entry deleted from font path.
[   527.456] (==) FontPath set to:
 /usr/share/fonts/X11/misc,
 built-ins
[   527.457] (==) ModulePath set to "/usr/lib/xorg/modules"
[   527.459] (II) The server relies on udev to provide the list of input
devices.
 If no devices become available, reconfigure udev or disable
AutoAddDevices.
[   527.574] (II) Loader magic: 0x2aa0af70010
[   527.575] (II) Module ABI versions:
[   527.577]X.Org ANSI C Emulation: 0.4
[   527.580]X.Org Video Driver: 23.0
[   527.582]X.Org XInput driver : 24.1
[   527.586]X.Org Server Extension : 10.0
[   528.090] (++) using VT number 7

[   528.386] (II) systemd-logind: logind integration requires -keeptty
and -keeptty was not provided, disabling logind integration
[   528.486] (II) no primary bus or device found
[   528.618] (II) LoadModule: "glx"
[   529.032] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   529.960] (II) Module glx: vendor="X.Org Foundation"
[   529.962]compiled for 1.19.6, module version = 1.0.0
[   529.965]ABI class: X.Org Server Extension, version 10.0
[   529.971] (==) Matched modesetting as autoconfigured driver 0
[   529.978] (==) Matched fbdev as autoconfigured driver 1
[   529.979] (==) Assigned the driver to the xf86ConfigLayout
[   529.980] (II) LoadModule: "modesetting"
[   530.049] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[   530.256] (II) Module modesetting: vendor="X.Org Foundation"
[   530.257]compiled for 1.19.6, module version = 1.19.6
[   530.259]Module class: X.Org Video Driver
[   530.261]ABI class: X.Org Video Driver, version 23.0
[   530.263] (II) LoadModule: "fbdev"
[   530.413] (WW) Warning, couldn't open module fbdev
[   530.416] (II) UnloadModule: "fbdev"
[   530.420] (II) Unloading fbdev
[   530.421] (EE) Failed to load module "fbdev" (module does not exist, 0)
[   530.422] (==) Matched modesetting as autoconfigured driver 0
[   530.425] (==) Matched fbdev as autoconfigured driver 1
[   530.426] (==) Assigned the driver to the xf86ConfigLayout
[   530.428] (II) LoadModule: "modesetting"
[   530.549] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[   530.552] (II) Module modesetting: vendor="X.Org Foundation"
[   530.559]compiled for 1.19.6, module version = 1.19.6
[   530.560]Module class: X.Org Video Driver
[   530.563]ABI class: X.Org Video Driver, version 23.0
[   530.564] (II) UnloadModule: "modesetting"
[   530.567] (II) Unloading modesetting
[   530.572] (II) Failed to load module "modesetting" (already loaded, 7)
[   530.576] (II) LoadModule: "fbdev"
[   530.729] (WW) Warning, couldn't open module fbdev
[   530.731] (II) UnloadModule: "fbdev"
[   530.775] (II) Unloading fbdev

Best regards,
Toyokazu Kobayashi



--
Jay Brenneman



--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschaeftsfuehrung: David Faller, 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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Installing Linux on VM

[Steffen Maier]

On 1/7/22 22:27, Mondy, Stephen (US - Texas) wrote:

I have a requirement to quickly install Red Hat Linux 8.5 on z/VM 7.2 for a
proof of concept of a Linux application.



I need the best
fast path, cookie cutter document/process to get the installs A-Z ( 2
instances ) completed ASAP. Is there one?



These are the docs I have been reviewing so far;
SG24-8147-02 - Virtualization Cookbook Vol 1 IBM zVM 7.2
SG24-8303-01 - The Virtualization Cookbook for IBM Z Volume 2 Red Hat 
Enterprise Linux Server 8.2


I think the cookbooks are rather for larger scale penguin farms and might be
overkill for a PoC with just two Linux instances.


SC24-6287-04 - zVM720 Getting Started with Linux on IBM Z



red_hat_enterprise_linux-8-performing_a_standard_rhel_installation-en-us


I would start with that RHEL install guide. In particular, the following parts:

Typically installing Linux on Z is done over the network, so you need some
network server providing the content of the RHEL DVD ISO such that your Linux
z/VM guest can access it.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_installation/prepare-installation-source_installing-rhel#ports-for-network-based-installation_prepare-installation-source

The Z part of the installation:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_installation/planning-for-installation-on-ibm-z_installing-rhel

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_installation/overview-of-the-ibm-z-installation-process_installing-rhel

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_installation/booting-the-installation_installing-rhel

The custom content of generic.prm is important, e.g. to get the network
configured used during installation (FWIW, since RHEL7 I don't use CMS
configuration files anymore and instead put everything in generic.prm):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_installation/customizing-boot-parameters_installing-rhel

Here is a generalized examples of what it often looks like in my case; you need
to customize things in angle brackets such as network device numbers (bdf?), IP
addresses, etc.:

ro ramdisk_size=4 cio_ignore=all,!condev
rd.znet=qeth,<0.0.bdf0>,<0.0.bdf1>,<0.0.bdf2>,layer2=<1>
ip=:enc:none
nameserver=
inst.repo=<http://.../s390x/RHEL8./DVD>
inst.vnc inst.vncpassword=<...> inst.sshd

You'd probably use the z/VM Reader to IPL the installer:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_installation/installing-under-z-vm_installing-rhel

I typically connect from my workstation via VNC to the RHEL graphical installer
running on Z.

Next, things continue pretty much like with RHEL on any other architecture:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_installation/graphical-installation_graphical-installation


--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z and LinuxONE

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Multipathing and booting from SAN LUN

[Steffen Maier]

Hi Martha,

On 7/3/20 12:32 AM, Mark Post wrote:

On 7/2/20 5:32 PM, Martha McConaghy wrote:

I've run into something that is a bit beyond my Linux skills at this point.  
So, I could use some advice.

I have several RHEL 7 servers running on z/VM that are booting from SAN LUNs, 
not ECKD.  That isn't our normal practice, so it is different for me.  I use 
LOADDEV to define the port and LUN, and dedicate the device addresses to each 
server.  (All are using NPIV addressing and are zoned to a DS8870 on the SAN.)  
Here is what one of the directory entries looks like:

IPL 2000
LOADDEV PORT 500507630628D700
LOADDEV LUN 40004007
MACHINE ESA 4
OPTION CHPIDV ONE
DEDICATE 2000 5000
DEDICATE 3000 6000



-snip-

I don't know what to do with this situation, though, to get full use of the 2nd 
fabric.  First there is the IPL issue...how can I have an alternate IPL address 
if 2000 doesn't work?  Then, there is the issue of Linux once it boots...not 
sure how to get multipath drivers introduced after the boot process is already 
done.  The LUN contains the operating system as well as data.


[snip]


For the multipathing, you're probably going to need to enable the
multipathd service, and them rebuild your initrd so that it gets started
there, before your file systems get mounted. Not being familiar with the
exact details of Red Hat's setup, all I can say is the commands will be
something like:
sysctl enable whateverthenameofthemultipathingsservice is, followed by
the dracut with whatever parameters normally get used. I don't know that
dracut will figure out it should include support for multipathing in the
initrd or not. That may be something to run a Google search on.


Ideally, more than one path gets specified during installation, then the
installer performs the necessary steps for the installed system to continue
using multiple paths [1, slide 15].

If that's not possible, perform a backup of the existing system(s), as the
following _untested_ steps could make it unbootable, so you have something to
go back to and retry differently.

I would add one additional "rd.zfcp=..." statement to the kernel parameters in
/etc/zipl.conf for each path of each volume that is part of the root file
system dependencies. Also add the paths to /etc/zfcp.conf and activate them 
with:
# /usr/sbin/zfcp_cio_free
# /usr/sbin/zfcpconf.sh
[1, slide 23] and
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-post-installation-fcp-attached-luns-s390#sect-post-installation-fcp-attached-luns-persistent-s390

Next, I would enable multipath tools. If they're not installed yet:
# yum install device-mapper-multipath
The following RHEL-specific command should perform the steps Mark outlined.
# mpathconf --enable --with_multipathd y
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/dm_multipath/mpio_setup

If the system has not used multipath devices (not even with only a single path)
so far, then things become somewhat tricky, as you would need to lift a system
running on a single path SCSI disk device to the new multipath layer on top.
This is not possible during runtime, so it needs some preparation and a reboot.
[1, slide 16] might help with terminology and device names.
Lifting might include but is not necessarily limited to adapting:
root=... in kernel parameters, root-fs mount info in /etc/fstab.
(If LVM is involved, its indirection eases things, as typically no single path
SCSI disk device names appear, but LV names and they remain the same even over
multipath.)

Mark is right about rebuilding the initramfs [my above cited doc probably
erroneously tells otherwise]. You might need to persuade dracut to include
multipathing in initramfs even though the system might not yet use it:
# dracut -f --add multipath

Finally, re-write the boot record so zipl will find the new initramfs and new
kernel parameters on subsequent boots:
# zipl

Then reboot.

Reference:
[1]
http://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf?cm_sp=dw-dwtv-_-linuxonz-_-presentation-PDF
which is listed on https://developer.ibm.com/tv/linux-ibm-z/

--

HTH

Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Replacement the root disk with a larger disk (without LVM)

[Steffen Maier]

On 9/12/19 5:19 PM, Marcy Cortes wrote:

Just went through all this a while ago!

Here's my instructions for my 101 -> 201 move

2. Enlarge the 101 disk if not already 1000 cyl (non LVM)
# Allocate a 1000 cyl disk at address 201

vmcp link \* 201 201
chccwdev -e 201
# Lsdasd - get new disk letter
dasdfmt -f /dev/dasd? -b 4096
fdasd -a /dev/dasd?
mke2fs -j -b 4096 /dev/dasd?1
mount /dev/dasd?1 /mnt
cd /mnt
rsync -lPprvtaxS / .
cd /
for fs in dev proc sys; do mount --bind /$fs /mnt/$fs; done
chroot /mnt
mount -a


Marcy's instructions are great.

Please note, that there may be (other) cases where you need to also rebuild
your initrd with mkinitrd before re-writing the boot record with zipl.

Though, probably not in your case, as you made the new disks have the old
devnos, so the Linux device configuration content does not need to change,
making it a lot easier. :-)

FYI: While it's "mkinitrd && zipl" with SLES11
 [http://public.dhe.ibm.com/software/dw/linux390/docu/les3dd03.pdf
  Chapter "Chapter 3. Kernel and module parameters"
  Section "Specifying module parameters"
"Including module parameters in a boot configuration"]
it will be "dracut -f && grub2-install" once you're with SLES12

[https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_pitfall_scsi.html].


zipl
exit
# Edit directory entry and switch the 101 and 201 disks



-Original Message-
From: Linux on 390 Port  On Behalf Of Csaba Polgar
Sent: Thursday, September 12, 2019 8:06 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Replacement the root disk with a larger disk (without LVM)

Hello,

We have many system with SLES 11 SP4, and would like to upgrade these to
SLES 12 SP4.
The the root filesystem (/, on dasd 201, with ext3, and without LVM, simple
dasd) has the OS (itself the Linux, without the applications).
But this root filesystem is too small for the upgrade. So, I did the
following steps;
- I requested a new and larger disk (on 209 address)
- after the shutdown, I formatted the new disk (209) as ext3 (from another
Linux system)
- copied the full content from the small disk (201) to the larger disk
(209, with "rsync -avxHAX --progress /sourcepath/ /targetpath/" command,
with the other Linux)
- I changed the addresses of the disks in the Guest definition:
 from 201 -> to 1201
 from 209 -> to 201
- And I started the new guests, but the boot failed.

After it I compared the successful and unsuccessful boot logs, and I think
the below lines show the root cause of the fail;
in the successful log:
  dasdb:VOL1/  LBX201: dasdb1
in the unsuccessful log:
  dasdb:VOL1/  LBX209: dasdb1
In the unsuccessful log show, the 209 dsk address, but I use the new 201
dasd, and the 209 should not be important for the boot.

Somebody knows, what should be changed/updated for the usage of larger and
replaced root disk ?

FYI, the last error messages:


Before that you presumably got an error when the Linux kernel tried to open its
ramdisk.


Kernel panic - not syncing: No init found.  Try passing init= option to kernel.


After the file system based copy, the initrd can be at a different logical
block location on the disk, so zipl with the old "bootmap" cannot find it
anymore. Zipl can then just load whatever data is at the blocks defined in the
old bootmap. The init process (user space binary executable) for preparing and
mounting the actual root-fs is inside the initrd. The Linux kernel cannot
continue booting without an init process. That causes the final init panic.

[see also https://www.mail-archive.com/linux-390@vm.marist.edu/msg61407.html
 / http://www2.marist.edu/htbin/wlvtype?LINUX-VM.85131 for more details]

--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Redhat 8.1 error

[Steffen Maier]

On 9/10/19 6:54 PM, Adolph Kahan wrote:

Jake, I installed into an LPAR using FTP server running on Intel Based Linux.

Here is my prm file. This should be a single line


While it's certainly safe to have it as one single line, I think that bug was
fixed quite a while ago, so not only the kernel but also dracut, parsing many
of the installer/boot-specific pseudo kernel parameters, can deal with newlines
in the string. It might have been this change:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/commit/?id=9f0878540bdc8054dc2b45427eed957b9bd25f2d


inst.repo=ftp://user:password@ftpserver/ClefOS  
root=live:ftp://user:password@ftpserver/ClefOS/images/install.img ro 
ramdisk_size=4 cio_ignore=cio_ignore -r 0.0.d900,0.0.d901,0.0.d902,!condev 
rd.znet=qeth,0.0.d900,0.0.d901,0.0.d902,layer2=1 
ip=10.0.20.20::10.0.20.1:24:clefos1:enccw0.0.d900:none nameserver=10.0.20.254 
nameserver=10.0.20.253


IIRC, inst.repo= implies root= to find install.img within the file system of
the installation DVD. So root= is only necessary for very special cases to
override the automatic implication.

"cio_ignore -r 0.0.d900,0.0.d901,0.0.d902" looks like the syntax a user would
enter on the interactive (shell) command line invoking the s390-tool cio_ignore
to remove/free those device bus-IDs.
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lkdd/lkdd_r_cio_ignore_cmd.html

The parm file uses kernel parameter syntax.
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lkdd/lkdd_r_cioignoreparm.html

However, since RHEL6.0, all code parts dealing with onlining of CCW devices,
automatically deal with cio_ignore in the background transparently for the user.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/ch-parmfiles#ch-parmfiles-required
In this case. the rd.znet= parameter parsing code in dracut implicitly frees
its devbusids from cio_ignore before attempting to group them into a ccwgroup
and set the ccwgroup online. Likewise for rd.dasd= and rd.zfcp=.
IOW, the mechanism to onlining, which is required anyway, was extended to also
handle cio_ignore as they both use the same input information, namely device
bus-IDs.
Hence there is no need to modify the cio_ignore= kernel parm.

--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Redhat 8.1 error

[Steffen Maier]

On 9/11/19 10:37 AM, Jake Anderson wrote:

I tried again the first error message went off but this time message is
different



Ý  116.752969¨ anacondaÝ1837¨: Traceback (most recent call last):
Ý  116.753003¨ anacondaÝ1837¨:   File "/usr/sbin/anaconda", line 285, in  



Ý  116.753145¨ anacondaÝ1837¨: from blivet.devices import FcoeDiskDevice



Ý  116.753602¨ anacondaÝ1837¨: self.update_from_boot_cmdline()
Ý  116.753628¨ anacondaÝ1837¨:   File 
"/usr/lib/python3.6/site-packages/blivet/flags.py", line 104, in 
update_from_boot_cmdline
Ý  116.753655¨ anacondaÝ1837¨: self.get_boot_cmdline()
Ý  116.753681¨ anacondaÝ1837¨:   File 
"/usr/lib/python3.6/site-packages/blivet/flags.py", line 97, in get_boot_cmdline
Ý  116.753709¨ anacondaÝ1837¨: args = shlex.split(buf)
Ý  116.753735¨ anacondaÝ1837¨:   File "/usr/lib64/python3.6/shlex.py", line 
305, in split
Ý  116.753760¨ anacondaÝ1837¨: return list(lex)
Ý  116.753786¨ anacondaÝ1837¨:   File "/usr/lib64/python3.6/shlex.py", line 
295, in __next__
Ý  116.753811¨ anacondaÝ1837¨: token = self.get_token()
Ý  116.753840¨ anacondaÝ1837¨:   File "/usr/lib64/python3.6/shlex.py", line 
105, in get_token
Ý  116.753867¨ anacondaÝ1837¨: raw = self.read_token()
Ý  116.753905¨ anacondaÝ1837¨:   File "/usr/lib64/python3.6/shlex.py", line 
187, in read_token
Ý  116.753932¨ anacondaÝ1837¨: raise ValueError("No closing quotation")
Ý  116.753960¨ anacondaÝ1837¨: ValueError: No closing quotation


Looks like the storage component blivet of anaconda tries to parse the kernel 
commandline in order to configure FCoE, and it does not like what's in the 
kernel command line, probably a mis-balanced quote. The kernel command line 
comes from the parm file you booted the installer with.


--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Defined minidisks RHEL 6.0 on z/VM to grow / FS, forgot to Persistently Setting DASDs Online with /etc/zipl.conf and zipl.

[Steffen Maier]

uot;
HOSTNAME="linux8"
NETTYPE="qeth"
IPADDR="172.27.20.19"
SUBCHANNELS="0.0.0900,0.0.0901,0.0.0902"
NETMASK="255.255.0.0"
GATEWAY="172.27.20.254"




Basically, in the dracut (initrd) rescue shell you can manually prepare
all
necessary dependency (devices) for the root-fs. Then try to exit the
rescue
shell and it will try (again) to mount the root-fs and continue to boot.


https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut/dracut.html#accessing-the-root-volume-from-the-dracut-shell
(step 2 sounds quite like your use case with root-fs on LVM)


# lvm vgscan
# lvm vgchange -ay


--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Defined minidisks RHEL 6.0 on z/VM to grow / FS, forgot to Persistently Setting DASDs Online with /etc/zipl.conf and zipl.

[Steffen Maier]

Hi Roberto,

On 8/21/19 1:20 AM, Roberto Ibarra Magdaleno wrote:

I tried to IPL in rescue mode by doing these 2 configuration files:

RESCUE   PRM  A1

root=/dev/ram0 ro ip=off ramdisk_size=4 cio_ignore=all,]0.0.0009
inst.rescue


This looks like upstream (and RHEL7 or RHEL8) syntax
[https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-rescue],
whereas RHEL6 has an older slightly different syntax:

IBM Z:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/ch-parmfiles-miscellaneous_parameters

general (not everything applies to Z):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/ap-rescuemode#s1-rescuemode-boot

Does this help?

I think you don't even need the cms conf file for the rescue system, as the 
latter runs off the initrd and without network. The cms conf file is only 
parsed by the very early installer phase which should not run in rescue mode.



CMSDASD=191 CMSCONFFILE=redhat.conf

REDHAT   CONF A1

DASD="200-206"

HOSTNAME="linux8"

NETTYPE="qeth"

IPADDR="172.27.20.19"

SUBCHANNELS="0.0.0900,0.0.0901,0.0.0902"

NETMASK="255.255.0.0"

GATEWAY="172.27.20.254"



It does IPL the installation dialog but never the rescue system.





3. Log the guest off and attach the disks(s) to another, running system,.


Working on this from 1. Mounted its first DASD (200) and could read it,
didn’t found the /etc/dasd.conf needed.

Linked second DASD (201) tried to mount it, and couldn´t:

[root@rescue ~]# mount -t ext4 /dev/dasdf1 /lx8/20x

mount: wrong fs type, bad option, bad superblock on /dev/dasdf1,

missing codepage or helper program, or other error

In some cases useful info is found in sysl


Maybe I'm confused, but I thought your DASDs would be PVs in an LVM 
configuration so you would not mount the individual PVs, but they need to be 
assembled in an LVM VG and you would access some LV of that VG?


https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/physvol_display

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/vg_activate

Basically, in the dracut (initrd) rescue shell you can manually prepare all 
necessary dependency (devices) for the root-fs. Then try to exit the rescue 
shell and it will try (again) to mount the root-fs and continue to boot.


https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut/dracut.html#accessing-the-root-volume-from-the-dracut-shell
(step 2 sounds quite like your use case with root-fs on LVM)

I suppose you'd need to fixup your config files on the root-fs including
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_initrd_rebld.html 
[applies to RHEL6, too]

afterwards so any subsequent (re)boot will succeed without manual intervention.

--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Wait at IPL

[Steffen Maier]

On 4/29/19 8:43 PM, Bodra - Pessoal wrote:

I´m trying to load a DVD to construct a RAM Disk to install Red Hat 7.6
version and getting a disable wait PSW 0002000180112704

Where can I found what this means?


I usually look at the console to determine the root cause of a failing 
installer load.

For LPAR, it's the Operating System Messages on HMC/SE.
For z/VM guest, it's a 3270 terminal session to the guest.

Typical additional questions are:
How is the DVD connected to IBM Z?
(HMC DVD drive, FCP-attached DVD drive, DVD file system exported over network, 
etc.)

What's the content of the parm file used to load the installer?
[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-installer-booting-ipl-s390#sect-customizing-generic-prm-s390]

--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
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

Re: install a RedHat on LPAR (without z/VM), via HMC and from DVD

[Steffen Maier]

eir WWPNs:
$ ls /sys/bus/ccw/drivers/zfcp/0.0./0x*
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_fcp_wrk_pinfo.html


Logical unit number (As Logical unit number fill in the LUN of the DVD
drive as a 16-digit hexadecimal number. )


The SCSI-to-FCP bridge hardware appliance defines which SCSI ID, such as a DVD 
drive, appears as which FCP LUN on the FCP side of the bridge. It could be 
hardwired or defined through a management interface of the appliance.


I'm not sure a (RHEL6) installer ramdisk would contain enough tooling to 
perform a LUN discovery with zfcp. If only one DVD drive is attached to the 
SCSI-to-FCP bridge, you could just use trial and error by trying the following 
sequence of FCP LUNs until you found the one that corresponds to the DVD drive 
and works: 0x, 0x0001, 0x0002, ... 
0x0007, or maybe even up to 0x000f (to cover the SCSI 
ID range of ultra-wide (parallel) SCSI).



And I got stuck here. Could you please say me, how can I define or how can
I query these?

Regards / Mit freundlichen Grüßen / Üdvözlettel,

Csaba Polgar



--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
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

Re: RHEL Install in a LPAR

[Steffen Maier]

On 3/21/19 5:45 PM, Rob van der Heij wrote:

On Thu, 21 Mar 2019 at 16:04, Huckert, James A  
wrote:


Does anyone know a way to install RHEL on a EC13 without using the HMC?
I thought there was a way to format a volume from z/OS 2.3 and lay down
the needed files and boot RedHat.

Due to security concerns we are not allowed physical access to our HMC's
nor insert any kind of media into them.
Any suggestions or links to documentation on possible ways around this
would be greatly appreciated.


There was, but it may not have been used in the previous two decades.
http://home.iae.nl/users/rvdheij/linuxipl.html
I suspect it might still work.


At least for the IPL installer part, that might be combined with

RHEL6
Preparing
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/s1-steps-hd-installs-s390
"Using a Prepared ..."
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/s1-s390-steps-boot

However, the ISO and install.img for the installer phases following the IPL
typically reside on a Linux filesystem and I have no idea if and how you could
create such under z/OS.

Not sure if this still works with RHEL7 as I could not find the preparation
documentation any more, just how to IPL from something that was already 
prepared:
"Using a Prepared ..."
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-installation-overview-s390

Alternatively, installation over network is an option, if you want to avoid
using HMC storage for IPL/install. This requires the preparation of some
reachable network server.

But doesn't somebody at least need to trigger an LPAR load on the HMC in any
case to IPL the installer?

--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
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

Re: Question on auto lun scan

[Steffen Maier]

ng, and
auto lun scan processing during initrd and after initrd. Otherwise things can
be quite silence by default even for "error" cases:

linuxrc=trace scsi_mod.scsi_logging_level=4605 printk.time=1 ignore_loglevel

This provides a lot of output on the console.

Optionally also "shell=1", if you want to get a root shell at the end of initrd
processing to have a look what the device setup is at this boot point in time
before it attempts to mount the root file system.

linuxrc=trace and shell=1 are specific to SLES11 initrd [man 8 mkinitrd].
Kernel parameters:
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaaf/lnz_r_s114.html
Device Drivers, Features, and Commands on SUSE Linux Enterprise Server
Chapter 3. Kernel and module parameters
Chapter 38. Booting Linux

With SLES12, the initrd is from dracut and different.
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_c_ipl_kernparm.html
https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_description_7
https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut/dracut.html#debugging-dracut
https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut/dracut.html#dracutkerneldebug

For both SLES versions, the content of /etc/udev/rules.d/51-zfcp-*.rules
managed by "yast zfcp" and zfcp_{host|disk}_configure is also relevant.

--
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
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

Re: RHEL and HMC load from FTP

[Steffen Maier]

On 03/23/2018 09:49 AM, munif sadek wrote:

we have got couple of IFLs from IBM for our POC so all good.

I have activated my LPAR on IFL and can see LINUX on System Management
-> Partitions -> and LPAR icon.

Now when I am trying to use -RECOVERY -> Load from Removable Media or
Server, I am getting

"An error occurred while trying to obtain a list of software that can
be loaded. Please verify the information you entered and that the
correct media in the selected drive." ACT36201

IP Packet trace is:

Req: USER XX
Rsp: 331 Send password please.
Req: PASS XX
Rsp: 230 X is logged on.  Working directory is "XX.".
Req: PASV
Rsp: 227 Entering Passive Mode (NNN,NNN,NNN,NNN,8,58)
Syn Win=14600 Seq=2430599268 MaxSeg=1460 WScale=7 Sack-P TimeS...
Ack Syn Win=65535 Seq=2112466531 Ack=2430599269 MaxSeg=1460 WScale...
Ack Win=115 Seq=2430599269 Ack=2112466532 TimeStamp
Req: TYPE A
Rsp: 200 Representation type is Ascii NonPrint
Req: NLST /software/RHEL/generic.ins/.


The trailing slash strikes me odd.

HMC expects the directory, which contains some generic.ins, as path; not 
the .ins file itself as path. It does search the .ins file within the 
given path itself internally.



Rsp: 550 No data sets found.

But I can assure you DataSet or unix file generic.ins is there. May
someone help Please?

Regards

Munif



--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: Gold On LUN

[Steffen Maier]

On 09/08/2017 04:46 PM, Steffen Maier wrote:

On 09/08/2017 04:19 PM, Greg Preddy wrote:
gold server or in recovery mode, but if "It's all tooling, no direct 
editing of any config files with SLES." then how do we fix this?


You could run the customization in a chroot environment on the cloned 
disk, possibly on some central "staging"/provisioning Linux image also 
having (temporary) access to the cloned disk.


Or have the customization run very early during boot in custom additions 
to initrd/initramfs, especially before it activates LVM or even mounts 
the root-fs, basically before it touches disks in any way.


That was just from the top of my head. There might be other solutions.


Aren't there products that can already do this?
OpenStack?

In either case, you could invoke the tooling to generate the necessary 
config entries. (I assume the golden image has the "old" config entries 
already removed to be pristine, otherwise you could also use the tooling 
to remove these entries during customization.)


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: Gold On LUN

[Steffen Maier]

On 09/08/2017 04:46 PM, Steffen Maier wrote:

On 09/08/2017 04:19 PM, Greg Preddy wrote:
Bingo!  No NPIV so our only hope is fixing the clone with it mounted to 


NPIV won't solve clone customization. It just solves perfect access 
control. Your boot from the un-customized clone disk would fail with 
perfect access control because of access denied.


Well no second thought there's indeed more to NPIV: You could use zfcp 
automatic LUN scan, to get rid of a lot of places where a Linux disk 
image contains path information (target WWPN, FCP LUN) that would 
otherwise need to be changed as part of disk clone customization.


I suppose friends of disk clone provisioning also try to avoid any use 
of identifiers that change for a cloned disk, e.g. don't hardcode WWIDs 
in multipath.conf or elsewhere.


But all that's only part of still necessary further customization.

--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: Gold On LUN

[Steffen Maier]

On 09/08/2017 04:19 PM, Greg Preddy wrote:
Bingo!  No NPIV so our only hope is fixing the clone with it mounted to 


NPIV won't solve clone customization. It just solves perfect access 
control. Your boot from the un-customized clone disk would fail with 
perfect access control because of access denied.


gold server or in recovery mode, but if "It's all tooling, no direct 
editing of any config files with SLES." then how do we fix this?


You could run the customization in a chroot environment on the cloned 
disk, possibly on some central "staging"/provisioning Linux image also 
having (temporary) access to the cloned disk.


Or have the customization run very early during boot in custom additions 
to initrd/initramfs, especially before it activates LVM or even mounts 
the root-fs, basically before it touches disks in any way.


That was just from the top of my head. There might be other solutions.

In either case, you could invoke the tooling to generate the necessary 
config entries. (I assume the golden image has the "old" config entries 
already removed to be pristine, otherwise you could also use the tooling 
to remove these entries during customization.)



On 9/8/2017 9:05 AM, Scott Rohling wrote:

That depends on whether NPIV is enabled ...  otherwise this guest could
have the same access as the one it was cloned from..

Scott Rohling

On Fri, Sep 8, 2017 at 6:41 AM, Steffen Maier <ma...@linux.vnet.ibm.com>
wrote:


Volume access control (LUN masking / host mapping) should prevent access
to a golden volume. You'd still need to customize disk clones to make 
them

work but it should at least break early during boot and not accecss the
golden image (especially not writable and thus potentially destroying 
its

golden property).


On 09/07/2017 09:19 PM, Greg Preddy wrote:

I think that is it, we have no clue where SLES12 puts the info about 
LUNS

so don't know what to change where.



Here's the official top-level documentation for zfcp configuration:
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.
ibm.linux.z.lhdd/lhdd_t_fcp_wrk_on.html
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.
ibm.linux.z.lhdd/lhdd_t_fcp_wrk_addu.html

It's all tooling, no direct editing of any config files with SLES.

On overview of the same, although not yet full updated for SLES12, is in
(slides 33,35 for SLES):
http://www-05.ibm.com/de/events/linux-on-z/pdf/day2/4_Steffe
n_Maier_zfcp-best-practices-2015.pdf

But there's much more to customize in a golden disk image on the 
first use

of a disk clone...

Found some steps for cloning SLES11 that would most likely work if we 
were

SLES11.



http://www.redbooks.ibm.com/abstracts/sg248890.html?Open
"The Virtualization Cookbook for IBM z Systems Volume 3: SUSE Linux
Enterprise Server 12"

However, the authors moved focus from golden disk image cloning towards
different disk content provisioning techniques for technical reasons:
"Chapter 7. Configuring Linux for cloning
Linux operating systems over time tend to have more and more unique
identifiers, such as, with the introduction of systemd, a new machine ID
has been added. All of these identifiers must be re-created on the 
cloned

system. However, the process to know all these identifiers
and to re-create them requires in-depth knowledge of the golden image.
Failure to update all of these identifiers could cause unforeseen 
trouble
later, including the possibilities of data corruption or security 
issues.
If you are unsure of all of the unique identifiers for your golden 
image,

and you prefer not to follow the cloning process, refer to the automated
installation procedures for KIWI imaging instead. Find information about
these in the following chapters"

The older book version for SLES11 might contain more information on
cloning, but that's of course not necessarily fully applicable to 
SLES12.

http://www.redbooks.ibm.com/abstracts/tips1060.html?Open

NB: The book's own tooling/scripting contains the image clone
customization details.

On 9/7/2017 10:34 AM, Karl Kingston wrote:



Check your FCP definitions on linux.   You may find they are still
referencing your gold
system.

On Thu, 2017-09-07 at 11:31 -0400, Grzegorz Powiedziuk wrote:


Hi
What do you mean it still mounts a  gold LUN? You boot from from a 
NEW

Lun
but root filesystem ends up beeing mounted from GOLD Lun?
First of I all I would make sure that GOLD lun after clonning is not
accesible in virtual machine anymore. Just to make it simple.

I can't remember how it is done in SLES but in RHEL there is a 
bunch of

stuff that refers to a specific LUN with a specific scsi_id

For example multipath (/etc/multipath.conf)  configuration. In 
there you

usually you bond scsi_id (wwid) of Lun with friendly name (mpathX for
example).
That multipath configuration is also saved in initrd. So if you boot
from
clone, it will end up mounting wrong volume.

Are you using LVM?






2017-0

Re: Gold On LUN

[Steffen Maier]

Volume access control (LUN masking / host mapping) should prevent access 
to a golden volume. You'd still need to customize disk clones to make 
them work but it should at least break early during boot and not accecss 
the golden image (especially not writable and thus potentially 
destroying its golden property).



On 09/07/2017 09:19 PM, Greg Preddy wrote:
I think that is it, we have no clue where SLES12 puts the info about 
LUNS so don't know what to change where. 


Here's the official top-level documentation for zfcp configuration:
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_fcp_wrk_on.html
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_fcp_wrk_addu.html

It's all tooling, no direct editing of any config files with SLES.

On overview of the same, although not yet full updated for SLES12, is in 
(slides 33,35 for SLES):

http://www-05.ibm.com/de/events/linux-on-z/pdf/day2/4_Steffen_Maier_zfcp-best-practices-2015.pdf

But there's much more to customize in a golden disk image on the first 
use of a disk clone...


Found some steps for cloning 
SLES11 that would most likely work if we were SLES11.


http://www.redbooks.ibm.com/abstracts/sg248890.html?Open
"The Virtualization Cookbook for IBM z Systems Volume 3: SUSE Linux 
Enterprise Server 12"


However, the authors moved focus from golden disk image cloning towards 
different disk content provisioning techniques for technical reasons:

"Chapter 7. Configuring Linux for cloning
Linux operating systems over time tend to have more and more unique 
identifiers, such as, with the introduction of systemd, a new machine ID 
has been added. All of these identifiers must be re-created on the 
cloned system. However, the process to know all these identifiers
and to re-create them requires in-depth knowledge of the golden image. 
Failure to update all of these identifiers could cause unforeseen 
trouble later, including the possibilities of data corruption or 
security issues.
If you are unsure of all of the unique identifiers for your golden 
image, and you prefer not to follow the cloning process, refer to the 
automated installation procedures for KIWI imaging instead. Find 
information about these in the following chapters"


The older book version for SLES11 might contain more information on 
cloning, but that's of course not necessarily fully applicable to SLES12.

http://www.redbooks.ibm.com/abstracts/tips1060.html?Open

NB: The book's own tooling/scripting contains the image clone 
customization details.



On 9/7/2017 10:34 AM, Karl Kingston wrote:
Check your FCP definitions on linux.   You may find they are still 
referencing your gold

system.

On Thu, 2017-09-07 at 11:31 -0400, Grzegorz Powiedziuk wrote:

Hi
What do you mean it still mounts a  gold LUN? You boot from from a 
NEW Lun

but root filesystem ends up beeing mounted from GOLD Lun?
First of I all I would make sure that GOLD lun after clonning is not
accesible in virtual machine anymore. Just to make it simple.

I can't remember how it is done in SLES but in RHEL there is a bunch of
stuff that refers to a specific LUN with a specific scsi_id

For example multipath (/etc/multipath.conf)  configuration. In there you
usually you bond scsi_id (wwid) of Lun with friendly name (mpathX for
example).
That multipath configuration is also saved in initrd. So if you boot 
from

clone, it will end up mounting wrong volume.

Are you using LVM?




2017-09-07 9:08 GMT-04:00 Greg Preddy <gpre...@cox.net>:

All,

We're doing SLES 12 on 100% LUN, with gold copy on a single 60GB LUN.
This is a new cloning approach for us so we're not sure how to make 
this
work.  Our Linux SA got the storage admin to replicate the LUN, but 
when

we change the server to boot the copy, it still mounts the gold LUN.
99% sure we got the LOADDEV parms right.  Does anyone have steps to
clone a LUN-only SLES 12 system?


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: Single user (rescue target) in SLES 12

[Steffen Maier]

On 06/27/2017 12:34 AM, Marcy Cortes wrote:

Thanks!  That is easy to remember!



-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Monday, June 26, 2017 3:15 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Single user (rescue target) in SLES 12


On 6/26/2017 at 03:26 PM, Marcy Cortes <marcy.d.cor...@wellsfargo.com> wrote:

One thing I haven't figured out in SLES 12 systemd system is how to
boot into single user mode (rescue.target)?
On sles 11, I just did a #cp vi vmsg 1 1

Anyone know?


You should be able to do this:
IPL devno PARM S


Doesn't this take you to single user mode of the "auxiliary" 
kernel, i.e. the one of grub2-s390x-emu, rather than your 
"target" / production kernel which can be quite different?


[Similarly with SCPDATA instead of PARM if you would IPL from FCP/SCSI 
instead of from DASD.]


https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_c_ipl_vs_boot.html

CAVEAT:
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_c_parms_spec.html#parms_caution__section_bad_kparms


I only know of grub2-s390x-emu support to select a particular grub.conf 
menu entry.


https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_grub2_parms.html


For any other dynamic changing of kernel parameters for the target 
kernel, I only know of the interactive grub2 prompt.


https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_grub2_zseries.html

https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_grub2_file_structure.html#sec_grub2_menu_change

--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: SLES12 boot error after clone

[Steffen Maier]

On 05/09/2017 01:57 AM, Dave Myers wrote:

A bootable SLES12 SP1 system was cloned using flashcopy.
All minidisks on the clone are the same virtual address.

At boot on the clone we get:

IPL 201
Booting default (grub2)
dasd-eckd 42a207:  0.0.0200:  The specified record was not found.


https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.l0kmsg.doc/l0km_m_dasd-eckd.42a207.html



1.  What's the most likely cause for this error?

2.  What script/files do we need to tweak to fix it ?

Note:  On the golden copy, 200 is the root,  201 is a swap file.


Thanks,
Dave


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: Dump volumes made with zipl -d

[Steffen Maier]

On 05/01/2017 10:20 PM, Marcy Cortes wrote:

Is my dump volume made with zipl -d on SLES 11 SP4 still good for SLES 12 SP2?
Would be nice not to have 2 of them.


There might be some differences regarding SMT (and maybe also SIMD) 
support but I'm not sure that's really all to take into account:


https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdt/lhdt_c_intro.html

https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdt/lhdt_c_sharedev_diffvers.html

(OT:
Since SLES12, the zfcpdump standalone dump tool for dumping to 
zFCP-attached SCSI disk now also uses partition '-d' (as DASD has been)


https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdt/lhdt_t_scsixmp1.html

instead of filesystem '-D' as with SLES11

https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ledt/ledt_t_scsixmp1.html
)

--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: zFCP /dev naming

[Steffen Maier]

target port (fc_rport) maps to a scsi target 
(unpredictably numbered from zero on dynamic port discovery and allocation).
The LUN levels in a hex representation are 0x. Since the 
use starts at level 1 and expands to higher levels depending on the LUN 
format, the smallest LUNs in hex representation starting with LUN 0 and 
incrementing by one are:

0x
0x0001
0x0002
0x0003
...

In order to be somewhat compatible to the old parallel SCSI transport 
(T10 SPI) [http://www.t10.org/drafts.htm#SCSI3_PAR, 
http://www.t10.org/scsi-3.htm], Linux uses half-word (u16) shuffling to 
have (single level) peripheral device addressing LUNs appear with the 
same small decimal numbers starting at zero as SPI. While it might look 
like endianess conversion, it is different. So above numbers appear as 
Linux scsi lun:

0
1
2
3
...

By-path names for FCP in the common code naming scheme, happen to format 
LUN as decimal if the LUN value is <256, else as full 16 hex digit with 
leading '0x'.


https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-path_id.c#L65
function format_lun_number()
NB: Since a while the Linux kernel does support full 64 bit LUNs, so the 
comment in systemd regarding (upper) 32 bit LUNs is kind of outdated and 
it seems systemd by-path could not properly format such LUN if it made 
use of LUN levels 3 or 4.


# lsscsi
[0:0:1:1]diskIBM  2145   /dev/sdb

# lsscsi -x
[0:0:1:0x0001]  diskIBM  2145  
/dev/sdb


# lsscsi -xx
[0:0:1:0x0001]  diskIBM  2145  
/dev/sdb


# l /dev/disk/by-path/total 0
lrwxrwxrwx 1 root root  9 Apr 27 11:56 
ccw-0.0.50c0-fc-0x500507680b2281fb-lun-1 -> ../../sdb

lrwxrwxrwx 1 root root  9 Apr 27 11:56 scsi-0:0:1:1 -> ../../sdb

while the compat rule shipped with SLES12 SP2 would additionally create 
the old zfcp-specific always hex name:


lrwxrwxrwx 1 root root  9 Apr 27 11:56 
ccw-0.0.50c0-zfcp-0x500507680b2281fb:0x0001 -> ../../sdb



but in non-z architectures lun tends to be a number between 0
and 255.


This seems an urban legend I would like to get rid of.
The format of a LUN has nothing to do with the initiator (host) or its 
architecture.
It is solely the storage target which decides on a LUN format and 
exports LUNs in this format (see also REPORT LUNS SCSI command [T10 SPC] 
which is used for automatic LUN scanning on any initiator architecture). 
[http://www.t10.org/drafts.htm#SPC_Family]


See also Slide 10 "Logical Unit Numbers (LUNs)" in 
http://www-05.ibm.com/de/events/linux-on-z/pdf/day2/4_Steffen_Maier_zfcp-best-practices-2015.pdf.


The only indirect relation to the initiator is with some storage target 
types, such as IBM DS8000: To export LUNs to an initiator, one defines 
"host mappings" based on initiator WWPNs (typically the NPIV WWPNs of 
FCP devices on s390x). A host mapping or volume group has some property 
regarding the initiator "type", in order to chose some specific settings 
regarding target behavior to work optimally with the initiator type.
The host type "Linux on z" happens to also select the LUN mapping scheme 
"SCSIMASK" as property resulting in 0x40xx40yy, where xx is the 
LSS and yy the storage internal volume ID within this LSS. This is 
pseudo flat space addressing but with 2nd level, which can address 65536 
LUNs.
Other host types, including Linux on x86, happen to select the LUN 
mapping scheme "SCSIMAP256" resulting in 0x00zz, where zz is 
a freely selectable 256 bit number resulting in an independent mapping 
of internal volume ID xxyy to external LUN zz. This is T10 SAM 
peripheral device addressing LUN format, which can only address 256 LUNs.
While not qualified, one could export LUNs with SCSMAP256 to Linux on z, 
but I would not recommend it.


Other storages, such as IBM Storwize, do not use this initiator type 
distinction, and so even Linux on z typically sees LUN formats of type 
peripheral device addressing (and for LUNs > 256 FlashSystems switches 
to a (single level) flat space addressing scheme of 0x4zzz which 
can address 16384 LUNs).
Storages sometimes also use the bus identifier field of (single level) 
peripheral device addressing LUNs to address more than the strictly 
speaking possible 256 LUNs [e.g. 0x025f above].


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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-

Re: Installing RHEL 7

[Steffen Maier]

Hi Mike,

On 11/17/2016 01:15 PM, Michael MacIsaac wrote:

Is there any documentation on how to install RHEL 7 using DHCP?

The current "Cookbook" only shows how to static IP (who wrote that thing?
:)) The Red Hat documentation on line alludes to DHCP, but does not have a
specific example - perhaps I'm missing it.


The RHEL installation guide describes (a subset of) the "ip=" (pseudo) 
kernel parameter syntax:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/chap-installer-booting-ipl-s390.html#sect-customizing-generic-prm-s390
refers to:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/chap-anaconda-boot-options.html#list-boot-options-network
(It also occurs in the x- and p-specific network install chapter of 
which some parts are common code and also apply to z:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/chap-installation-server-setup.html)

I think omitting the "ip=..." entirely also defaults to dhcp.

A kickstart file itself also has some dhcp syntax (network 
--bootproto=dhcp):

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-kickstart-syntax.html#sect-kickstart-commands


On z Systems you likely still need "rd.znet=..." if you use a native 
network device.



The full syntax of the ip= parameter (not sure if RHEL supports all of 
this) is described for the dracut upstream project in 
https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_network.


The anaconda upstream documentation has its own (subset?) copy under 
https://github.com/rhinstaller/anaconda/blob/master/docs/boot-options.rst#network-options 
or 
https://rhinstaller.github.io/anaconda/boot-options.html#network-options, 
but since RHEL7 uses dracut even for the installer initrd it's the same 
mechanism as in my previous paragraph.



--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: Expanding disk

[Steffen Maier]

If Michael used "yast dasd" to enable the disk, this would have 
internally used dasd_configure and that indeed necessary part would be good.
However, there are more things necessary regarding root-fs to make it 
sufficient:


http://www.mail-archive.com/linux-390@vm.marist.edu/msg67867.html
http://www.mail-archive.com/linux-390@vm.marist.edu/msg67849.html
(I recommend to use "dracut -f" instead of "mkinitrd")

meanwhile we specifically give hints:

SLES12 
http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_pitfall_scsi.html#lhdd_t_pitfall_scsi


Ubuntu 16.04 
http://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.ludd/ludd_t_pitfall_scsi.html#ludd_t_pitfall_scsi


RHEL 7 
http://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_c_ipl_ramdisk.html 
(this book is a bit older than the other two and thus does not describe 
the steps in detail; they are: dracut -f && zipl; see also 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/chap-post-installation-configuration-s390.html#sect-post-installation-dasds-on-root-s390)


On 11/17/2016 12:57 AM, Marcy Cortes wrote:

This generally happens when you miss the dasd_configure step which adds it into 
/etc/udev/rules.d/


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Michael 
Weiner
Sent: Wednesday, November 16, 2016 3:55 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Expanding disk

Hi group!

I have created an LVM on root root and about a month ago I expanded / resized 
it using yast.

I formatted the DASD
CreAted the partition
Added the volume to vgroot
Expanded the LVM and finished.

Today I went to bring up the machine and it was complaining about lvroot that 
it was missing a disk.

If I followed the above process, why would the disk be missing?

Did I miss something?

Thanks!!!

Mike


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: zLinux backup solutions

[Steffen Maier]

[disclaimer: FCP rather than FICON point of view assumed in the 
following so there might be differences]


If your workload could live with an atomically consistent but "dirty" 
disk content, you could use online block device snapshot technologies. 
Maybe inside Linux with LVM snapshot. Storage servers can also do this 
for you without Linux CPU cycles and even more so they can support 
snapshot consistency groups which you need if some filesystem (or raw 
RDBMS table space) spans multiple volumes (such as with LVM striping).


There might be backup software solutions exploiting above, but that's 
beyond my knowledge.


On restarting your workload (such as Linux boot) after a restore of such 
snapshot content, the workload will see some consistent atomic disk 
content, but the content is not clean as in closed application files or 
as in unmounted filesystems. So the application/filesystem (or whatever 
read/writes from/to disks) needs to cope with that, e.g. by replaying a 
journal.


I suppose if you not only collect disk snapshots but before doing so 
suspend the Linux to disk (potentially with hypervisor support), you 
could resume such Linux with those disk snapshots and apps/fs would not 
even notice (because they slept and then wake up with the old state as 
if nothing happened inbetween). Suspending is of course already some 
kind of disruption or temporary outage taking some time as opposed to 
what I mentioned above.


On 11/09/2016 06:42 PM, Scott Rohling wrote:

I should have added that we will do a physical backup of zLinux in some
cases without quiescing - but it is always supplemented with a logical
backup..   The physical restore will normally give you a working zLinux ...
 any corrupted/missing/changed files can be restored via the logical backup
to bring things 'up to date'.

Scott Rohling

On Wed, Nov 9, 2016 at 9:39 AM, Scott Rohling <scott.rohl...@gmail.com>
wrote:


Yes - a logical backup solution --   TSM is an IBM solutionyou
need a backup client which can read your filesystems and send them to a
server for archiving/retrieval  

A physical backup of the hard drives will always require a quiesced system
for a clean backup.

Scott Rohling

On Wed, Nov 9, 2016 at 9:15 AM, Neal Scheffler <vmwiz...@gmail.com> wrote:


To get a clean backup of our zLinux servers we currently shutdown the
zLinux server and do full volume backups of its disks.

Is there some other method / product available that we could use to get a
clean backup without having to take an outage on the zLinux server?

Thanks,
Neal



--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: WWN change

[Steffen Maier]

On 10/28/2016 08:04 AM, Christer Solskogen wrote:

On Thu, Oct 27, 2016 at 6:55 PM, Alan Altmark <alan_altm...@us.ibm.com>
wrote:


On Thursday, 10/27/2016 at 02:32 GMT, "Cohen, Sam" <sam.co...@lrs.com>
wrote:

If you're not replacing the target SAN disks, then there are no changes

to z/VM or a Linux

connections (as long as the IOADDRS are unchanged).  Your SAN fabric has

to change for the new

WWPNS on the z.


The z13 includes support to retain the NPIV WWPNs during an upgrade.  Look
for the "Update I/O World Wide Port Number" task.  (Read it as "Update I/O
Serial Number Portion of WWPNs".)  This was previously an RPQ.

To the extent you keep the same IOCDS definitions and PCHID assignments,
you can keep the same NPIV WWPNs.



But we are changing the target SAN disks as well. And new SAN switches.


Since you seem to be changing both the initiator as well as the target 
side, there are two aspects (changing the switches is more or less 
transparent except for having to migrate the config of the old switches 
over to the new ones, and recabling of course):


Changing the initiator (mainframe) influences SAN switch zoning and 
host-mapping/LUN-masking on the storage target side. Alan's suggestion 
is to minimize the influences or even make it completely transparent.

See also slides 20, 22, and 48 in [1].

Changing the target (storage) influences SAN switch zoning and path 
configuration in Linux. I don't know if storages have similar 
possibilities to carry over old storage HBA port WWPNs as described for 
the mainframe above; if so it would be transparent.

Else:
If you use zfcp automatic LUN scanning then it would be transparent but 
only regarding path detection [1, slides 33 and 38].
Otherwise I would probably recommend to teach your Linuxes the 
information for all new (post-storage-migration) paths before doing the 
migration [1, slides 35 or 37] so it knows both old and new; just make 
sure e.g. via zoning that Linux only ever sees either the old or the new 
storage.


I fear the volumes on the new storage will get different WWIDs so they 
won't be added to the same path groups as the corresponding old volumes, 
so you might either need additional alias entries in multipath.conf or 
adapt fstab and kernel parameters to get to know the new multipath 
device names [1, slide 25]. If so, I think this must be disruptive, i.e. 
Linux shutdown before switchover and Linux boot after switchover (you 
need that Linux disruption likely anyway because you also change the 
mainframe unless you use something like live guest migration). Linux 
multipathing should detect and automatically use the new paths [1, slide 
30 and 32]. If you would like to clean up, you could start dynamically 
removing the old path information from your Linuxes [1, same slides as 
for adding path information above].


It's unfortunately tricky, so I'd recommend to practice this at least 
once with a small test environment.

Having the root-fs on DASD makes it at least a bit easier.

[1] 
http://www-05.ibm.com/de/events/linux-on-z/pdf/day2/4_Steffen_Maier_zfcp-best-practices-2015.pdf


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: udevadm question

[Steffen Maier]

On 08/25/2016 06:53 PM, Mark Pace wrote:

I'm having issues with that link also.

*To enable user-friendly names or to specify aliases:*

*In a terminal console, log in as the root user.*

*Open the /etc/multipath.conf file in a text editor.*

*(Optional) Modify the location of the /var/lib/multipath/bindings file. *

*The alternate path must be available on the system root device where
multipath can find it. *


Does your multipath volume contain your root-fs?
If not, you can definitely skip this optional step.


*Move the /var/lib/multipath/bindings file to /etc/multipath/bindings.*

*Set the bindings_file option in the defaults section of
/etc/multipath.conf to this new location. For example:*
On my system I don't have any of those files.
/etc/multipath.conf
/var/lib/multipath <-- that subdirectory does exist in /var/lib


The only relevant step for simple data volumes is
"5. (Optional) Specify your own names for devices by using the alias 
option in the multipath section."

(and 6 to save the changes)


On Thu, Aug 25, 2016 at 12:33 PM, Mark Pace <pacemainl...@gmail.com> wrote:


Thank you for the comments and the link.  I'll go looking there.

The manual I refer to is - SC33-8413-08 - How to use FC-attached SCSI
devices with Linux on z Systems


OK, thanks for letting me know.

Parts of this book are superseded by the more often updated
"Device Drivers, Features, and Commands" book
or respective distro documentation (for the case here).


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: udevadm question

[Steffen Maier]

Hi Mark,

On 08/25/2016 06:20 PM, Mark Pace wrote:

sles 11sp3

Working with FCP devices for the first time.
I have 2 devices that I am using to multipath.
I've followed the manual pretty well to multipath these devices.

 multipath -ll


multipathd -k'show topo'
is preferred because
- it only works if multipathd runs which is a requirement
- it does not cause unnecessary load due to extra path checks


36005076307ffd4da0028 dm-1 IBM,2107900
size=100G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=1 status=active
  |- 0:0:0:1076379648 sda 8:0  active ready running
  `- 1:0:0:1076379648 sdb 8:16 active ready running

So now I have this device with the really long name -
/dev/mapper/36005076307ffd4da0028
/dev/mapper/36005076307ffd4da0028_part1

In the manual it talks about using udev to map it to a more friendly name,
there it goes wrong. The manual talks about udevinfo, which doesn't exist,
it's part of udevadm, but that output doesn't look like the manual.

I'm looking for example of udevadm to add a rule to rename those to
something short and easy to remember.


Which manual do you refer to?

While udev can be used in general to rename devices,
for multipath devices there is a much easier common way to do this via 
alias names in multipath.conf:

https://www.suse.com/documentation/sles11/stor_admin/data/mpionames.html

--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: adding eckd disk space to KVM

[Steffen Maier]

On 03/29/2016 10:47 PM, Frank M. Ramaekers wrote:

Try this LISTSERV for zLinux related questions:

For LINUX-390 subscribe / signoff / archive access instructions, send
email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390=CwIFAg=JeEQba34pbypuH24NmkPeQmaR10xRxVB2BkB2ZkzOTA=GmMCqcCAb_PnEQRDX8l03QrVvBcsyg4O0tRLv9ePqZ8=xMmaxAbughh6nKAt
hEYZaNXRUne6rOXfXd1kN833fUc=Wyd1E0eqzUyWK19QqzMwAPHX36HsRih3BDtucvr5sqg=

Frank M. Ramaekers Jr.

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Michael Prahin
Sent: Tuesday, March 29, 2016 3:18 PM
To: ib...@listserv.uark.edu
Subject: adding eckd disk space to KVM

Now, that KVM is running in lpar and has a sles12 linux instance
under it, i have increased demand for disk space there suddenly. I
created KVM with 16G disk and assigned 10G to sles12. so far it is
not very clear how to add another pack(s) to KVM short of
reinstalling it with new parm file.
Any ideas would be greatly appreciated.


Does this help, esp. the persistent part?:
http://www.ibm.com/support/knowledgecenter/SSNW54_1.1.1/com.ibm.kvm.v111.admin/addingdasds.htm

(or in case of FCP: 
http://www.ibm.com/support/knowledgecenter/SSNW54_1.1.1/com.ibm.kvm.v111.admin/addingfcpattachedlogicalunits.htm)


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: IPL from SAN

[Steffen Maier]

On 02/29/2016 02:21 PM, Rothman, Peter wrote:

This is per our Linux sysadmin.
I have asked him about the WWPN - FYI this was the posted.


We need the target WWPN which typically the storage and or SAN admin 
knows about.



The loaddev portname looks like the initiator WWPN of your local FCP=20
device 0.0.2000, so the open port fails as expected.
Portname should be (one of) the storage target WWPN(s) behind which your =

LUN is reachable (it must be the LUN that contains the "zipl target",=20
which is /boot with RHEL, and thus the zipl boot record).

Is there a way I can query the wwpn 'behind' the LUN?


From the host / Linux perspective, the LUNs are behind the target port 
WWPN.


In a running Linux, you can use "lszfcp -P" to see all target ports that 
zfcp could discover

[http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_fcp_wrk_pinfo.html
http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ldsg/ldsg_r_scsiipl_sanaddr.html]
If you don't have Linux running, you could use the z/VM tool SCSIDISC to 
discover target ports

[http://www-01.ibm.com/support/knowledgecenter/SSB27U_6.3.0/com.ibm.zvm.v630.hcpb7/scsidisc.htm],
or you can use "FCP SAN Explorer" on the HMC/SE
[presentation I referenced in an earlier mail].

Depending on your zoning and LUN masking you need to chose the correct 
target port if multiple ports were discovered.


Earlier you wrote that you could successfully install and reboot.
Alternatively, you can use such a running Linux instance and run 
"lsreipl" to figure out the necessary FCP addressing parameters for a 
manual IPL. The Linux distribution installer figured this out already.

[http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_r_lsreipl_cmd.html]


Our storage guys always zone the storage to/for the WWPN that CP displays via 
the Q FCP command.


The zone also contains the storage target port(s) which the host / 
initiator needs for accessing the LUNs.



--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: IPL from SAN

[Steffen Maier]

On 02/26/2016 06:39 PM, Rothman, Peter wrote:

We completed a kickstart 'to SAN' with RHLE 7.2.
A linux 'shutdown reboot' worked OK but now a IPL from the FCP device fails.
What am I missing?

Here is the console:
q loaddev
PORTNAME C05076E4 5D1CLUN   BOOTPROG 2


The loaddev portname looks like the initiator WWPN of your local FCP 
device 0.0.2000, so the open port fails as expected.
Portname should be (one of) the storage target WWPN(s) behind which your 
LUN is reachable (it must be the LUN that contains the "zipl target", 
which is /boot with RHEL, and thus the zipl boot record).


If you want to boot zipl menu entry 2, then the bootprog setting is OK; 
otherwise you may want to try the default zipl menu entry with "bootprog 0".



BR_LBA    

SCPDATA
  0+1+2+3+4+
 NORESUMENORESUMENORESUMENORESUMENORESUMENORESUMENO
0050 RESUMENORESUME


the scpdata looks funny, so once the SCSI loader will work with a proper 
loaddev, this could cause kernel boot issues (or it just ignores it as 
unknown kernel parameter)



  q fcp attach dztpc001
00: FCP  FE07 ATTACHED TO DZTPC001 2000 CHPID 52
00:  WWPN C05076E45D1C



00: MLOFCP009E: Unable to open target port with WWPN 0xc05076e45d1c (d_id 0x
00: 00035519) on adapter 0.0.2000.


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: Z linux boot from SAN

[Steffen Maier]

Hi Peter,

On 02/22/2016 05:17 PM, Rothman, Peter wrote:

I have been tasked with creating a linux system to boot from SAN for a POC.
This is RHEL 7 so any info on the 'kickstart' part would also be helpful
I was told it is needed ASAP.

Can you please point me to the relevant documentation to do this so I
can cut down on some of the investigation time.


Assuming your SAN is FCP (as opposed to FICON/ECKD):
http://www-05.ibm.com/de/events/linux-on-z/pdf/day2/4_Steffen_Maier_zfcp-best-practices-2015.pdf
particularly the following slides:

25 Multipathing for Disks – Persistent Configuration
"use multipathing on installation"

36 LUN Management with ZFCP: RHEL Installation
includes (blue) clickable hyperlinks directly into RHEL documentation 
including kickstart


40 SCSI IPL

44 More Information (repeats hyperlinks into relevant documentation parts)

for more details:
http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_fcp_wrk.html
http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_fcp_wrk_addu.html

--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: ZFCP lun status command?

[Steffen Maier]

On 02/15/2016 03:13 PM, James Vincent wrote:

Does anyone know of a way to get info/status on luns on FCPs that are _not_
active (failed state)?

This is the scenario:
zLinux machine with one active lun (non-NPIV)
A new lun 0x000e was added to /etc/zfcp.conf (yes, triple
checked content for accuracy)
Ran zfcpconf.sh - no errors, no kernel messages, NO DEVICE added in
/dev/mapper
Ran multipath -ll - nothing to report; new lun had no info there
Ran lsluns - can see the old and new lun in the list (there is a -a flag in
lsluns which shows the active luns, but nothing to show 'failed' luns)

Finally traversed down one of the FCPs
to /sys/bus/ccw/drivers/zfcp/0.0.0100/0x5973001c8d9c/ and noted both
luns are there; looked in the 0x000e directory and failed is 1
and status is 0x6080  So the lun didn't get added as a device, but


This status is really only zfcp driver internal for debugging by service 
and development and therefore not documented nor should anyone rely on 
particular values with stable semantics in here.



nothing told us that - no errors/msgs at all.


Just a shot in the dark: Did you get a kernel message (dmesg or syslog 
(the latter depends on syslog config and might suppress such kernel 
message) like the following?:


": LUN 0x on port 0x 
is already in use by CSS, MIF Image ID ID of the LPAR>"


[http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaaf/lnz_r_km.html
http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.l0kmsg.doc/l0km_m_zfcp.747e7d.html]

See also the access_denied sysfs attribute description for zfcp units in 
our device drivers book.
[SLES12SP1 
http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_fcp_wrk_actinfo.html
RHEL7.2 
http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_fcp_wrk_actinfo.html]



I was hoping there was something more better to run to tell me that though.
  ie, lsluns -f (for failed) or lsluns -s (to show the full status of the
luns)

Does anyone have an idea of how to show lun status info like this easier?


After zfcp created the zfcp unit successfully, the next step is scsi 
midlayer LUN probing. This can fail, e.g. due to wrong host mapping of 
the LUN on the storage server. Unfortunately, Linux does not emit 
anything in such case with the default debug levels.
You can debug this further by setting an appropriate scsi_logging_level 
to see what the midlayer does and why it fails to finally create a 
scsi_device belonging to the zfcp unit.

[http://www-05.ibm.com/de/events/linux-on-z/pdf/day2/4_Steffen_Maier_zfcp-best-practices-2015.pdf]

Once there is a scsi_device, and it is of type random access (disk), it 
would create a scsi disk device which can then be assembled into a 
multipath device.


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems 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/

Re: Losing SAN Adapters with RHEL5 servers after patching

[Steffen Maier]

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

Re: Losing SAN Adapters with RHEL5 servers after patching

[Steffen Maier]

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
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
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/

Re: WWPN changes

[Steffen Maier]

On 06/17/2015 01:50 PM, Mainframe Mainframe wrote:

   Thanks for reply . I am new in this configuration. I
checked the links provided in earlier email chain. But I am still not clear
the file where I will have to change the WWPN number .


Assuming you want to change paths to LUNs to use a different target 
WWPNs on a Linux, that was already installed and is currently running, 
then the slides

LUN Management with ZFCP: SLES/RHEL Post-Installation
would apply.

You use tools with SLES to remove paths with the old WWPN and add paths 
with the new WWPN.


You edit text files with RHEL.

More information for such distro specific information is in the distro 
documentation referred to at the bottom half of slide More Information.


Where appropriate, IBM also refers to distro documentation in the zfcp 
chapter of the book Device Drivers, Features, and Commands.



On Wed, Jun 17, 2015 at 3:45 PM, Steffen Maier ma...@linux.vnet.ibm.com
wrote:

On 06/17/2015 07:45 AM, Mainframe Mainframe wrote:


We are using SUSE 11.2 z/Linux system with FCP channels. There are  issues
with one host that WWPN  being dropped .
So, now we want to use different WWPN number for this host and bring up
again.



  2) Somewhere in z/Linux kernel. I am not sure the exact location


Can anybody help me making this WWPN changes in z/Linux kernel  .



Linux configuration only deals with storage target WWPNs.
Pointers are in a presentation I referred to earlier:
http://www.mail-archive.com/linux-390@vm.marist.edu/msg67433.html



--
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/

Re: WWPN changes

[Steffen Maier]

On 06/17/2015 07:45 AM, Mainframe Mainframe wrote:

We are using SUSE 11.2 z/Linux system with FCP channels. There are  issues
with one host that WWPN  being dropped .
So, now we want to use different WWPN number for this host and bring up
again.


Do you really mean the WWPN for host as in Fibre Channel host (Linunx 
fc_host), i.e. the initiator WWPN of the FCP device itself?


Why?

It's the machine (not the OS) that automatically manages initiator WWPNs;
both the physical WWPN of the FCP channel as well as all the virtual 
WWPNs of NPIV-enabled FCP devices of FCP channels.
Both contain an IBM OUI prefix and something derived from the CEC's I/O 
serial.

NPIV WWPNs also contain an automatically generated suffix.
Physical Channel WWPNs also contain the PCHID followed by 1 as 4 
trailing hex digits (as of z196).

http://www.redbooks.ibm.com/redbooks/SG247266/wwhelp/wwhimpl/api.htm?href=10-1-1.htm


For doing this, as per my knowledge we have to change entries in two places

1) z/VM text file, which is used while z/Linux comes up and have network
related information etc.


If you refer to the parm file used to pass kernel parameters at 
boot/IPL, then this does not deal with initiator WWPNs.
Only for some distro installers it can be used to configure LUNs but 
that involves storage target WWPNs.



2) Somewhere in z/Linux kernel. I am not sure the exact location

Can anybody help me making this WWPN changes in z/Linux kernel  .


Linux configuration only deals with storage target WWPNs.
Pointers are in a presentation I referred to earlier:
http://www.mail-archive.com/linux-390@vm.marist.edu/msg67433.html

--
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/

[no subject]

[Steffen Maier]

On 06/09/2015 09:22 AM, Mainframe Mainframe wrote:

Hello Group,
   Currently we facing below issue.

*Issue : *

/scratch is on dasda1 device. We need mount sda device on /scratch so that
we can do porting work.

Steps taken to solve issue :

# umount -l /scratch


This seems to be a lazy unmount, so you don't know when this mount point 
will be truely unmounted properly.



# fsck -y /scratch
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
fsck.ext3: Attempt to read block from filesystem resulted in short read
while trying to open /dev/sda1
Could this be a zero-length partition?


Maybe due to the lazy unmount, /scratch might be in some intermediate 
state or now even already belong to containing the root-fs(!), so 
calling fsck on that mount point seems dangerous.


A safe procedure might be to unmount without lazy option and then fsck 
the block device that used to be mounted on /scratch, i.e. /dev/dasda1.



*cat /etc/fstab*

LABEL=/ /   ext3
  defaults,usrquota,grpquota1 1
tmpfs   /dev/shmtmpfs   size=8045M0
0
devpts  /dev/ptsdevpts  gid=5,mode=620  0 0
sysfs   /syssysfs   defaults0 0
proc/proc   procdefaults0 0
/dev/sda1/scratch   ext3  defaults 1 0


*We changed *

/dev/sda1/scratch   ext3  defaults 1 0

to

/dev/sda1/scratch   ext3  defaults 1 2


You should always use multipathing instead of single path SCSI devices, 
otherwise you lack path redundancy.


How do you ensure that all the paths to this SCSI disk are persistently 
configured?
(SCSI devices don't appear fully automatically without any user action 
with Linux on z Systems.)
In other words, it could have been that there is no /dev/sda at all 
during fsck time on boot.


http://www-05.ibm.com/de/events/linux-on-z/pdf/day2/4_Steffen_Maier_zfcp-best-practices-2015.pdf


*So, that fsck run on reboot time  and we rebooted system and after reboot
I was getting below messages.*



Checking all file systems.
-/sbin/fsck.ext3 (1) -- /- fsck.ext3 -a /dev/dasda1
/: clean, 177325/5412928 files, 1517520/5408976 blocks
-/sbin/fsck.ext3 (1) -- /scratch- fsck.ext3 -a /dev/sda1
fsck.ext3: No such file or directory while trying to open /dev/sda1
/dev/sda1:
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
 e2fsck -b 8193 device

-FAILED-

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance


e2fsck -b 8193
Usage: e2fsck --panyrcdfvstDFSV- --b superblock- --B blocksize-
 --I inode_buffer_blocks- --P process_inode_size-
 --l|-L bad_blocks_file- --C fd- --j external_journal-
 --E extended-options- device

Emergency help:
  -p   Automatic repair (no questions)
  -n   Make no changes to the filesystem
  -y   Assume yes to all questions
  -c   Check for bad blocks and add them to the badblock list
  -f   Force checking even if filesystem is marked clean
  -v   Be verbose
  -b superblockUse alternative superblock
  -B blocksize Force blocksize when looking for superblock
  -j external_journal  Set location of the external journal
  -l bad_blocks_file   Add to badblocks list
  -L bad_blocks_file   Set badblocks list
(Repair filesystem) 2 #


Any solution of this issue.


--
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/

Re: Need assistance with a SAN install

[Steffen Maier]

On 05/21/2015 09:20 PM, Offer Baruch wrote:

If you set this kernel parameter you won't have to play around with the
udev rules:
zfcp.no_auto_port_rescan
Luns will be added dynamically when zfcp devices are brought online...


No, please don't mix up the different scans (and their workaround 
options) for different objects within zfcp.


There are two different scans introduced at different times for 
different objects within zfcp:

zfcp automatic *port* scan
which is something completely different from
zfcp automatic *LUN* scan.
Way too many users have already mixed up those things and I would like 
to avoid adding to the confusion.


Please see my best practices presentation
slides
LUN Management with ZFCP: 2 Methods
LUN Management with ZFCP: Automatic LUN Scanning for NPIV-enabled FCP 
Devices
Multipathing for Disks – Persistent Configuration (distinction of zipl 
target and root-fs is vital)

Zoning: No automatic port rescan on events

http://www-05.ibm.com/de/events/linux-on-z/agenda.html
http://www-05.ibm.com/de/events/linux-on-z/pdf/day2/4_Steffen_Maier_zfcp-best-practices-2015.pdf
( or as an alternative if above URL would vanish in the future, there's 
a 2014 Version (only missing updates for z13 and SLES12):

  http://www.vm.ibm.com/education/lvc/zlinlvc.html
  http://www.vm.ibm.com/education/lvc/LVC0924.pdf
  http://ibmstg.adobeconnect.com/p21fcc7jzr8/
)

--
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/

Re: Installing Linux on VM

[Steffen Maier]

On 08/12/2014 02:59 PM, Mark Post wrote:

On 8/11/2014 at 06:56 PM, Cameron Seay cws...@gmail.com wrote:

All:

I got an eval disk from SUSE for Enter 11.  I want to try out their KVM for
System z.  Do I just pop this in the DVD drive on the SE and IPL the LPAR?


Yes and no.  That is one of the ways to _start_ the install.  But you
will still need a network installation server to provide access to
the installation media once the network is up.


SLES additionally provides one method of IPL/boot/start of the installer 
*and* access stage2 and packages not over the (computer) network but 
over an FCP SAN:


https://www.suse.com/documentation/sles11/book_sle_deployment/data/sec_zseries_prep.html
HINT: IPL from DVD
SUSE Linux Enterprise Server on DVD
Using an FCP-Attached SCSI DVD Drive
LPAR Installation: IPL from FCP-Attached SCSI DVD
z/VM Installation: IPL from FCP-Attached SCSI DVD

(NB: This is only for FCP-attached SCSI *DVD*, neither SAN-attached DASD 
nor SCSI disk work for linuxrc/YaST on System z.)


Nevertheless, you would still need to setup a (computer as opposed to 
storage) network connection for interactive installations in order to 
have the installer present its user interface (vnc/x11/ssh).



This is because only
IBM knows how to access the DVD in the HMC from an operating system
running in an LPAR.  An open source method to do that is currently
going through IBM Legal, but it's not available yet.

So, since you need to have a working network from the HMC to an
installation server, you could just as well use the boot from remote
FTP server option on the HMC to kick things off.  Either way will
work.  Some sites just have more restricted access to the raised
floor.


Mark Post

--
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/



--
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/

Re: LUN connection problem SLES11 SP3

[Steffen Maier]

On 07/09/2014 03:47 PM, Rick Troth wrote:

On 07/09/2014 09:15 AM, Sollenberger, Justin W CIV DISA (US) wrote:

I'm assisting one of our SA's to add some FCP attached LUN's to a
new server.  We have many other servers on this LPAR already using
LUN's across the same connections with no issues.


is NPIV involved?


I'm able to run 'zfcp_host_configure 0.0. 1' with no issues.
Running 'zfcp_disk_configure 0.0. 0x
0x00nn 1' produces no errors or log messages but when
running 'lszfcp -D' it reports 'Error: No fcp devices found.'  I've
also attempted to add it in YaST, but upon clicking next when it
drops back to the main screen the LUN is not in the list.


I presume each guest has its own FCP adapter (or pair, recommended). If
NPIV is in play, and the other Linuxen are happy, then I'd suspect the
zoning and masking of this LUN. Check with your storage team. Is the LUN
wired to hit a different guest? (different FCP adapter(s))


If you don't see the necessary target port(s) with
# lszfcp -b 0.m. -P
(or the necessary ports are in failed state)
then it would be zoning.
But I doubt that because zfcp_disk_configure should have complained with 
WWPN xyz invalid and errorlevel 4 about the missing port.


I suppose the zfcp unit which zfcp_disk_configure created by means of 
the unit_add sysfs attribute ended up in failed state:
# cat 
/sys/bus/ccw/drivers/zfcp/0.m./0x/0x00nn/failed

1
[book Device Drivers, Features, and Commands,
Section Configuring SCSI devices,
If there is no SCSI device for this LUN, the LUN is not valid in the 
storage system, or the FCP device is offline in Linux.
After fixing LUN masking (see below), you can dynamically reprobe the 
LUN as in Section Recovering failed SCSI devices

http://www.ibm.com/developerworks/linux/linux390/distribution_hints.html]

LUN masking is indeed a probable root cause in this case.
Zfcp Traces won't help much here, since it just passes SCSI commands 
from the SCSI midlayer used for LUN probing to the FCP channel, but does 
not care or interpret the transferred SCSI sense codes.

In order to see what happens (or fails) on LUN probing
and to see if any SCSI error recovery is involved,
you can (temporarily, although the suggested log level won't adversely 
affect regular good path I/O) increase the scsi logging level:

# echo 4605  /sys/module/scsi_mod/parameters/scsi_logging_level
SCSI logging is done with kernel messages (dmesg) and depending on 
syslogd config kernel messages of certain severity levels end up in 
syslog (typically /var/log/messages).


To undo the loglevel increase:
# echo 0  /sys/module/scsi_mod/parameters/scsi_logging_level

--
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/

Re: VMRELOCATE problem with SAN file systems

[Steffen Maier]

On 06/11/2014 05:54 PM, Steffen Maier wrote:

On 06/11/2014 05:00 PM, Victor Echavarry Diaz wrote:

We install a couple of EC12 to our shop, upgrade some server to SLES
11 SP3 kernel 3.0.101-0.15-default under z/VM 6.2.  When we execute
the VMRELOCATE for some reason the SAN file system go read only. Our
previous configuration was an EC10, SLES 10 SP2 under z/VM 6.2. The
VMRELOCATE here works fine. Does anyone see this issue before? The
SAN is an IBM V7000. The Storage, Unix and DBA groups said their
configurations are ok.


Just a shot in the dark:

The builtin device-mapper multipath settings and documentation for SVC /
V7000 probably recommend something like no_path_retry 5 in
/etc/multipath.conf.

Since you temporarily lose all paths at the same time unavoidably during
LGR, you might need to reconfigure multipathing to always queue I/O
requests when all paths are gone instead of returning EIO (I/O error)
which in turn typically causes file systems to remount read-only (sooner
or later).


Just for the records the corresponding z/VM documentation:

z/VM 6.3.0
Planning and Administration
z/VM: CP Planning and Administration
Single System Image Clusters Planning and Administration
Preparing for Guest Relocations in a z/VM SSI Cluster
Supported Configuration for Relocation
http://www-01.ibm.com/support/knowledgecenter/SSB27U_6.3.0/com.ibm.zvm.v630.hcpa5/hcpa5313.htm

z/VM 6.3.0
Planning and Administration
z/VM: Getting Started with Linux on System z
Preparing for live guest relocation
Steps for performing a relocation for a Linux virtual server
http://www-01.ibm.com/support/knowledgecenter/SSB27U_6.3.0/com.ibm.zvm.v630.hcpl0/hcpl086.htm


Queueing requests can be configured with:
no_path_retry queue (or its alias feature queue_if_no_path).

https://www.suse.com/documentation/sles11/stor_admin/data/bbillhs.html
https://www.suse.com/documentation/sles11/stor_admin/data/bbj68de.html
https://www.suse.com/documentation/sles11/stor_admin/data/bbi89rh.html#b122sbgo

https://www.suse.com/documentation/sles11/stor_admin/data/be5rvii.html#bok8cn1
(actually I recommend to disable dev_loss_tmo entirely which might be
the SLES default anyway)
https://www.suse.com/documentation/sles11/stor_admin/data/mpioerrormgmt.html

https://www.suse.com/documentation/sles11/stor_admin/data/mpiostall.html

in case you use LVM:
http://www.novell.com/support/kb/doc.php?id=7007498



--
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/

Re: VMRELOCATE problem with SAN file systems

[Steffen Maier]

On 06/11/2014 05:00 PM, Victor Echavarry Diaz wrote:

We install a couple of EC12 to our shop, upgrade some server to SLES
11 SP3 kernel 3.0.101-0.15-default under z/VM 6.2.  When we execute
the VMRELOCATE for some reason the SAN file system go read only. Our
previous configuration was an EC10, SLES 10 SP2 under z/VM 6.2. The
VMRELOCATE here works fine. Does anyone see this issue before? The
SAN is an IBM V7000. The Storage, Unix and DBA groups said their
configurations are ok.


Just a shot in the dark:

The builtin device-mapper multipath settings and documentation for SVC / 
V7000 probably recommend something like no_path_retry 5 in 
/etc/multipath.conf.


Since you temporarily lose all paths at the same time unavoidably during 
LGR, you might need to reconfigure multipathing to always queue I/O 
requests when all paths are gone instead of returning EIO (I/O error) 
which in turn typically causes file systems to remount read-only (sooner 
or later).


Queueing requests can be configured with:
no_path_retry queue (or its alias feature queue_if_no_path).

https://www.suse.com/documentation/sles11/stor_admin/data/bbillhs.html
https://www.suse.com/documentation/sles11/stor_admin/data/bbj68de.html
https://www.suse.com/documentation/sles11/stor_admin/data/bbi89rh.html#b122sbgo
https://www.suse.com/documentation/sles11/stor_admin/data/be5rvii.html#bok8cn1 
(actually I recommend to disable dev_loss_tmo entirely which might be 
the SLES default anyway)

https://www.suse.com/documentation/sles11/stor_admin/data/mpioerrormgmt.html
https://www.suse.com/documentation/sles11/stor_admin/data/mpiostall.html

in case you use LVM:
http://www.novell.com/support/kb/doc.php?id=7007498

--
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/

Re: Adding a zfcp LUN to root file system logical volume

[Steffen Maier]

 remains fulfilled, it is possible, though it 
could be considered unsafe.

This matches the discussion Tomas Pavelka pointed to.

[1] 
http://www.ibm.com/developerworks/linux/linux390/s390-tools-1.8.3.html#changes

[2] http://www.ibm.com/developerworks/linux/linux390/distribution_hints.html



--
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/

Re: Adding a zfcp LUN to root file system logical volume

[Steffen Maier]

Hi Keith,

On 05/21/2014 02:05 PM, Keith Gooding wrote:

Thank you to everyone who responded. No, we did not run mkinitrd and
zipl after adding the second LUN to the root file system. When we
have added LUNs in the past it has been unnecessary because they were
not needed during boot - I started to understand this just after I
posted my question. (My linux knowledge is not very good - I
understand z/OS and system z in general and do the 'z' parts of
installing zLinux. A colleage who knows little about system z then
takes over. There seems to be a big gap in our combined knowledge,
but I have now learned something about the boot process - at least I
now understand that 'rd' in initrd stands for 'ram disk').

Unfortunately the volume groups in all of our systems are called
'VolGroup00' so I was not able to vgimport the group into a RH 5
system so I accessed it from a SUSE system which does not LVs so that
I could rename it. I was just about to import it into a RH 5 system
so that I could run initmkd and zipl under chroot when I read
Steffen's refernce to the restrictions with LVs in RH 5. The reason
for adding the second PV was that the first was full, so it is
possible that any new boot image will be created on the new physical
volume. I think this is getting too difficult.


I'm missing some setup information to make a valid statement here.
What does your /etc/fstab look like?

Since RHEL5 most likely does not support /boot (whether separately or
included in the root-fs) on multipathing or LVM (or any non-physical
block device(s)), don't you already have /boot separately on some
single-path /dev/sdXYNM ?
If so, adding PVs to your root-fs should not be a problem at all.


Re-installing with a
later release is probably more productive.

Incidentally I spent some time yesterday in attempting to enter
kernel parameters using the SCPDATA option of LOADDEV in zVM V5.
(a). I assumed that the parameters have to be in ascii so I entered
them in hexadecimal. (b). Is this method actually available for RH 5?


Linux kernel support for SCPDATA only appeared via upstream with kernel
2.6.32, so it's not available for RHEL5, but e.g. with SLES11 SP1 /
RHEL6 or later.

http://www.ibm.com/developerworks/linux/linux390/kernel-2.6.32.html
quote
Summary:
kernel: Extra kernel parameter for SCSI IPL
Description:
When booting from a SCSI boot device, you can now specify kernel
parameters in addition to the existing kernel parameters that are used
by your boot configuration. To specify kernel parameters, use the
SCPDATA option of the CP LOADDEV command or enter kernel parameters in
the 'Operating system specific load parameters' panel when IPLing a
system from the HMC.

Please refer to the 'Device Drivers, Features, and Commands' manual
(Documentation), Chapter 'Booting Linux', section 'Providing additional
kernel parameters when booting'.
/quote

It seems parameters have to be ASCII characters (not hex), otherwise
SCPDATA is ignored.
The used setting can be read from /sys/firmware/ipl/scp_data in the
IPLed kernel (where you could also reconfigure for an upcoming reboot
under /sys/firmware/reipl/fcp/scp_data).
It works for both a regular IPL as well as for an IPL of the SCSI
standalone dumper (zfcpdump).

I'd recommend to pick the device drivers book matching your distribution
from
http://www.ibm.com/developerworks/linux/linux390/distribution_hints.html
to get matching customized documentation.
You might look into more recent minor release books in case there were
documentation fixes.


- I found the reference in the RH 6 documentation. (c). If  SCPDATA
can be used with RH 5, what is the syntax of the zfcp options. I
asssumed that it was zfcp.device=0.0.,wwpn,lun but also


Please do not use the zfcp module parameter zfcp.device=.
It's only for test purposes and can only activate exactly one single
LUN. This is of course not sufficient for production environments with
=2 paths. RHEL and SLES use different methods to activate zFCP LUNs.


tried the rd.zfcp format from RH 7. Should it be 'rh_zfcp as in RH
6 or is it not available at all ?


Since RHEL5 does not have any pseudo boot parameter to activate zFCP
LUNs (it only takes info from inside initrd), passing parameters on boot
most probably won't help you with RHEL5.
Hence, you were absolutely right attaching the disk(s) somewhere else
and recreating initrd in a chroot environment.

This only works with RHEL6 (rd_ZFCP= and it's case sensitive!)
or RHEL7 (rd.zfcp= also case sensitive!).



Keith
On Wednesday, 21 May 2014, 11:21, Steffen Maier ma...@linux.vnet.ibm.com 
wrote:



Hi Keith,

On 05/20/2014 02:36 PM, Keith Gooding wrote:

We installed a RH 5.2 system where the root file system is on a
logical volume comprising a single physical volume which is on zFCP LUN.
Later we added another zFCP LUN, updated zfcp.conf and added the
physical volume to the LV. This appeared to be OK until we had a
scheduled reboot of the system.


Did you run mkinitrd and then zipl after

Re: Red Hat Kick Start prompts to Format DASD

[Steffen Maier]

 as a result of viruses.

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities.



--
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/

Re: defining zfcp devices on SLES11

[Steffen Maier]

On 12/09/2013 07:57 PM, Karl Kingston wrote:

We have an XIV connected to 2 switches which in turn is connected to our
z10 through 4 adapters.

We have defined 5 luns for use under SLES11SP2.

Right now, we are using YaST to define all of the connections.   This
seems to be cumbersome.

Is there a way for us to to scan and define each lun without having to do
this manually?


If your FCP devices are NPIV-enabled and you use strict zoning 
(single-intiator zoning in the best case) with strict LUN masking, you 
can make use of zfcp auto LUN scanning:

http://www.mail-archive.com/linux-390@vm.marist.edu/msg64017.html
(NPIV is a hard requirement for auto LUN scan, the other requirements 
are best practice because otherwise you would attach everything visible 
in your fabric which might cause competition for the same LUNs in 
different Linux images which is dangerous because of potential data 
corruption (unless one uses a cluster file system intentionally).)


In all cases you can use lsluns from s390-tools to discover LUNs 
available on your storage target(s) and use SLES' command line tools 
(zfcp_host_configure and) zfcp_disk_configure (also s390-tools) to 
configure the LUNs both dynamically and persistently. The two latter 
tools are actually the backend of yast zfcp and can be used directly 
on the command line.
I've heard users crafting their own scripting around lsluns and 
zfcp_*_configure, but I would only recommend to do so with perfect 
zoning and LUN masking (especially if not using NPIV).


--
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/

Re: Any idea how to get into RedHat PDB mode on a kickstart through a TN3270 console in z/VM?

[Steffen Maier]

: Any idea how to get into RedHat PDB mode on a
kickstart through a TN3270 console in z/VM?
Sent by:Linux on 390 Port LINUX-390@VM.MARIST.EDU



I'm actually using both of those (RUNKS=1 and cmdline) already. And
I think we know where in the code there's a problem--the clearpart
--initlabel --all/zerombr is not getting run against all disks, just
disks mentioned later in the kickstart. In 6.2, we could use it to


You do have all disks including the extra disks, activated (set 
online) at the beginning of the installation?

Either in phase 1 interactively or per DASD=... boot parameter.
Just trying to rule out that they are not visible to anaconda during the 
wipeout step.



wipe out the header info from every disk the linux OS could see, but
in RHEL 6.4, it misses what I call extra disks--minidisks we use to
have a single kickstart file for multiple-sized linux servers that
still have the same base requirements. We build out a default of two
minidisks in volume group datavg for every server, but since that
only adds up to 20G, we wanted to be able to have a random number of
additional disks that'd get added into the datavg in a kickstart
%post script for servers whose application code will need more than
20G. Works great on a brand-new carved-straight-from-z/VM server, but
when we're rebuilding a server that's already been built once, since
the extra disks aren't wiped clean, linux senses that datavg
already exists when the kickstart tries to create it. Under RHEL 6.2,
since everything was wiped, a rebuild was just as easy as a new
build. We can get around it by recreating (deleting and re-adding)
the extra minidisks, or by running a %pre dasdfmt against any extra
disk sensed (which, since it single-threads how I coded it, can take
way longer than the z/VM minidisk recreate), but that won't help
RedHat figure out the bug in their code.


Wiping sufficiently many MB at the beginning and end of each partition 
(or disk, if you have clearpart anyway) might be a feasible workaround.

Dasdfmt should not be necessary here.

Unfortunately, I'm not very familiar with the pre-conditions and 
implications of things performed in the %post section.
Would dynamically creating the kickstart file be an option, in order to 
get away without the %post section and adding as many PVs as necessary 
with the volgroup native kickstart command?


Also I haven't tracked anaconda development since RHEL6.0, so I cannot 
tell what could have made the difference between 6.2 and 6.4.



That's just a little background, but I figured it might shed some
light on what we're doing. I've tried the enter/enter thing
mentioned below and in the RHEL note, but it doesn't seem to take,
which makes me wonder if the real problem isn't that the connection
to the linux bootstrap-OS is gone when it spits out the error. I seem
to get a prompt that expects only a certain handful of responses, but
I haven't figured out how to enter them either:

 Storage Activation Failed
 An error was encountered while activating your storage configuration.
 vgcreate failed for datavg: 15:46:23,603 ERROR   :   A volume
group called datavg already exists.
 ('custom', ['_File Bug', '_Exit installer'])

If I enter custom or _File Bug or _Exit installer, nothing happens.
Really, when the error pops up, I don't seem to have any recourse
from the z/VM guest console except logging off or entering #CP I
CMS to restart the process...


I see. You cannot enter anything when using cmdline. It is really 
entirely non-interactive. What you see is output that only makes sense 
in a TUI install where it would present dialog boxes.


What I forgot to mention previously: In order to debug this (with pdb) 
you need to use a GUI install (on System z, at least), i.e. please IPL 
without RUNKS=1 and without cmdline. You can still use kickstart. For 
the GUI selection, I recommend VNC over X11.

Only then the pdb lurks in the ssh session of the install user.
It becomes active on python exception tracebacks and there might also be 
other ways of explicitly trapping into pdb on user request:

https://fedoraproject.org/wiki/Anaconda_Boot_Options?rd=Anaconda/Options#debug
e.g. boot/anaconda option: debug=1 and probably loglevel=debug.
(http://fedoraproject.org/wiki/Anaconda/Stage2DevelopmentGuide#Debugging)


FYI--I've attached the below email to the redhat ticket. I'm hoping
some of the stuff I didn't understand in here might spark ideas in the
RedHat support staff. Thanks to both you (Steffen) and David, as well as
Rick Troth (who sent a straight-up) email for your responses so far. And
if you think of anything else, please let me know!
 Shannon


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Steffen 
Maier
Sent: Tuesday, July 16, 2013 1:23 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Any idea how to get into RedHat PDB mode on a kickstart through 
a TN3270 console in z/VM?

On 07/16/2013 05:25 PM

Re: Any idea how to get into RedHat PDB mode on a kickstart through a TN3270 console in z/VM?

[Steffen Maier]

On 07/16/2013 05:25 PM, David Boyes wrote:



We're trying to research an issue with our kickstarting that cropped up in
RHEL6.4 (worked perfectly in RHEL6.2).  RedHat support has asked us to
wait till the kickstart fails then issue CNTL+ALT+F1 to get into pdb mode
so they can debug the anaconda stuff, but since we boot in z/VM, the
terminal doesn't appear to translate those keys correctly--at least, I issue
them and nothing happens.


Call RH back and insist on talking to someone who can understand
This is not an Intel system. Those keys don't exist on System z.


Does anyone know how to send those to the
host operating system through a tn3270e console?  Or know of a different
way that we could get an ascii-based terminal for the automated kickstart if
needed?  When I ssh into the guest at the failure time, I can hop on as root
but I'm not breaking into the install process--I can't enter anything that'd
change the flow of the install.

Really hoping someone on this forum might have an idea, since IBM won't
respond (not a zVM issue, apparently, that their console doesn't work) and
RedHat doesn't seem to know...


The only way you could get an ASCII console that early in the process
would be from the HMC, and it's still not going to help you.

Try adding the cmdline option to the kickstart parm line. That will
take you through the install line by line, which should help you
findthe problem.

If this is 6.4, there are known bugs in kickstart. Have them search
for kickstart RHEL6.4 in their issue tracker.


cmdline will only allow you to roughly determine the point in the 
installation process but might make debugging the anaconda python code 
(pdb is the integrated Python DeBugger) harder or even impossible.
Also, you typically need RUNKS=1 along with cmdline (which is mutually 
exclusive with interactive TUI or GUI installation).

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-parmfiles-Kickstart_parameters.html

Since System z does not have the typical multiple x86 VGA Linux virtual 
terminals (VT), some features are packed into the ssh session or the 
Linux console and other features (such as the installer text logs) 
cannot be viewed directly (but indirectly through ssh as root and 
looking at the files in /tmp).


IIRC, the PDB for anaconda pops up in the ssh session you made as user 
install when moving from install phase 1 (linuxrc) to 2 (loader). 
That's basically the stdin/stdout on System z (as opposed to VT 1) for 
the anaconda process and thus the python interpreter with integrated pdb.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-s390-Phase_1.html 
[end of section]

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-Installation_Phase_2-s390.html
https://git.fedorahosted.org/cgit/anaconda.git/commit/?h=rhel6-branchid=5df5401f9d35a2da441a92372b7c3e36c2ebd386

There should also be some tools in pykickstart to (syntax) check your 
kickstart file, in case you suspect something wrong in the unattended 
installation answer file. This won't help if you suspect an anaconda 
code bug.


For the sake of completeness even though it might not help with the 
issue at hand:
During the RHEL installation, the Linux console sits there waiting for a 
linefeed to be entered. On doing so, it'll spawn a root shell (which, in 
contrast to ssh login(s) as root, even works if the network to the guest 
OS is down). The (default) Linux console is the 3270 terminal under z/VM 
or the HMC operating system messages panel on the HMC for LPAR.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-s390-Phase_1.html#ch-s390-Phase_1-terminals

--
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/

Re: RHEL6 and san luns

[Steffen Maier]

Hello Ann,

this should cover zfcp-attached SCSI device configuration for RHEL6:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_FCP-Attached_LUNs-Persistently.html

See also 
http://www.mail-archive.com/linux-390@vm.marist.edu/msg63917.html for 
some specifics of RHEL6.


Above-mentioned has precedence over the following complementary 
documentation which you can consult to get more background details on zfcp:

http://www.ibm.com/developerworks/linux/linux390/documentation_red_hat.html
* Device Drivers, Features, and Commands on Red Hat Enterprise Linux
* How to use FC-attached SCSI devices with Linux on System z

Please let us know if something's missing.

On 07/02/2013 09:11 PM, Smith, Ann (CTO Service Delivery) wrote:

I've gotten familiar with SLES and san configuration but looks like
now I may need doc on RedHat and san configuration. Anyone know the
best docs out there? Any known gotcha's?

Ann Smith


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: NPIV on sles11 SP2

[Steffen Maier]

On 06/18/2013 06:44 AM, Avinoam hirschberg wrote:

we try to use NPIV (dynamically) with no success, we can do Manuel with
command line and Yast/Yast2


Could you please elaborate in more detail what your expectations are, 
what you tried, and what (error) messages you got?


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: NPIV on sles11 SP2

[Steffen Maier]

On 06/18/2013 01:28 PM, Avinoam hirschberg wrote:

we try to do as follows and the system did recognize/see any LUNs

from this doc -
http://public.dhe.ibm.com/software/dw/linux390/docu/lk38ts07a.pdf

FCP setups running in NPIV mode detect the LUNs automatically and after
setting

the device online no further configuration is necessary.
* NPIV example *

1. To set FCP device 0.0.5400 online, issue the following command:
# chccwdev --online 0.0.5400
Setting device 0.0.5400 online
Done

The *chccwdev *command is part of s390-tools. For a description of the
command see *Device Drivers, Features, and Commands*, SC33-8411

After setting the FCP device online, all LUNs with valid host-connections
for the
WWPN of the NPIV FCP device are automatically visible as SCSI devices:

# lsscsi
[0:0:0:1073758410]disk IBM 2107900 0.33 /dev/sda
[0:0:0:1073823946]disk IBM 2107900 0.33 /dev/sdb

2. To find out if the FCP setup is running in NPIV mode, check the port_type
attribute of the FCP device, for example:

# cat /sys/bus/ccw/drivers/zfcp/0.0.5400/host0/fc_host/host0/port_type
NPIV VPORT


The scsi howto you refer to describes upstream kernel version 2.6.38.
This book version is closest to SLES11 SP2, but we don't have an 
explicit SLES spin of the book.
In addition to the scsi howto, we have our device drivers book as 
reference and for those we have a version specifically for each distro 
release. Please see:

http://www.ibm.com/developerworks/linux/linux390/documentation_suse.html#sles11sp2

Assuming you don't get scsi devices by means of auto lun scan with zfcp 
despite the use of NPIV-enabled FCP devices, you probably need to use

the following zfcp module parameter: zfcp.allow_lun_scan=1.
In contrast to upstream kernels, it had to remain disabled by default in 
SLES11 in order not to introduce semantic changes between service packs.
The simplest place to put the parameter is as additional kernel boot 
parameter in /etc/zipl.conf. For more details about such parameters 
please see Chapter 3. Kernel and module parameters.


Reference:
Device Drivers, Features, and Commands on SUSE Linux Enterprise Server 
11 SP2

Service Pack 2 changes
You can now enable automatic scanning for SCSI devices that are 
available through an NPIV port. See “Configuring SCSI devices” on page 
70 and the information about the allow_lun_scan= module parameter in 
“zfcp module parameters” on page 59.


For presistent configuration across reboots, you would only use 
zfcp_host_configure which will set the FCP device(s) online for you.

Just drop the part that does the unit_add for the non-NPIV cases,
i.e. do not use zfcp_disk_configure. Yast probably also does not yet 
support the NPIV auto lun scan case because it always wants to configure 
individual LUNs (ending up calling zfcp_disk_configure).


HTH
Steffen Maier

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Missing lv

[Steffen Maier]

On 05/23/2013 07:09 PM, Mark Post wrote:

On 5/23/2013 at 08:22 AM, Steffen Maier ma...@linux.vnet.ibm.com wrote:

I think anaconda should not add swap or any other non-root-fs LVs to the dracut 
cmdline.


Isn't that done so suspend/resume works?  I know that's why we do it in SLES.


Good point, Mark. That makes sense, I haven't thought about that.


Steffen Maier

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Error while IPLing Cloned Server - RHEL 6.3 on System Z

[Steffen Maier]

Of course, as already suggested, adapting the virtual device numbers in the 
hypervisor is the primary and easiest choice, if possible.



For cases where this is not an option or not even possible (e.g. WWPN and LUN 
with FCP), I strongly recommend to follow the RHEL 6 documentation.

For any resources (transitively, i.e. through and including any LVM or 
multipathing) required to bring up and mount the root fs,
dracut needs to be instructed on the kernel command line to activate the base 
physical devices
(in contrast to other distro releases, that information is usually (unless you 
build a host-only initramfs) not inside the initramfs which makes zipl or even 
other dynamic ways of passing kernel boot options at IPL suffice):
* DASD
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info.html#ap-s390info-Adding_DASDs-Persistently_setting_online-Part_of_root_file_system
* ZFCP
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_FCP-Attached_LUNs-Persistently.html#ap-s390info-Adding_FCP-Attached_LUNs-Persistently-Part_of_root_file_system
* And for the probably uncommon case of a network root-fs
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_a_Network_Device.html#ap-s390info-Adding_a_Network_Device-qeth_Device-Persistently
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_a_Network_Device-Configuring_network_device_for_Network_Root_File_System.html#ap-s390info-Adding_a_Network_Device-Configuring_network_device_for_Network_Root_File_System

So in the original posting of this thread, I suppose the rd_DASD entries in 
/etc/zipl.conf would have to be adjusted and /etc/fstab because RHEL6 uses 
by-path for DASDs (in order to enable devno virtualization in the hypervisor as 
mentioned at the top of this mail) plus a zipl run.

Above is a significant difference to the persistent activation configuration of 
any other (data) volume, i.e. volumes that are *no* dependencies for the root 
fs. They only use /etc/dasd.conf, /etc/zfcp.conf, or 
/etc/sysconfig/network-scripts/ifcfg-... respectively. No recreation of 
initramfs nor zipl run.



Since RHEL 6.0 there is transparent support for cio_ignore, if you use the 
documented ways of persistently configuring devices (both for the root fs as 
well as any other).

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info.html#ap-s390info-Adding_DASDs-Persistently_setting_online
 cio_ignore is handled transparently for persistent device
 configurations and you do not need to free devices from the ignore
 list manually.
 There is no need to recreate the initramfs.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_FCP-Attached_LUNs-Persistently.html#ap-s390info-Adding_FCP-Attached_LUNs-Persistently
 cio_ignore is handled transparently for persistent device
 configurations and you do not need to free devices from the ignore
 list manually.
 There is no more need to recreate the initramfs. 

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_a_Network_Device.html#ap-s390info-Adding_a_Network_Device-qeth_Device-Persistently
 cio_ignore is handled transparently for persistent device
 configurations and you do not need to free devices from the ignore
 list manually.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_a_Network_Device-Configuring_network_device_for_Network_Root_File_System.html#ap-s390info-Adding_a_Network_Device-Configuring_network_device_for_Network_Root_File_System
 There is no need to recreate the initramfs. cio_ignore for the
 network channels is handled transparently on boot.

For strictly maintained I/O configurations in the hypervisor (whether in z/VM 
or PR/SM), you may remove the cio_ignore option from the kernel command line, 
but it's not necessary.



HTH
Steffen Maier

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

On 05/21/2013 07:11 PM, Mauro Souza wrote:
 I usually get rid of cio_ignore every time I install a Linux guest
 (but sometimes I forget to). I think this parameter is usable only
 when you install Linux on a partition, and this partition can see
 every device on the mainframe. On a Linux guest, the only devices
 Linux can see is the devices we gave to it, so cio_ignore does
 nothing we haven't already done. But it can lead to a lot of
 confusion and scratched heads when we change a device.
 
 Mauro http

Re: Missing lv

[Steffen Maier]

On 05/16/2013 07:55 PM, Neale Ferguson wrote:

That was it Steffen. I did a find / grep looking for vg_swap so I thought
it'd pick up the zipl.conf but I must have messed up the command. In any
event, I got rid of it and re-ran zipl.

Note, that rd_LVM wasn't put in manually by me but as part of the
installation.


Right, I vaguely remember having seen this, too, but haven't given much 
thought about it so far.
I think anaconda should not add swap or any other non-root-fs LVs to the 
dracut cmdline.
Searching for dependencies of only the root-fs with features such as lvm 
or multipathing is non-trivial so this might be an anaconda bug.



On 5/16/13 1:39 PM, Steffen Maier ma...@linux.vnet.ibm.com wrote:

Do you happen to have this in your kernel command line?:
rd_LVM_LV=vg_rh62gfs/lv_swap


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Missing lv

[Steffen Maier]

Hi Neale,

On 05/16/2013 04:59 PM, Neale Ferguson wrote:

I used system-config-lvm to remove a lv “vg_rh62gfs/vg_swap”. It appeared to go 
ok and after zipling I rebooted only to get:

dracut: Scanning devices dasda1 dasdb1 dasdc1  for LVM logical volumes 
vg_rh62gfs/lv_root vg_rh62gfs/lv_swap
dracut: Skipping clustered volume group vg_snatest
dracut: Skipping volume group vg_snatest
dracut: inactive '/dev/vg_rh62gfs/lv_boot' [500.00 MiB] inherit
dracut: inactive '/dev/vg_rh62gfs/lv_root' [2.12 GiB] inherit
dracut: inactive '/dev/vg_rh62gfs/opt' [488.00 MiB] inherit
dracut: One or more specified logical volume(s) not found.
dracut: Scanning devices dasda1 dasdb1 dasdc1  for LVM logical volumes 
vg_rh62gfs/lv_root vg_rh62gfs/lv_swap

I mounted the volumes on another system and did a scan to find where
vg_swap was still specified. I couldn’t find any reference so I’m not
sure why dracut wants to find it.


Do you happen to have this in your kernel command line?:
rd_LVM_LV=vg_rh62gfs/lv_swap

One should only ever have dependencies for the root-fs on the dracut 
command line [1,2]. Swap does not belong to the root-fs dependencies; 
swap is only activated later on during the sysVinit process after the 
root-fs was already mounted by the initramfs.
Also, it might make dracut insist on finding and activating this 
particular LV and thus breaks when it's gone.


[1] https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_lvm
[2] 
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info.html#ap-s390info-Adding_DASDs-Persistently_setting_online-Part_of_root_file_system


HTH
Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: zfcp_hbaapi on RedHat 5.8

[Steffen Maier]

On 12/12/2012 12:44 PM, Fernando Gieseler wrote:

Has anyone used/installed zfcp_hbaapi kernel module on RedHat 5.8?

I need this .ko file to run san_disc tool to discovery LUN's on my System.


AFAIK, there is no zfcp hba api for RHEL5.
However, you may use lsluns from the s390utils package to perform LUN 
discovery.


For the sake of completeness (regarding san_disc functionality [1]): I 
don't know of any tool to perform remote (target) port discovery with 
RHEL5, so you have to perform manual port_add's and know WWPNs beforehand.
RHEL6 and SLES11 (=SP1) have auto port scanning in zfcp, so there is no 
need to have any user space tool for that

(and both have zfcp hba api (without an additional kernel module)
as well as lsluns).

BTW, zfcp_san_disc is a SLES specific wrapper script.

Steffen Maier

[1] http://www.ibm.com/developerworks/linux/linux390/zfcp-hbaapi.html

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Fedora17 - S390X on Hercules/390

[Steffen Maier]

On 11/27/2012 03:13 AM, John McKown wrote:

I downloaded the DVD ISO to my Linux/Intel Fedora 17 - x86_64 system. I
tried to IPL the ISO using Hercules/390. I did a loop-back mount of the
ISO to a directory, then did the Hercules/390 command:

ipl /path/to/dev/generic.ins

I got a lot of messages to the hercules console. The last ones that look
good are:


82.265996! dracut: rd.dm=0: removing DM RAID activation
82.403817! dracut: rd.md=0: removing MD RAID activation

Followed by the following messages, in a loop until I quit hercules

loop type=unending
dracut Warning: Unable to process initqueue
dracut Warning: /dev/root does not exist


What's in your parm file (or used kernel boot parameters in general)?
Does this help assuming you haven't seen any other errors before the 
failing root-fs mount?:

https://fedoraproject.org/wiki/Architectures/s390x/17#Release_Notes
The specification of the initramfs representing the installer's root-fs 
has changed significantly and most of linuxrc.s390 is gone so mostly 
only dracut is left for init like bringup of anaconda.

See also
http://lists.fedoraproject.org/pipermail/fedora-s390x/2012-June/000192.html
http://lists.fedoraproject.org/pipermail/fedora-s390x/2012-October/000384.html

Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Any Official HMC Screenshots?

[Steffen Maier]

Hi Mark,

On 11/07/2012 11:52 PM, Mark Post wrote:

Cross-posted to Linux-390, IBMVM and IBM-MAIN.

I'm developing some documentation which deals with Linux installation
into an LPAR.  I would like to include images/screenshots of the
various HMC screens involved so that the end-user can better relate
the text to what they're going to see on a real HMC.  Does any of the
official IBM manuals have any images like that included?  I know some
of the Redbooks do, but I would prefer something other than those if
possible.


I don't know about copying content from our books
but would the following be what you're looking for?:

http://www.ibm.com/developerworks/linux/linux390/documentation_dev.html
Book Device Drivers, Features, and Commands

* for operating system messages console:
Chapter Console device drivers

* for LPAR image load of the installer:
Chapter Booting Linux
Section Booting Linux in LPAR mode
Subsection Loading Linux from removable media or from an FTP server

The distro specific stuff should be in distro documentation, i.e. what 
the content of the operating system messages console looks like per 
distro installer.


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: lvcreate succeeds but no /dev/mapper device

[Steffen Maier]

Hi Mike,

On 10/19/2012 01:31 PM, Michael MacIsaac wrote:

udevadm settle is not always reliable and the last response was
that you have to sit and poll until the device actually appears


This one is worse - the LV  *never* appears in either directory until
after reboot and lvdisplay oradata_lv  hangs the system. On the console
while lvdisplay is hung, I see these messages:

INFO: task lvdisplay:5188 blocked for more than 120 seconds.
echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this message.
lvdisplay D 004cd070 0  5188   5119 0x0200
7bd5e078 004d6a00 00132c0a 7b80b850
7b80b820 0080ee80 008a7e00 7bd5e4d8
0001 7bd5e4d8 7bd17800 0080ee80
008a7e00 7bd5e4d8 7ee98040 03379e00
004d6d18 004cc5b8 7b80b850 7b80ba08
Call Trace:
(Ý004cc5b8¨ schedule+0x5a4/0xfe0)
  Ý004cd070¨ io_schedule+0x7c/0xd4
  Ý002939b8¨ __blockdev_direct_IO_newtrunc+0x7a0/0xdfc
  Ý0029408c¨ __blockdev_direct_IO+0x78/0xf0
  Ý002916ea¨ blkdev_direct_IO+0x72/0x80
  Ý001f34f0¨ generic_file_aio_read+0x75c/0x7b0
  Ý00254fc8¨ do_sync_read+0xf0/0x154
  Ý00255fa0¨ vfs_read+0xa0/0x1a0
  Ý002561a2¨ SyS_read+0x5a/0xac
  Ý0011863c¨ sysc_tracego+0xe/0x14
  Ý0045c5f756fc¨ 0x45c5f756fc
...

After the reboot, lvdisplay works fine. I plan to open a bug report.


Do you have your PVs on device-mapper multipath devices?
[filter in /etc/lvm.conf]
Do you have at least one available path per pathgroup for all PVs in VG?
Otherwise your lvcreate request might still be stuck in the dm-mp device 
queue [queue_if_no_path in /etc/multipath.conf] (which would also 
explain why udevadm settle has no effect since udev events are not yet 
emitted)
and lvdisplay obviously blocks very long on I/O because it cannot 
service the I/O request if all paths are gone at the same time (or path 
failover did not work).


--
Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Moving Root DASD

[Steffen Maier]

On 10/11/2012 11:20 PM, Scott Rohling wrote:

The easiest thing to do is bring the guest down and  LINK these 2 disks
from another running Linux ..  mount them as /mnt /mnt/disk1 and 2 and copy
- I would use rsync:

rsync -av /mnt/disk1/  /mnt/disk2


In case you follow down this path, don't forget to rewrite the 
bootloader since the boot files are now at different places on the disk 
after having copied the content file by file:

chroot /mnt/disk2
zipl -V
exit


Unmount, detach - and swap the disks in the directory so the big disk is
the same address as the old small one.


In case you don't want to / cannot rename the DASD devno, you can adjust 
it in above workflow between the chroot and the zipl call with:

vi /etc/fstab
vi /etc/zipl.conf
# use the distro mechanism to configure root devno such that it'll
# set it (or them in case of multi-PV LVM rootfs) online during boot
mkinitrd # not necessary with RHEL6

With zfcp attached scsi disks this is usually mandatory since one can 
hardly influence target WWPN and LUN to be the same after moving to 
another disk (or even a disk in another storage system).



If you don't have another running Linux you can do something similar by
booting the install kernel from the reader and getting into the recovery
shell..   I don't think the rsync command is there, so you'd have to use
the 'cp' command or a tar pipe.

Scott Rohling


On Thu, Oct 11, 2012 at 12:41 PM, Ben Duncan b...@linux4ms.net wrote:


Hi group. Need to some help in transferring and recreating the ROOT ( /
) dasd device to another dasd
Specifically we want to migrate from a 300MB partition and replace it
with a 2Gb partition which is
already formatted and prepped.


Any pointer or how to's on this ?


Steffen Maier

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: SCSI/FCP disk size

[Steffen Maier]

On 10/10/2012 02:00 AM, Thang Pham wrote:

That works, thanks.

From:   Raymond Higgs/Poughkeepsie/IBM@IBMUS
Date:   10/09/2012 07:56 PM

It is in /var/log/messages:

Oct  9 19:43:21 4e1d-laplace-48 kernel: [23044.656933] scsi 1:0:26:1082146832: 
Direct-Access IBM  2107900  36.5 PQ: 0 ANSI: 5
Oct  9 19:43:21 4e1d-laplace-48 kernel: [23044.657047] sd 1:0:26:1082146832: 
Attached scsi generic sg21 type 0
Oct  9 19:43:21 4e1d-laplace-48 kernel: [23044.659692] sd 1:0:26:1082146832: 
[sdv] 4194304 512-byte logical blocks: (2.14 GB/2.00 GiB)
Oct  9 19:43:21 4e1d-laplace-48 kernel: [23044.660473] sd 1:0:26:1082146832: 
[sdv] Write Protect is off
Oct  9 19:43:21 4e1d-laplace-48 kernel: [23044.660839] sd 1:0:26:1082146832: 
[sdv] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct  9 19:43:21 4e1d-laplace-48 kernel: [23044.663606]  sdv: unknown partition 
table
Oct  9 19:43:21 4e1d-laplace-48 kernel: [23044.665817] sd 1:0:26:1082146832: 
[sdv] Attached SCSI disk

Or send the SCSI read capacity command like this:

root@4e1d-laplace-48.1:sg_readcap /dev/sdv
Read Capacity results:
Last logical block address=4194303 (0x3f), Number of blocks=4194304
Logical block length=512 bytes
Hence:
Device size: 2147483648 bytes, 2048.0 MiB, 2.15 GB



Linux on 390 Port LINUX-390@vm.marist.edu wrote on 10/09/2012 07:32:19 PM:


From: Thang Pham/Poughkeepsie/IBM@IBMUS
Date: 10/09/2012 07:40 PM



Is there a way to find out the size of a native SCSI device attached via
FCP channel?  I do not see lszfcp or lsscsi having an option that lets you
see the size of the disk you have attached to a VM.


The size of a scsi (disk) device is the same as the block device size. 
This is not specific to Linux on System z nor zfcp nor SCSI. It's just 
common block subsystem code.


Depending on what kind of code you want to process this information with;
for scripting you could use /sys/block/devicename/size (and adhere to 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/sysfs-rules.txt;hb=HEAD) 
(or parse the somewhat older /proc/partitions);
for C code you could just use the ioctl BLKGETSIZE64 from 
include/linux/fs.h [see e.g. the source of 'blockdev --getsz dev' as 
an example].
All other suggestions so far basically boil down to this in the end, so 
I'd probably prefer to use the user space interface directly.


This requires that you had attached the LUN to Linux previously and that 
would include lun probing in the kernel which already did inquiry and 
readcapacity (if the device is a disk, e.g.) among other things so 
there's no need to resend those scsi commands again explicitly.


I'm not quite sure what you mean in your second sentence with regard to 
a disk attached to a VM.
To a VM as a z/VM userid, i.e. attached to the virtual machine by the 
hypervisor? AFAIK this means EDEV under z/VM. I don't know of any other 
way of attaching a scsi disk to a VM (usually users only attach the FCP 
host bus adapter to a VM).

To a VM as in guest operating system? Then the previous paragraphs apply.
Or would you like to get the lun size without even attaching them to 
Linux or the VM? If so, then this depends on the storage type since 
you'd have to use out of band mechanisms (i.e. non-scsi) to query the 
storage target server.


Steffen Maier

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: VLAN Packet reverb.

[Steffen Maier]

:0 overruns:0 frame:0
   TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:984 (984.0 b)

eth1.4Link encap:Ethernet  HWaddr 02:00:C2:00:00:1B
   inet6 addr: fe80::c2ff:fe00:1b/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:492 (492.0 b)

loLink encap:Local Loopback
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


 From a tcpdum -i eth1. This shows traffic between two other nodes, but 18 
copies of it:
12:19:12.089413 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089444 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089449 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089455 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089460 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089465 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089470 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089475 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089480 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089485 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089490 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089495 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089500 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089505 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089510 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089515 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089520 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64
12:19:12.089525 IP 10.55.255.1  10.55.255.2: ICMP echo request, id 3334, seq 
1, length 64


--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: persistent zfcp ports/luns

[Steffen Maier]

On 03/01/2012 09:50 AM, Offer Baruch wrote:

I am using the /etc/sysconfig/mkinitrd/modules file to specify the zfcp
module... But i did not run zipl as i only replaced the initrd. I thought
that zipl should only run if you change zipl.conf. I tried to run zipl and
the old luns are gone...


You were lucky you could even reboot with having the initrd updated but 
not run zipl. Actually zipl still booted the old initrd whose sectors 
were still on disk but already freed by the filesystem on generating the 
new initrd (the latter created a new initrd file and did an unlink on 
the old initrd). During time or on disk space pressure, old freed 
sectors will be overwritten and your old initrd content will be 
destroyed. Once that has happened you could no longer boot.



Please can you explain what zipl does with the initrd file?


I'm certainly no zipl expert and my colleagues will hopefully correct 
me. Generally, for anything that is needed to boot -- and this include 
kernel, parm file, and initrd -- the actual current disk sectors where 
the file content can be found is figured out by zipl and written in a 
so-called bootmap. On IPL, zipl uses this boot map to find the file 
content because it does not understand the Linux file systems.



On intel grub only points to the initrd file. Why is there any difference?


Grub (on any platform it is ported to) does understand Linux filesystems 
and therefore does not need an updated bootmap each time the content or 
sector layout of file needed to boot changed on disk.

In that respect, zipl is more like lilo rather than grub.

Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: persistent zfcp ports/luns

[Steffen Maier]

On 02/29/2012 07:07 AM, Offer Baruch wrote:

I have a strange zfcp problem i just can't figure out...
My OS runs on ECKD but i have a few luns on an XIV machine for oracle data.
We are in the middle of a migration process from one XIV to another.
my /etc/zfcp.conf used to look like this (before the migration):
#
0.0.0010 0x0 0x5001738000800140 0x0 0x
0.0.0010 0x0 0x5001738000800150 0x0 0x
0.0.0010 0x0 0x5001738000800160 0x0 0x
0.0.0011 0x0 0x5001738000800171 0x0 0x
0.0.0011 0x0 0x5001738000800181 0x0 0x
0.0.0011 0x0 0x5001738000800191 0x0 0x



and now it looks like this (different WWPNs and i got rid of lun zero):
#
0.0.0011 0x0 0x5001738062670140 0x0 0x0001
0.0.0011 0x0 0x5001738062670150 0x0 0x0001
0.0.0011 0x0 0x5001738062670160 0x0 0x0001
0.0.0010 0x0 0x5001738062670170 0x0 0x0001
0.0.0010 0x0 0x5001738062670180 0x0 0x0001
0.0.0010 0x0 0x5001738062670190 0x0 0x0001



I expected that after a reboot zfcp will forget about the old luns but he
didn't.
looking at:
/sys/bus/ccw/drivers/zfcp/0.0.0010
/sys/bus/ccw/drivers/zfcp/0.0.0011
i can still see the old ports and luns. for example:
drwxr-xr-x 6 root root0 Feb 28 15:17 0x5001738000800140 - old
drwxr-xr-x 6 root root0 Feb 28 15:17 0x5001738000800150 - old
drwxr-xr-x 6 root root0 Feb 28 15:17 0x5001738000800160 - old
drwxr-xr-x 5 root root0 Feb 28 15:17 0x5001738062670170 -new
drwxr-xr-x 5 root root0 Feb 28 15:17 0x5001738062670180 -new
drwxr-xr-x 5 root root0 Feb 28 15:17 0x5001738062670190 -new
under 0x5001738000800140 you can see the old luns:
drwxr-xr-x 2 root root0 Feb 28 15:17 0x
drwxr-xr-x 2 root root0 Feb 28 15:17 0x0001
drwxr-xr-x 2 root root0 Feb 28 15:17 0x0002
drwxr-xr-x 2 root root0 Feb 28 15:17 0x0003

something does not add up. i guess i have some misunderstanding about zfcp
start up procedure.
I though the script zfcpconf.sh is run at startup using the
56-zfcp.rules* *udev
rule and that is it...
as all 56-zfcp.rules* *does is run zfcpconf.sh i can't figure out where did
the system get the old luns/ports?


I suppose this is RHEL 5: You may need to regenerate your initrd after 
modifications to /etc/zfcp.conf since this gets added to the initrd, 
IIRC. On reboot, your old initrd containing the old zfcp.conf still 
activates the old WWPNs and LUNs before the root-fs gets mounted.


(All this differs for RHEL 5, RHEL 6, SLES 10, SLES 11.)


zfcpconf.sh just reads /etc/zfcp.conf


That adds the new WWPNs and LUNs after the root-fs was mounted.

HTH
Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: NFS install stall

[Steffen Maier]

On 02/21/2012 05:29 PM, Cameron Seay wrote:

And my saga continues still:

Got the NFS volume configured and moved the RHEL 5.7 files to it.  I am
stalled on these last two messages from VM about the install

15:35:26 INFO: NFS install method detected, will use RHupdates/
15:35:26 INFO: Running anaconda script /usr/bin/anaconda

On the Linux shell for the installation I see:

login as: root
Welcome to the anaconda install environment 1.2 for zSeries

loader has already been run.  Starting shell.


What's in your parm and/or conf file?
Did you try to login on the console of the system, i.e. 3270 under z/VM 
or operating system messages in LPAR? That would only be useful for 
installer debugging. The installation itself gets kicked off by logging 
in over ssh, which starts the first (and only) instance of loader, but 
according to the message above you already did so before and loader 
already started anaconda. So you just don't seem to get access to the 
graphical (or alternatively text) install UI. This depends on parameters 
in your parm file and/or interactive user choices in the loader. Even 
though the following is from the RHEL6 docs it pretty much applies to 
RHEL5 and at the same time gives an overview of the matrix of choices:

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/Installation_Procedure_Overview-s390-GUI.html
FWIW, this is all independent of the type of install medium, i.e. http, 
ftp, nfs, local disk, or whatever.


HTH
Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: lsscsi issue with RHEL5

[Steffen Maier]

On 12/15/2011 11:47 PM, Shumate, Scott wrote:

  I have an issue with zfcp luns.  I 2 luns 1 100GB lun and 1 1GB lun.
The 100GB lun has 4 paths  /dev/sda, /dev/sdb, /dev/sdd, and /dev/sde.
The 1GB lun has one path /dev/sdc.  I want paths /dev/sda thru /dev/sdd
for the 100GB lun and /dev/sde for the 1GB lun.  Is there anything I can
do to make this happen?  I've manually removed the scsi disk and
rebooted, but it still has the same issue.  What am I doing wrong?


No issue here. /dev/sdX are kernel device names allocated by no 
particular rule a user can rely on. Therefore, udev provides persistent 
device names implemented by means of symbolic links under /dev. For 
storage, those can be found under /dev/disk/by-.../...
For those cases where I really need to refer to an individual path of a 
zfcp attached SCSI disk, I usually rely on 
/dev/disk/by-path/ccw-devbusid-zfcp-wwpn:lun.


http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html
and also the Section SCSI device nodes in the zfcp chapter in the 
Device Drivers, Features, and Commands book on 
http://www.ibm.com/developerworks/linux/linux390/documentation_red_hat.html#rhel5


Just curious: Having configured multiple paths I presume you use 
device-mapper multipathing on top which doesn't care about the device 
names of individual paths.

What do you need device names of underlying physical paths for?


[root@wil-zstsintgdbprdbu01 ~]# cat /etc/zfcp.conf
0.0.dc000x50060e800571f006  0x0020
0.0.dd000x50060e800571f016  0x0020
0.0.de000x50060e800571f007  0x0020
0.0.df000x50060e800571f017  0x0020


This only contains persistent configuration for four paths to your 
presumable 1GB LUN. However, where does the config for the one path to 
the 100GB LUN come from?



[root@wil-zstsintgdbprdbu01 ~]# lszfcp -D
0.0.dc00/0x50060e800571f006/0x0020 0:0:0:1
0.0.dc00/0x50060e800571f006/0x0026 0:0:0:2
0.0.dd00/0x50060e800571f016/0x0020 1:0:0:1
0.0.de00/0x50060e800571f007/0x0020 2:0:0:1
0.0.df00/0x50060e800571f017/0x0020 3:0:0:1

[root@wil-zstsintgdbprdbu01 ~]# lsscsi
[0:0:0:1]diskHITACHI  OPEN-V   6008  /dev/sda
[0:0:0:2]diskHITACHI  OPEN-V   6008  /dev/sdc
[1:0:0:1]diskHITACHI  OPEN-V   6008  /dev/sdd
[2:0:0:1]diskHITACHI  OPEN-V   6008  /dev/sde
[3:0:0:1]diskHITACHI  OPEN-V   6008  /dev/sdb


Looks perfectly good to me.

Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Install tape driver error on zlinux

[Steffen Maier]

On 10/18/2011 09:51 PM, Mark Post wrote:

On 10/18/2011 at 05:41 AM, Steffen Maierma...@linux.vnet.ibm.com  wrote:

Since you (had to) build the lin_tape device driver kernel module
yourself it is formally flagged as not supported by SLES11 and
therefore modprobe denies loading the module. This is indicated by above
message for which you can find more details in:

http://www.novell.com/support/viewContent.do?externalId=7002793sliceId=1
http://www.novell.com/linux/releasenotes/s390x/SUSE-SLES/11-SP1/#KernelModul
es

Unfortunately, I don't know how this case is handled with SLES regarding
distribution support for SCSI tape drives.
Hoping for Mark Post to step in here.


We do provide native support for SCSI tapes in the distribution.
I  don't know what lin_tape provides over and above that.


Assuming you refer to the st SCSI tape driver by native support,
then multipathing comes to mind as additional feature of lin_tape.

Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Cannot Ping SLES11 guests from z/VM through hypersockets

[Steffen Maier]

On 10/19/2011 01:56 AM, Peter E. Abresch Jr. - at Pepco wrote:

Maybe, net.ipv4.conf.all.rp_filter was set to 1. I took one of my
SLES11-SP1 guest and set it to 2. It now pings from z/VM. When I set it
back to 1, it still pings. When I set it to 0, it still pings. I went to a
different SLES11 guest. It did not ping, but once I set
net.ipv4.conf.all.rp_filter to 0, it pinged fine. I returned it to 1 and
it still pings. I am confused. Why is it pinging all of a sudden or is it
just the nature of the beast.


I suppose that once you had loosened the reverse path filtering, you got 
routing cache entries and then rp_filter no longer checks the FIB 
(forwarding information base == routing table(s)) as long as a 
corresponding cache entry is still there even if you have set rp_filter 
back to 1 for strict checking.


/sbin/ip route list table cache

The routing cache is volatile. You can cross check my assumption by 
flushing the routing cache after having set rp_filter back to 1 for 
strict filtering and checking whether ping fails to work again.


/sbin/ip route flush table cache


Should I set it to 2 globally?


Probably this depends on your network topology and security 
requirements. Do you have any asymmetric routing or multiple interfaces 
to the same subnet [1] in the same virtual machine and need such 
configuration?


[1] http://www.mail-archive.com/linux-390@vm.marist.edu/msg57175.html


From:   Michael O'Reillymik...@us.ibm.com
  Are you by any chance hitting:
Applying SLES 11 SP 1 Causing Communication Issues
http://www.novell.com/support/search.do?cmd=displayKCdocType=kcexternalId=7007649sliceId=1docTypeID=DT_TID_1_1



On 10/18/2011 at 06:42 PM, Peter E. Abresch Jr.   - at Pepco

peabre...@pepco.com  wrote:

We are running z/VM Version 5 Release 4.0, service level 1001 (64-bit). We
can ping all of our SLES10 guests through our real hypersockets from z/VM.
however we cannot ping our SLES11 guests from z/VM through our real
hypersockets. All our Linux guests (SLES10 and SLES11) can ping each other
fine through hypersockets. z/OS can ping SLES10 and SLES11 guests through
hypersockets fine. SLES10 and SLES11 Linux guest can ping everything fine
through hypersockets. The only problem is pinging SLES11 guests from z/VM.
Has anyone else experienced this problem or have any suggestions?


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Install tape driver error on zlinux

[Steffen Maier]

On 10/18/2011 09:14 AM, Lu GL Gao wrote:

Our linux is SUSE Enterprise Server 11 SP1 running on z/VM V5.4.



Our tape lib is TS3500, driver is 3592 E05.



(1) download tape driver from website of System Storage Interoperation
Center.



I downloaded 2 files. One is lin_tape-1.61.0-1.src.rpm, the other is
lin_taped-1.61.0-sles11.s390x.rpm.

(2) I'm sure that zfcp device driver is loaded into kernel, because we have
scsi disk connected through zfcp device driver.

(3) rpmbuild -rebuild lin_tape-1.61.0-1.src.rpm
This step produced lin_tape package
on /usr/src/packages/RPMS/s390x/lin_tape-1.61.0-1.s390x.rpm

(4) rpm -ivh /usr/src/packages/RPMS/s390x/lin_tape-1.61.0-1.s390x.rpm
This step produced below error:

Preparing...   ###
[100%]
   1:lin_tape   ###
[100%]
Starting lin_tape: FATAL: module
'/lib/modules/2.6.32.12-0.7-default/kernel/drivers/scsi/lin_tape.ko' is
unsupported
Use --allow-unsupported or set allow_unsupported_modules to 1 in
/etc/modprobe.d/unsupported-modules


Since you (had to) build the lin_tape device driver kernel module 
yourself it is formally flagged as not supported by SLES11 and 
therefore modprobe denies loading the module. This is indicated by above 
message for which you can find more details in:


http://www.novell.com/support/viewContent.do?externalId=7002793sliceId=1
http://www.novell.com/linux/releasenotes/s390x/SUSE-SLES/11-SP1/#KernelModules

Unfortunately, I don't know how this case is handled with SLES regarding 
distribution support for SCSI tape drives.

Hoping for Mark Post to step in here.

Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: FTP file timestamps

[Steffen Maier]

On 09/16/2011 08:48 PM, Frederick, Michael wrote:

There is a subcommand/setting in (SLES9/10/11) FTP called preserve,
which says whether or not the timestamp on the file when you transfer
it gets rewritten or not.  It is defaulted such that the timestamp on
a 'get' remains the same.

I have been asked if there is a way (other than issuing 'preserve
off') to set this via some '.ftp_profile' or configuration file.  I
know that I could download the FTP source, find the setting in there,
change it, and recompile the program, but I would think there'd be an
easier way.  Can anyone think of how you would do this?


I don't know anything about the particular preserve option. However,
the traditional ftp client reads ~/.netrc (man 5 netrc), where you can 
specify users and passwords to use with certain hosts, plus defining 
macros with macdef, where the special macro named init gets executed 
automatically on successful login to an ftp host. Maybe you can use this 
to set the preserve thingy. With the lftp client, there's additionally 
~/.lftprc and ~/.lftp/rc and the system-wide /etc/lftp.conf and there 
seem to be options like ftp:use-mdtm 
[http://tools.ietf.org/html/rfc3659#section-3].


On the server side, things most probably depend on the specific ftpd 
implementation. E.g. I found an mdtm_write option with vsftpd with which 
you can disable the use of the MDTM ftp command to set file modification 
times (on the server side).


Apparently, things depend on the direction of transfer and are not 
straight-forward according to http://www.rjh.org.uk/ftp-report.html.


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: zfcp disk error

[Steffen Maier]

On 09/16/2011 11:55 AM, Lu GL Gao wrote:

We have use 4 FCP type channel on Mainframe side. Every channel is enabled
NPIV with 64 sub-channels whose WWPN are available.
We use 4 hba-ports on DS8000 side.
We will add 20 LUN disks for zlinux system. Every disk has two paths to be
reached.(multipath was enabled)


Just curious: If you have 4 ports on the host side and 4 ports on the 
storage side, wouldn't you have at least 4 paths for each disk, or even 
16 if you make use of cross-over i.e. all combinations of 4*4 ports?



Howevery, in our system, I found some sub-channel can normally get WWPN of
hba-port, some can not get.
Strange thing is that these sub-channel is belong to same physical channel.


Is there a particular reason why you use more than one subchannel of the 
same FCP channel within the same virtual machine?
I would have expected to see four active FCP subchannels, each on a 
different channel, in your logs below. This would also mean less host 
WWPNs to allow on the storage side.



I find some error messages shown on zlinux guest console from z/VM side:
---
zfcp.e78dec: 0.0.3f24: A QDIO problem occurred
zfcp.e78dec: 0.0.3f1e: A QDIO problem occurred
zfcp.e78dec: 0.0.3f18: A QDIO problem occurred
zfcp.e78dec: 0.0.3f00: A QDIO problem occurred
zfcp.e78dec: 0.0.3f36: A QDIO problem occurred
zfcp.e78dec: 0.0.3f0c: A QDIO problem occurred
zfcp.e78dec: 0.0.3f2a: A QDIO problem occurred
zfcp.e78dec: 0.0.3f06: A QDIO problem occurred
zfcp.e78dec: 0.0.3f12: A QDIO problem occurred
zfcp.3dff9c: 0.0.3f24: Setting up the QDIO connection to the FCP adapter
failed


While talking to the FCP channel, the zfcp device driver got notified 
about errors from the communication mechanism QDIO.
See also the corresponding distro-specific kernel messages book on 
http://www.ibm.com/developerworks/linux/linux390/distribution_hints.html 
to decode zfcp.e78dec or zfcp.3dff9c.


The zfcp error recovery could not reestablish the connection,
so it went into full adapter (meaning FCP subchannel) recovery,
which apparently helped reestablishing the basic QDIO connection:


qdio: 0.0.3f24 ZFCP on SC 19 using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W AO
qdio: 0.0.3f1e ZFCP on SC 18 using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W AO
qdio: 0.0.3f06 ZFCP on SC 14 using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W AO
qdio: 0.0.3f18 ZFCP on SC 17 using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W AO
qdio: 0.0.3f12 ZFCP on SC 16 using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W AO
qdio: 0.0.3f0c ZFCP on SC 15 using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W AO
qdio: 0.0.3f00 ZFCP on SC 13 using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W AO
qdio: 0.0.3f2a ZFCP on SC 1a using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W AO
qdio: 0.0.3f36 ZFCP on SC 1c using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W AO


However, you might get QDIO errors again as soon as zfcp sends requests 
to the channel. That seems to be the case with your setup.



INIT: Id 4 respawning too fast: disabled for 5 minutes


Don't know if that's related or what it means without context.


Based on your guys experience, what caused this error, is it a hardware
error or system error?


You seem to have an issue between the zfcp device driver and the FCP 
channel, that's where QDIO is used to communicate. Inbetween there might 
be z/VM, in case you run under VM. If the latter, what's the z/VM version?

What version of FICON Express channels do you use?
Is this SLES11? SP1?
What's the output of lszfcp -Ha?
Maybe we also need the mapping of device bus IDs, subchannels, and 
CHPIDs: lscss -t 1732/03.
The content of /var/log/messages might also have additional information 
since the above logs that happen to appear on the console(s) are just a 
subset of kernel messages.
You might also find log entries regarding the FCP channels on the 
service element.


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Enumerating LUNs on DS8100

[Steffen Maier]

Mark is right about SLES.
Fernando is right about the LUN numbering scheme for DS8K. However, it 
may differ with other storage servers.
Additionally, all recent versions of SLES10, SLES11, RHEL5, and RHEL6 
should ship the perl script lsluns in the s390-tools package (named 
s390utils on RHEL). It can query the storage server by means of the 
report luns scsi command. It's documented per man page and also in the 
device drivers book on developerworks.


On 07/29/2011 12:45 PM, Mauro Souza wrote:

Unfortunately, it's for RHEL6.



On Fri, Jul 29, 2011 at 12:25 AM, Mark Postmp...@novell.com  wrote:

On 7/28/2011 at 05:29 PM, Mauro Souzathoriu...@gmail.com  wrote:

I've heard somewhere that there's a script capable of enumerating all LUNs
on a given WWPN. Do someone have this script on hand?


For which Linux distribution?  For SLES, zfcp_san_disc might be of some
use.


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: zFCP disk issue on linux system z

[Steffen Maier]

Hi Scott,

with RHEL(5), the persistent zfcp lun configuration is in the simple 
text file /etc/zfcp.conf. I don't know of any tools to manage this file 
except during the installation (with anaconda). Hence, any text editor 
will do.
See also 
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-s390info-zfcp.html 
which does describe post-installation configuration despite being part 
of the install guide.


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

On 05/20/2011 09:55 PM, Shumate, Scott wrote:

Sorry.  Im running red hat version 5.4



-Original Message-
From: Mark Post
Sent: Friday, May 20, 2011 3:49 PM



On 5/20/2011 at 02:59 PM, Shumate, Scottscshum...@bbandt.com

wrote:

I ran into something interesting today with zFCP disk.  I've assigned
a LUN to a linux server and it worked great.  I did the following.

1.  Set the adapter on line with chccwdev -e command
2.  Added target port to FCP adapter by echoing port_add into wwpn.
ex.  echo 0x50060e800571f007  port_add
3.  I cd to new port directory and added FCP LUN to that port by
echoing unit_add into new port directory.\
ex. Echo 0x000b  unit_add
4.  SCSI disk was available.  I validated it with lsscsi command.

I noticed that the LUN size was incorrect so I wanted to change the
adapter to use a different LUN.  In this case 0x0007. I
removed the old LUN and changed added the new LUN with the following
script.

#!/bin/bash
OLD_PWD=`pwd`
DIR=/sys/bus/ccw/drivers/zfcp
DROP=0x000b
ADD=0x0007
PORT1=0x50060e800571f007
PORT2=0x50060e800571f017
PORT3=0x50060e800571f006
PORT4=0x50060e800571f016
echo 1  /sys/bus/scsi/devices/0\:0\:0\:1/delete
echo 1  /sys/bus/scsi/devices/1\:0\:0\:1/delete
echo 1  /sys/bus/scsi/devices/2\:0\:0\:1/delete
echo 1  /sys/bus/scsi/devices/3\:0\:0\:1/delete
echo $DROP  $DIR/0.0.dc00/$PORT1/unit_remove echo $DROP
$DIR/0.0.dd00/$PORT2/unit_remove echo $DROP
$DIR/0.0.de00/$PORT3/unit_remove echo $DROP
$DIR/0.0.df00/$PORT4/unit_remove echo $ADD
$DIR/0.0.dc00/$PORT1/unit_add echo $ADD
$DIR/0.0.dd00/$PORT2/unit_add echo $ADD
$DIR/0.0.de00/$PORT3/unit_add echo $ADD
$DIR/0.0.df00/$PORT4/unit_add

It shows the new LUN.  I validated it with the lszfcp -D command.
Output below:
0.0.dc00/0x50060e800571f007/0x0007 0:0:0:1
0.0.dd00/0x50060e800571f017/0x0007 1:0:0:1
0.0.de00/0x50060e800571f006/0x0007 2:0:0:1
0.0.df00/0x50060e800571f016/0x0007 3:0:0:1

So you can see that the lun is now 0X0007.  When I reboot, it goes
back to 0x000b.  What am I missing?  To get around this issue, I had
to move LUNs around on the disk subsystem side.  Can someone give me a



good process of removing LUNs and then readd them or tell me what I'm
missing.


You didn't say what distribution you're running.  That's not relevant to
why you're seeing this happen, but it is relevant to how you fix it.

Essentially, every command you issued is a dynamic change to the system.
Nothing was done to tell the system to do anything different on the next
boot.  If you are running SLES, then the answer is to either:
1. Use YaST to do this work.
2. Use zfcp_host_configure and zfcp_disk_configure 3. Manually update
all the necessary configuration files yourself.

I would pick option #1 or #2.  :)


--
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/

Re: SLES11 SP1 Recovery System on different LPAR

[Steffen Maier]

On 01/26/2011 09:23 AM, Richard Heimo wrote:

Last week we make an similar installation with RHEL6. We must modify different 
Config-File



Add FCP oft he 2nd System in /etc/zipl.conf

rd_ZFCP=0.0.0301,0x50060e801525ab47,0x0005 
rd_ZFCP=0.0.0302,0x50060e801525ab57,0x0005


Iff the root file system is on this LUN, then that's correct, otherwise 
only /etc/zfcp.conf should be used to activate (non-root-fs) LUNs.



Create new Initial RAMDISK image

   dracut --force
   zcat /boot/initramfs-`uname -r`.img | cpio -iv


In contrast to mkinitrd, there is no more need to recreate initramfs 
with dracut, since initramfs content is by default generic (unless 
manually created in host-only mode). The only system specific 
cusomtization is via the boot parameters in zipl.conf. Therefore, I 
would recommend against recreating initramfs with RHEL6 to avoid 
potential errors on recreation (of the same content as before, anyway).
So modifying zipl.conf for root-fs-disks and running zipl afterwards is 
all you need with RHEL6.


http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_FCP-Attached_LUNs-Persistently.html#ap-s390info-Adding_FCP-Attached_LUNs-Persistently-Part_of_root_file_system


Prepare boot-Loader

   zipl


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Fedora 14 for IBM System z 64bit official release

[Steffen Maier]

On 01/26/2011 05:59 PM, Frederick, Michael wrote:

For those interested:

| If it took so long for Fedora to have a 64 bit favor, why would anyone use it?

Fedora supported s390x on Fedora 11, but not on 12 or 13.[1]


Just one little nit pick: F11 on s390x was a repo of rpm packages only, 
i.e. no working installer (anaconda) and no iso with necessary install 
image. One can build a bootable system based on that repo with some 
effort though.


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: vswitch name in sysfs

[Steffen Maier]

Not encouraging to make procedures dependent on vswitch names,
just sharing info on how to obtain base info within Linux itself.

On 01/19/2011 09:02 PM, Christian Paro wrote:

#!/bin/bash
### BEGIN SCRIPT: getswitchname ###
function getVSwitch {
   local iface=$1
   local userid=$(vmcp q userid)


# grep ^VM.*Name: /proc/sysinfo
VM00 Name:LNXUSR1

might save a hypercall by not using vmcp


   local vdev=$(sed -rn
's/^SUBSYSTEM.*KERNELS==0.0.([0-9a-f]{4}),.*NAME='${iface}'$/\1/pI' \
/etc/udev/rules.d/70-persistent-net.rules)


This file might have been edited by an administrator meanwhile and no 
longer reflect the actual system configuration. You can get the latter 
directly from sysfs to obtain the mapping between network interface name 
and device bus IDs (devnos) on s390:


local vdev=$(readlink -f /sys/class/net/eth0/device)
vdev=${vdev##*.}

Based on:
# ll /sys/class/net/eth0/device
lrwxrwxrwx. 1 root root 0 Jan 20 18:33 /sys/class/net/eth0/device - 
../../../0.0.f5f0



   catdirectoryentry --mergeprofile ${userid%% *} | sed -n
's/^NICDEF\s'${vdev}'.*SYSTEM //p'
}

getVSwitch $1



...where `catdirectoryentry` is a script I wrote for a project I'm current
working on, which pulls the directory entry for a guest, expands all


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Finding the lost symlink in SLES11.1

[Steffen Maier]

On 12/28/2010 08:22 PM, Richard Troth wrote:

There are changes between the kernel shipped with SLES 10 and that
shipped with SLE 11.  If you have home-grown scripts (as many of us
do), you'll have to adjust them.  Looks like the link you're after
changed from

 /sys/devices/dcssblk/PERFOUT/block:dcssblk0

to

 /sys/devices/dcssblk/PERFOUT/block/dcssblk0

(if I am reading the traffic correctly).


The recent distro major releases (SLES11 SP1, RHEL 6) have their kernel 
built without CONFIG_SYSFS_DEPRECATED_V2 [1] which seems correct and has 
the consequences on sysfs layout that you encountered.

This applies to all kinds of device classes, e.g. block or network [3].
Indeed the former symlink was replaced with two containing directories, 
the name of the outer depending on the device class.
There are some rules for user space tooling working with sysfs to get it 
future-proof [2]. Maybe they are of help.


[1] http://lxr.linux.no/#linux+v2.6.32/init/Kconfig#L608
[2] http://lxr.linux.no/#linux+v2.6.32/Documentation/sysfs-rules.txt
[3] 
https://www.redhat.com/archives/anaconda-devel-list/2010-June/msg00095.html


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: ethtool and SLES10SP2

[Steffen Maier]

On 12/23/2010 02:12 PM, Victor Echavarry Diaz wrote:

The problem is we can upgrade until Oracle certify SLES11. And our
network is running 1000MB but velocity show the guests are 100MB so
we want to know how to change it.


On any distro release, the lsqeth utility from the s390-tools package 
can display the card_type. This attribute contains the link speed, but 
only for real OSA, i.e. dedicated / direct-attached to z/VM guests.


In my following example, I used a dedicated OSA with 1Gbps Ethernet.
# lsqeth
Device name : eth0
-
card_type   : OSD_1000
...

Please find documentation of possible card_type values in
http://public.dhe.ibm.com/software/dw/linux390/docu/l26edd01.pdf, qeth 
chapter (page 107) -- or alternatively any other recent device drivers 
book (the older version matching SLES 10 did not yet document the 
card_type attribute).


If you use virtual OSA, i.e. through z/VM VSWITCH, then you would have 
to check the link speed of the VSWITCH uplink OSA(s) (RDEV(s) and/or 
portgroup) under z/VM.


I don't know which source velocity uses to determine the network (link) 
speed, but the above described method should provide reliable 
information directly from the qeth device driver.



-Original Message- From: Linux on 390 Port
[mailto:linux-...@vm.marist.edu] On Behalf Of Mark Post Sent:
Wednesday, December 22, 2010 5:58 PM To: LINUX-390@VM.MARIST.EDU
Subject: Re: ethtool and SLES10SP2


On 12/22/2010 at 03:04 PM, Victor Echavarry
Diazvechava...@evertecinc.com wrote:

We are trying to use ethtool to see the card speed and we receive
the following message:

ethtool eth0 Settings for eth0: No data available

How we solve this?


Upgrade to SLES11 SP1.  The version of ethtool in SLES10 doesn't
support qeth devices.

Mark Post


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Red Hat 6 Installation on DASD

[Steffen Maier]

On 12/07/2010 07:43 PM, Scully, William P wrote:

I'm having trouble getting the Red Hat 6 GA materials to load onto CKD
disks.



The error message is:

   An error was encountered while formatting device /dev/dasdb1.
   invalid device specification

This is shown in the window Formatting Failed.  Advice, please?



- I can see /dev/dasda, /dev/dasdb and /dev/dasdc.  Each of these disks
had been previously formatted with the CMS FORMAT command.


The RHEL 6 installer can currently only cope with ECKD DASDs which were 
low-level formatted with the compatible disk layout (CDL).

You could accomplish this at the root userid with the dasdfmt Linux tool.
IIRC, non-CDL causes the error you've seen.


- On the root userid (before I respond OK to the Red Hat splash
screen) I fdisk each /dev/dasd disk, allocating the primary partition 1


Did you really use fdisk or actually fdasd. It should be the latter for 
ECKD DASD.



using all available space on the disk.



- On the Partitioning Type window I use entire drive and ensure that
only /dev/dasdb and /dev/dasdc are selected for use during installation.



I select OK to continue.

- A window opens Writing storage configuration to disk asking if I
really want to write the changes to disk.  I select that button.

- The installation fails with the window Formatting failed:

   An error was encountered while formatting device /dev/dasdb1.
   invalid device specification



In the GUI installation (step 23.6 in the doc) a panel allows
Specialized Storage Devices.  Perhaps I must be using this path?


That would not make a difference. It would only allow you to activate 
FCP LUNs

(or iSCSI / FCoE although I'm not sure which of those is supported on s390).
You could also filter out specific disks. However, we do this by means 
of only enabling those disks in the DASD parameter on s390, so no need 
for blacklisting disks here.



Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Red Hat Enterprise Linux 6 - installing problems

[Steffen Maier]

On 12/02/2010 03:51 AM, Bern VK2KAD wrote:

I then managed to make progress using the URL install method and ftp - after
successfully logging on to the ftp server things started to happen. So far so 
good.

Alas, suddenly it all evaporated into a puff of smoke - the following is a
snip from the log.

Can anyone explain why the install decided to shutdown -

02:44:43,403 INFO : transferring 
ftp://b...@20.250.180.52/RHEL6/images/install.img
02:45:24,353 INFO : mounted loopback device /mnt/runtime on /dev/loop0 as 
/tmp/install.img
02:45:24,354 INFO : got stage2 at url 
ftp://b...@20.250.180.52/RHEL6/images/install.img
02:45:24,354 INFO : reset repo= parameter to ftp://b...@20.250.180.52/RHEL6
02:45:26,682 INFO : Loading SELinux policy
02:45:42,692 INFO : getting ready to spawn shell now
02:45:42,697 INFO : not spawning a shell
02:45:54,461 INFO : Running anaconda script /usr/bin/anaconda


Apparently, the installer made progress into phase 3 
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-guimode-s390.html.

Did you see any TUI/GUI parts of this phase 3?
If so, during which of the wizard screens did the installer bail out?

Maybe enabling debug output will show some hints on the console. Could 
you please add loglevel=debug ignore_loglevel 
[https://bugzilla.redhat.com/show_bug.cgi?id=603136#c1] to your parm 
file (NOT conf file) and post the entire console log from IPL to shutdown?



about to exec shutdown
disabling swap...
unmounting filesystems...
/mnt/runtime done
disabling /dev/loop0 LOOP_CLR_FD failed: 16
/proc done
/dev/pts done
/sys done
/selinux done
waiting for mdraid sets to become clean...
Error: mdadm exited with status: 127
sending termination signals...done
sending kill signals...done
halting system


This is just the default follow-on procedure in case anaconda bails out.
There is an anaconda boot option nokill to prevent this default 
shutdown. Unfortunately, it currently does not work on s390. It would be 
very helpful to fetch the logs from the volatile /tmp to see where the 
installer bailed out. In case you need or would like to do that, the 
following patch would need to be applied to sbin/init inside initrd.img:


commit ea22912b014c64ca8732305b36d4463c33f438e9
Author: Steffen Maier ma...@linux.vnet.ibm.com
Date:   Mon Jun 7 03:08:23 2010 +0200

Support nokill boot option for shutdown in linuxrc.s390

diff --git a/loader/linuxrc.s390 b/loader/linuxrc.s390
index 2a4104a..c0a6331 100644
--- a/loader/linuxrc.s390
+++ b/loader/linuxrc.s390
@@ -103,10 +103,17 @@ function checkipv4()
 return $?
 }

+function getKillPolicy()
+{
+if grep -q nokill /proc/cmdline; then
+echo --nokill
+fi
+}
+
 function doshutdown()
 {
 echo $about to exec shutdown
-exec /sbin/shutdown
+exec /sbin/shutdown $(getKillPolicy)
 exit 0
 }

@@ -123,7 +130,7 @@ function doreboot()
 fi

 echo $about to exec shutdown -r
-exec /sbin/shutdown -r
+exec /sbin/shutdown -r $(getKillPolicy)
 exit 0
 }


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Red Hat Enterprise Linux 6 - installing problems

[Steffen Maier]

On 11/30/2010 11:59 PM, Karsten Hopp wrote:

Am 30.11.2010 05:47, schrieb Bern VK2KAD:

I can successfully IPL from the generic.ins file and the installer
starts.



At the Installation Method dialog box I select URL - next I get a No
driver found dialog to which I select Select driver

Next dialog is a combo box Select Device Driver to Load - I cannot
get any
of the options to throw anything other than returning me to the No
Driver
Found dialog again.



Select Device Driver to Load rings a bell, I've stumbled over that
during the F-14
development, too.
Bad news for you is that CTC isn't supported anymore as a installation
device in RHEL6,
I've added support for point-to-point devices back in Fedora-14.


This issue is described in the following bug comment and is due to 
loader (of anaconda) not accepting ptp network devices. CTC does work up 
to the start of loader since the earlier linuxrc.s390 sets up CTC 
correctly and this is used for the ssh login.


https://bugzilla.redhat.com/show_bug.cgi?id=596826#c22

While the earlier parts in above bug are fixed in RHEL6 and upstream, 
the following fixes for your encountered issue only seem to be upstream:


http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=aec2e17840f2c3f5e5c605b96518e3d80dadf53d
http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=dc68f9a6bc1c36d808a8c8c514f7cb6caac5f769
http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=fa5ed4e8bbc5d56750a03a82b596dbdf804d1bf0
http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=d3180ef38db7d4cc2615ebadedfbb59d9fe984cd

However, loader (as part of anaconda) accepting ptp devices is only part 
of the installation solution and NetworkManager also needs to accept ptp 
devices since anaconda uses NM to manage network devices once loader has 
started (and thus takes over device management from linuxrc.s390 which 
runs before loader on s390).

I found the following bug opened by Karsten for NM:

https://bugzilla.redhat.com/show_bug.cgi?id=641986

HTH
Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Fedora 14 for System Z needs testers!

[Steffen Maier]

On 11/26/2010 07:52 PM, Neale Ferguson wrote:

Testing away, rather than flood the list with these results where would you 
like them sent?

system-config-lvm
Xlib:  extension RANDR missing on display localhost:10.0.

Gdk-ERROR **: The program 'system-config-lvm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
   (Details: serial 1068 error_code 16 request_code 7 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...
Aborted


I've seen such X protocol errors ever since the most recent major distro 
releases (sles11, rhel6) and since F11, whenever I used a rather old X 
server which did not provide whatever X extensions those recent GTK 
versions seem to require. Unfortunately, GTK does not seem to check for 
the required extensions but rather keeps on going and causes confusing 
errors as above. I doubt that GTK would drop the requirement on those 
extensions, so the only fix I could think of would be to check for those 
extensions and print a helpful error message.


My workaround has been to use VNC instead. Meanwhile I have a recent X 
server on my desktop which works with X11. However, for connections to 
the host which have anything but very short LAN latencies, I would 
recommend VNC in any case. Otherwise X11 and GTK slow down any X client 
program, presumably because of many blocking round trip X11 messages 
throttling program progress.


The problem is documented for RHEL 6:
If the installer on your workstation fails because the X11 server does 
not support required X11 extensions you might have to upgrade the X11 
server or use VNC.

[http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/Installation_Procedure_Overview-s390-GUI.html]

Even though it's RHEL 6 documentation, F14 is extremely similar in terms 
of installation.


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Can't create ctcmpc groups

[Steffen Maier]

On 11/05/2010 03:45 PM, Roger Evans wrote:

According to chap. 11 of the device driver manual, I should have 3
directories:
  /sys/bus/ccwgroup/drivers/ctcmpc/0.0.400
/sys/bus/ccwgroup/drivers/0.0.400
and
/sys/devices/ctcmpc/0.0.400


That might be a typo in the dd book for the October 2005 stream.
Older development stream books seem to have it right:

/sys/devices/cu3088/0.0.400

Back then, both lcs and ctcmpc were based on cu3088. Since the latter 
did the bind of the devices, lcs and ctcmpc devices could be found under 
cu3088.


More recent kernel versions do not have the cu3088 meta ccw driver 
anymore and one would see /sys/devices/lcs or /sys/devices/ctcm

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=0ca8cc6fe7e1acd42a8a3741473ad7540f13893a


I have the first two, but not the last one.  I don't even have a
directory /sys/devices/ctcmpc:
---
LNXCCL:~ # ls /sys/devices
css0  cu3088  iucv  platform  qeth  system
--


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Question about multipathing on zDebian (Lenny)

[Steffen Maier]

On 10/07/2010 06:06 PM, Wiggins, Mark wrote:

Okay first, I had already changed my
/etc/sysconfig/hardware/config-ccw-0.0.a200 to the way that you
suggested based on a recommendation from David Straub.

So on to the lszfcp commands. Before and after reboot are the same
for lszfcp -HV command

 # lszfcp -HV

Looks like the fcp adapters (HBAs) come up but the LUNs seem missing 
after regular boot.



But the # lszfcp -DV command shows *nothing* after reboot and shows
this before the reboot,

 # lszfcp -DV

The list looks good. How did you get the LUNs active before the reboot?
By manually calling hwup or by writing to sysfs? Whatever trigger it 
was, this trigger seems to be missing during regular boot.



Obviously, that is an issue. So what do you think that I'm missing?
It still seems that I'm missing a configuration file, maybe it's not
/etc/sysconfig/hardware/config-ccw-0.0.a200 in Debian??? I've read


Have you tried tracing the hwup (shell script) command to see if and why 
it fails?

# /bin/bash -x `which hwup ...`

Since debian seems to look very much like SLES with respect to 
persistent device configuration, you could look out for the command line 
tools which YaST uses on SLES to write the hwconf files. SLES ships them 
as part of the s390-tools package. Those tools can also be called 
directly as user root on the command line and this way you could be sure 
to have the hwconf file being syntactically correct and have the correct 
name.

To configure fcp adapters:
# zfcp_host_configure
To configure fcp luns (on configured adapters):
# zfcp_disk_configure

Their usage is described in the first few comment lines of those shell 
scripts. You can also trace them to see what they do and which files 
they write. If that worked, then try rebooting and if the LUNs still 
don't come up automatically you could also try to update initramfs and 
run zipl and see if it'll then work. Sorry, I don't know anything s390 
specific about debian.


BTW, there are more command line tools for persistent device 
configuration in SLES (10 and 11):

dasd_configure
qeth_configure
ctc_configure (also works for LCS devices so it actually handles cu3088)
iucv_configure


through IBM's Device Drivers, Features, and Commands (amongst a
hundred other documents), but haven't found anything there either. It
shows you how to configure the devices (echo 0x001f
0.0.a200/0x50050768011035d9/unit_add) but doesn't suggest where to
put those configuration parameters to make them permanent.


Yes, you won't find distro-specific persistent configuration procedures 
in the device drivers book. It describes the kernel/user space interface 
which is code IBM contributes, so only dynamic (non-persistent) 
configuration. How to configure devices persistently, should be in the 
distro documentation since the distros contribute that code.



Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Question about multipathing on zDebian (Lenny)

[Steffen Maier]

On 10/05/2010 07:35 PM, Wiggins, Mark wrote:

I'm trying to
add some multipath'd devices to a Debian(Lenny)  instance. I can get
the devices configured properly,



I just can't get these definitions to hold across a reboot. I've


In order to narrow down which activation step does not work correctly, 
it would be interesting to know if the following holds true after the 
boot process finished:

- zfcp adapters for each path are online
  # lszfcp -HV
- all fcp luns for each path and disk are online
  # lszfcp -DV
Those would be the prerequisites to have the necessary SCSI disks for 
device-mapper multipath to work with. After that, dm-mp might have 
problems. However, I'm not particular familiar with that and its config 
file (incl. blacklists/whitelists).



My /etc/sysconfig/hardware/config-ccw-0.0.a200 looks like this,
# Configured zfcp disks
ZFCP_LUNS=0x50050768014035ee:0x001f
ZFCP_LUNS=0x50050768014035d9:0x001f
ZFCP_LUNS=0x50050768014035ee:0x0020
ZFCP_LUNS=0x50050768014035d9:0x0020


This seems to overwrite the ZFCP_LUNS shell variable three times and the 
last one will win. So I guess only the FCP LUN 0x0020 on 
WWPN 0x50050768014035d9 will be set online and you're missing the other 
three LUNs (or at least the second path to the same LUN).


This looks very much like the SLES syntax and IIRC, you have to use one 
ZFCP_LUNS variable assignment and put each WWPN:LUN pair on a separate 
line within the same double quotes on the right hand side of the 
assigment, i.e.:


# Configured zfcp disks
ZFCP_LUNS=0x50050768014035ee:0x001f
0x50050768014035d9:0x001f
0x50050768014035ee:0x0020
0x50050768014035d9:0x0020

You could try tracing the hwup (shell script) command to see where it fails.
# /bin/bash -x `which hwup ...`

Not sure how debain handles disks that are members of the root-fs and 
those that are not. If the luns are not required for the root-fs you 
might even get away without updating the initramfs and without running 
zipl. However, it's safe to do both steps anyway.


HTH
Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Dev DASD

[Steffen Maier]

On 07/22/2010 06:30 PM, Scully, William P wrote:
 Where or how is a disk address mapped to /dev/dasdx (where x is a, b,
 c)?  I ask because at install time I am -certain- that I instructed the
 partitioner to make the 200 disk to be /dev/dasda1, the 201 to be
 /dev/dasdb1, and 202 to be /dev/dasdc1.  (I have a screen-shot of the
 VNC windows, but won't include it here.)  
 
 After installation completes I see: 
 
 linux024:~ # cat /proc/dasd/devices
 0.0.0201(ECKD) at ( 94: 0) is dasda   : active at blocksize:
 4096, 600840 blocks, 2347 MB
 0.0.0202(ECKD) at ( 94: 4) is dasdb   : active at blocksize:
 4096, 600840 blocks, 2347 MB
 0.0.0200(FBA ) at ( 94: 8) is dasdc   : active at blocksize:
 512, 409600 blocks, 200 MB
 
 How can I change the DASDA, B, and C settings around?  Or am I missing a
 step in the expert partitioning, during set-up?
 
 
 This is on SLES 11.  

IIRC, SLES 11 activates DASDs during installation in the order provided
manually by the user through the YaST UI or in an autoyast configuration
file. Only during installation, it arranges for /dev/dasdX device names
to have a predictable order and thus being able to use those kernel
device names for partitioning during installation.

In the installed system, DASDs (or zFCP LUNs or network devices) are
activated by udev rules
/etc/udev/rules.d/51-devicetype-devicebusid.rules.
Since udev executes rules in parallel, the ordering of all those
51-rules cannot be predetermined.
Therefore, you should use persistent device names to reference, e.g.
DASDs, instead of their kernel device names /dev/dasdX. Symlinks such as
/dev/disk/by-path/ccw-devicebusid work well to reference DASDs by
their devno. YaST can be told to use this as identifier for partitions
in /etc/fstab and IIRC by-path is the default in SLES 11.

Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Can't get hipersockets to come online

[Steffen Maier]

On 07/20/2010 01:47 PM, Bauer, Bobby (NIH/CIT) [E] wrote:
 ifcfg-his- has:

I suppose it's /etc/sysconfig/network-scripts/ifcfg-hsi0

 DEVICE=hsi0
 BOOTPROTO=static
 ONBOOT=yes
 NETTYPE=qeth
 MTU=8192
 SUBCHANNELS=0.0.710C,0.0.710D,0.0.710E

To be on the safe side, hex digits for Linux should be lower case,
i.e. SUBCHANNELS=0.0.710c,0.0.710d,0.0.710e.

Whenever there are problems with persistently configured network devices
not being grouped or not being online, the following manual triggering
of the script /lib/udev/ccw_init that usually does that triggered by
udev (/etc/udev/rules.d/55-ccw.rules) might be of help (all in one line):

DEVPATH=/sys/bus/ccw/devices/0.0.710c SUBSYSTEM=ccw bash -x
/lib/udev/ccw_init

 IPADDR=10.1.160.46
 NETMASK=255.255.0.0
 OPTIONS='fake_ll=1'

 They are attached
 [r...@lssb1 log]# vmcp q 710c-710e
 OSA  710C ATTACHED TO LSSB1710C DEVTYPE HIPER   CHPID 20 IQD
 OSA  710D ATTACHED TO LSSB1710D DEVTYPE HIPER   CHPID 20 IQD
 OSA  710E ATTACHED TO LSSB1710E DEVTYPE HIPER   CHPID 20 IQD
 
 [r...@lssb1 log]# vmcp q virt osa
 OSA  710C ON OSA   710C SUBCHANNEL = 0008
 710C DEVTYPE HIPER   CHPID 20 IQD
 710C MAC 02-0F-00-00-00-0C CURRENT
 710C QDIO-ELIGIBLE   QIOASSIST-ELIGIBLE
 OSA  710D ON OSA   710D SUBCHANNEL = 0009
 710D DEVTYPE HIPER   CHPID 20 IQD
 710D QDIO-ELIGIBLE   QIOASSIST-ELIGIBLE
 OSA  710E ON OSA   710E SUBCHANNEL = 000A
 710E DEVTYPE HIPER   CHPID 20 IQD
 710E QDIO-ELIGIBLE   QIOASSIST-ELIGIBLE

Are the subchannels visible to Linux with lscss, i.e. not masked with
e.g. cio_ignore?
I guess they are, since you were able to group and set online manually
with sysfs.

 They aren't in /proc/qeth
 [r...@lssb1 /]# cat /proc/qeth
 devicesCHPID interface  cardtype   port chksum 
 prio-q'ing rtr4 rtr6 fsz   cnt
 
 -- - -- --  -- 
 --   - -
 
 0.0.0800/0.0.0801/0.0.0802 x00   eth0   GuestLAN QDIO  0sw always_q_2 
 no   no   64k   16
 
 Just the interface to the vswitch.


Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/

Re: Strange problems adding network adapter no 2 (eth1) in SLES11 SP1

[Steffen Maier]

On 07/15/2010 11:39 AM, Agblad Tore wrote:
 Ok, I have tried that now, had to be sure how to turn of
 firewall first via VM console in case of no net at all.
 
 No change, but now I get messages in the log (messages file)
 with 'kernel: martian source my login ip not working from my PC ip 
 address, on dev eth0' (or 1) 
 
 martian source means a source IP that is not possible together with other 
 ipconfig
 ( I have done some googling here ), so the kernel just refuse it.
 
 But I don't get the reason here, it is not an 'impossible' source IP here.

Since you have multiple interfaces on the same subnet, things may be a
bit complicated.

The kernel message you get is from ip_handle_martian_source
[http://lxr.linux.no/#linux+v2.6.32/net/ipv4/route.c#L1915].
In your case I suspect it to be called by __mkroute_input
[http://lxr.linux.no/#linux+v2.6.32/net/ipv4/route.c#L1945]
after having checked the source IP address with fib_validate_source
[http://lxr.linux.no/#linux+v2.6.32/net/ipv4/fib_frontend.c#L223].
The latter does a reverse path filtering check among other things.
Having multiple interface on the same subnet, with strict reverse
path filtering, only packets are allowed that have:
destination IP of packet == source IP of route table lookup with
source IP of packet as destination IP key for table lookup.

Depending on which of your eth{0,1,2} ends up having the first
routing table entry for the subnet, only traffic sent to this IP is
allowed but all other traffic from the same subnet ends up giving you
the above kernel message and the packets are dropped.

You can check if my assumption is valid with the following command:
tail /proc/sys/net/ipv4/conf/*/rp_filter
If it contains 1 for strict rp_filter on all eth{0,1,2} with SLES11SP1
but not with SLES10 then that may be the difference.

Do you really need multiple interfaces in the same subnet?
If so, you may configure loose rp_filter by writing 2 into the above
sysctl files (persistent config may be done with /etc/sysctl.conf)
[http://lxr.linux.no/#linux+v2.6.32/Documentation/networking/ip-sysctl.txt#L726].

Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
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/