Nagios agent for SLES 12 SP5

[Will, Chris]

Does anyone use Nagios on their SLES servers?  We are currently using SNMP to 
report up to Nagios but it is somewhat lacking.

Chris


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.


This message was secured by Zix(R).

--
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: Sles 12 with ibm Flashsystem 9500

[Rogério Soares]

27Gb Master... Looks Like a big memory leak :-(

Em qui., 11 de mai. de 2023 20:19, Mark Post  escreveu:

> On 5/11/2023 5:46 PM, Rogério Soares wrote:
> > I see a lot of oom-killer when dd
> > runs..
>
> This sounds like you need to increase the amount of memory defined for
> this system.
>
> > PMR opened with IBM
>
> Glad to hear it.
>
>
> 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://www2.marist.edu/htbin/wlvindex?LINUX-390
>

--
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: Sles 12 with ibm Flashsystem 9500

[Mark Post]

On 5/11/2023 5:46 PM, Rogério Soares wrote:

I see a lot of oom-killer when dd
runs..


This sounds like you need to increase the amount of memory defined for 
this system.



PMR opened with IBM


Glad to hear it.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Sles 12 with ibm Flashsystem 9500

[Rogério Soares]

Hello Mark,

I have tried multipath.conf recommended on
https://www.ibm.com/docs/en/flashsystem-9x00/8.3.x?topic=system-settings-linux-hosts

I'm running sles12 sp5..

Update: I was removed all references about 95000, unconfigured luns, and
ajusted everything to acess a fresh lun on ibm v7k storage

With a single dd creating a 200gb dummy file, the behavior repets.. Looks
like not be a Model storage problem... I see a lot of oom-killer when dd
runs..

PMR opened with IBM






Em qui., 11 de mai. de 2023 16:52, Mark Post  escreveu:

> On 5/11/2023 9:19 AM, Rogério Soares wrote:
> > Hello folks, anyone is using ibm Flashsystem 9500 with Sles 12? I'm
> facing
> > strange behavior after Mount disks Sles stay very very slow, when try
> > copy any data, Sles crash..
>
> What version of SLES12? Are you up to date on maintenance? Have you
> tried with a more modern version?
>
> Have you collected any performance data both when and when not seeing
> the problem?
>
> What sort of crashes are you seeing? Any dumps taken?
>
> > I have adjusted multipath.conf as suggested by ibm, but no luck yet...
>
> What sort of adjustments did they recommend?
>
>
> 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://www2.marist.edu/htbin/wlvindex?LINUX-390
>

--
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: Sles 12 with ibm Flashsystem 9500

[Mark Post]

On 5/11/2023 9:19 AM, Rogério Soares wrote:

Hello folks, anyone is using ibm Flashsystem 9500 with Sles 12? I'm facing
strange behavior after Mount disks Sles stay very very slow, when try
copy any data, Sles crash..


What version of SLES12? Are you up to date on maintenance? Have you 
tried with a more modern version?


Have you collected any performance data both when and when not seeing 
the problem?


What sort of crashes are you seeing? Any dumps taken?


I have adjusted multipath.conf as suggested by ibm, but no luck yet...


What sort of adjustments did they recommend?


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Sles 12 with ibm Flashsystem 9500

[Rogério Soares]

Hello folks, anyone is using ibm Flashsystem 9500 with Sles 12? I'm facing
strange behavior after Mount disks Sles stay very very slow, when try
copy any data, Sles crash..

I have adjusted multipath.conf as suggested by ibm, but no luck yet...

--
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: GRUB - DRACUT error on SLES 12 SP5

[Mark Post]

On 10/15/21 11:12 AM, Victor Echavarry wrote:

dracut-initqueue[418]: Warning: Could not boot.
  Starting Dracut Emergency Shell...
Warning: /dev/swapvg/swap01lv does not exist

Generating "/run/initramfs/rdsosreport.txt"

Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.

Give root password for maintenance
(or press Control-D to continue):

How this happened after patching a guest? There is a way to solve it?


I would guess that it's not related to any patching you did. The most
frequent cause of this that I've seen is that someone added a new disk
to the LVM volume group, and did it in a way that the udev rules for it
weren't written out to /etc/udev/rules.d/.

You should be able to run vgscan and pvscan to see if those report any
missing disks. If they do, then bring the volume online and re-run them.
Then "systemctl default" should bring the system up the rest of the way
and you can check to see if the necessary udev rules are there, or if
they're excluded by cio_ignore, etc., etc.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

GRUB - DRACUT error on SLES 12 SP5

[Victor Echavarry]

After patching a guest and reboot it, we find the following error:

Booting default (grub2)
dracut-initqueue[418]: Warning: dracut-initqueue timeout - starting timeout scri
pts
dracut-initqueue[418]: Warning: dracut-initqueue timeout - starting timeout scri
pts
dracut-initqueue[418]: Warning: dracut-initqueue timeout - starting timeout scri
pts
dracut-initqueue[418]: Warning: dracut-initqueue timeout - starting timeout scri
pts
dracut-initqueue[418]: Warning: dracut-initqueue timeout - starting timeout scri
pts
dracut-initqueue[418]: Warning: dracut-initqueue timeout - starting timeout scri
pts
dracut-initqueue[418]: Warning: dracut-initqueue timeout - starting timeout scri
pts
dracut-initqueue[418]: Warning: dracut-initqueue timeout - starting timeout scri
pts
dracut-initqueue[418]: Warning: dracut-initqueue timeout - starting timeout scri
pts
dracut-initqueue[418]: Warning: Could not boot.
 Starting Dracut Emergency Shell...
Warning: /dev/swapvg/swap01lv does not exist


Generating "/run/initramfs/rdsosreport.txt"


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.


Give root password for maintenance
(or press Control-D to continue):

How this happened after patching a guest? There is a way to solve it?

Regards,

Victor Echavarry
System Programmer
Operating Systems
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.

--
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: unstable LVM on SLES 12

[Mark Post]

On 4/14/20 8:17 AM, Csaba Polgar wrote:
> Hello,
> 
> In the past, there was an attempt to upgrade a Linux system from SLES11 SP4
> to SLES 12 SP4, but it was not successful because of the missing disks
> after OS upgrade.
> We saw the below error messages in the SLES11 SP4:
> 
> hostname:~ # lvs | grep "Attr\|ao--p"
>   LV  VG   Attr
> LSize   Pool Origin Data%  Move Log Copy%  Convert
>   db2db_db2bmtg0_db2data  vg0
> -wi-ao--p  60.00g
>   db2db_db2bmtg0_db2dump  vg0
> -wi-ao--p   2.00g
>   is_appname   vg0
> -wi-ao--p 700.00g
>   is_appname_mclm  vg0
> -wi-ao--p  44.25g
>   is_appname_tss-mzvg0
> -wi-ao--p 250.00g
>   opt_IBM_wstemp  vg0
> -wi-ao--p  65.00g
> hostname:~ #

Actual messages from the boot process would be more helpful. This output
isn't an "error message," just a status display.

-snip-
> 2) The upgrade was very slow and struggle. (The Linux system was useable
> after 3 reboot, and there was many device(dasd)/lvm/FS error.)
> In the SLES12 I saw many simlar errror messages:
> WARNING: Device for PV x5zvM9-l42o-ifVM-zMWC-NgT5-dZ8G-afApuY not found or
> rejected by a filter.
> ...
> Couldn't find device with uuid x5zvM9-l42o-ifVM-zMWC-NgT5-dZ8G-afApuY

This is where looking at the contents of /etc/lvm/archive might be
helpful. The files in there will tell you what the device name
(/dev/dasd??) was associated with that UUID at the time it was created.
Note that this does not mean it will be the same device today. Looking
at the system logs from that time should reveal the device number
(0.0.) that device name had at the time.

> 3 ) Many error message came from the old, and unused and corrupt VG (vg0)
> and its LVs, and PVs, so I deleted these (the PVs, LVs of vg0).
>   After a new reboot, disappeared every error messages (in SLES 12 SP4,
> after upgrade).

That should have been done a long time ago.

> 4 ) At this time, I have checked every filesystem (~80, with fsck), and
> every filesystem was good.
> 
> 5 ) I updated the metadata of LVM ( to lvmetad).

I don't know what this means.

> 6 ) I performed more (~10) boot on this Linux system to test, and I saw
> similar error messages during every boot:
> [FAILED] Failed to start LVM2 PV scan on device 94:617.
> See 'systemctl status lvm2-pvscan@94:617.service' for details.

What does the output from that command show?

-snip-
> 7 ) Aftet some reboot, I saw same error messages about the new VG (vg1)
> than above (in step 2) about the old and faulty VG (vg0)!;
> It means, that one or more of the Physical Volumes is missing from the
> Linux system, from the new VG.

Do you have a list of the devices that are supposed to be there? Does
that match the list of devices that actually are there?

-snip-
> Could somebody please say me, what should be fixed to get a stable PVs,
> LVs, FSs on SLES 12?

All of this sounds like some sort of configuration problem on the
system. I've not heard of anyone else having a problem like this on
SLES12. I'm not 100% certain that's the answer, but it seems likely.

I would say you need to start with documenting the current status of the
system. What DASD devices are in use, what their device names, device
numbers, and LVM UUIDs are, etc.

Then, make backups of the system, restore them to new DASD, and document
the mapping between the two. If you're using z/VM, you should have all
the same virtual addresses as you do on the production system.

Then perform the upgrade. Make sure everything you used to have, is
still there. That means each DASD device number and the UUID associated
with it.

Investigate any messages that say something like "See 'systemctl status
lvm2-pvscan@94:617.service' for details." Examine the system log from
the boot process. Is every device being found and handled properly? And
so on. Check /etc/lvm/lvm.conf to make sure the filter statement(s) in
there aren't excluding anything you need. Essentially, you need to dig
into the whole configuration and devices to make sure everything lines
up properly and makes sense.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: unstable LVM on SLES 12

[Mike Friesenegger]

Hello Csaba,

My experience leads me to believe that a step or steps in the upgrade 
process are the root cause of the issues that you are seeing.


You mention making a backup of the OS DASD but it is unclear to me if 
you tried to perform a test upgrade on this backup DASD.  The LVM 
entries still exist on the backup and LVM errors would happen if the 
LVMs were not enabled and used on the backup DASD.  This is one example 
of where a step might be a cause of the issues you are seeing.


One idea is to use vgexport so that the volume groups and its disks are 
unable to used during the upgrade process.  This is an idea that you 
should test on a test 11 SP4 system before attempting on the production 
system.  Here are the high level steps that I would do to test this 
idea.  First make sure that the fstab entries are commented out so the 
LVs are not mounted.  Then use vgexport to put the VGs in an offline 
state.  NOTE:  It is always a good idea to have a backup of the data on 
the VGs before performing vg operations like vgexport.  Once the VGs are 
successfully exported, reboot SLES 11 SP4 to make sure that no FS and 
mounting errors exist.  Finally, confirm the VGs and LVs are not used by 
the system.   Once this is done then I would try an offline upgrade from 
11 SP4 to 12 SP4.  BTW - SLES 12 SP5 is released and I strongly 
encourage upgrading  11 SP4 to this version.


Have you on the customer's behalf or the customer opened a support 
request to get ideas and recommendations regarding the issues you are 
seeing?


Regards,

Mike

On 4/14/20 6:17 AM, Csaba Polgar wrote:

Hello,

In the past, there was an attempt to upgrade a Linux system from SLES11 SP4
to SLES 12 SP4, but it was not successful because of the missing disks
after OS upgrade.
We saw the below error messages in the SLES11 SP4:

hostname:~ # lvs | grep "Attr\|ao--p"
   LV  VG   Attr
LSize   Pool Origin Data%  Move Log Copy%  Convert
   db2db_db2bmtg0_db2data  vg0
-wi-ao--p  60.00g
   db2db_db2bmtg0_db2dump  vg0
-wi-ao--p   2.00g
   is_appname   vg0
-wi-ao--p 700.00g
   is_appname_mclm  vg0
-wi-ao--p  44.25g
   is_appname_tss-mzvg0
-wi-ao--p 250.00g
   opt_IBM_wstemp  vg0
-wi-ao--p  65.00g
hostname:~ #

Please see the last see Attribute, which is "p". It means (see manual
pages):   (p)artial: One or more of the Physical Volumes this Logical
Volume uses is missing from the system.

We thought, that the permanent solution is the migration every data (~80
FileSystem) to a new Volume Group (from the vg0 to vg1). It was performed.
   The old and faulty VG (=Volume Group) (vg0) was not deleted with its LVs
(Logical Volume) and PVs (Physical Volume), but these were NOT used or
mounted.
   After it, the error messages disappeared on the SLES11 from the used
disks (PVs, LVs also). This was the staus till the new attempt of Linux
upgrade.

1 ) After it (on the last week), I started the OS upgrade again. I created
a full backup about the Linux OS (SLES 11) to a new disk before the
upgrade.
(The Linux itself is only on a pure 1 disk (dasd), without LVM. The
applications and their data are on LVM managed PVs, LVs, FSs.)

2) The upgrade was very slow and struggle. (The Linux system was useable
after 3 reboot, and there was many device(dasd)/lvm/FS error.)
In the SLES12 I saw many simlar errror messages:
WARNING: Device for PV x5zvM9-l42o-ifVM-zMWC-NgT5-dZ8G-afApuY not found or
rejected by a filter.
...
Couldn't find device with uuid x5zvM9-l42o-ifVM-zMWC-NgT5-dZ8G-afApuY
...
   There are 24 physical volumes missing.
WARNING: Couldn't find all devices for LV vg0/db2db_db2bmtg0_db2actlog
while checking used and assumed devices.
...

3 ) Many error message came from the old, and unused and corrupt VG (vg0)
and its LVs, and PVs, so I deleted these (the PVs, LVs of vg0).
   After a new reboot, disappeared every error messages (in SLES 12 SP4,
after upgrade).

4 ) At this time, I have checked every filesystem (~80, with fsck), and
every filesystem was good.

5 ) I updated the metadata of LVM ( to lvmetad).

6 ) I performed more (~10) boot on this Linux system to test, and I saw
similar error messages during every boot:
[FAILED] Failed to start LVM2 PV scan on device 94:617.
See 'systemctl status lvm2-pvscan@94:617.service' for details.
[FAILED] Failed to start LVM2 PV scan on device 94:517.
See 'systemctl status lvm2-pvscan@94:517.service' for details.
[FAILED] Failed to start LVM2 PV scan on device 94:473.
See 'systemctl status lvm2-pvscan@94:473.service' for details.
But the PVs, LVs, FSs (FileSystems) were good (without error messages) in
beginning.

7 ) Aftet some reboot, I saw same error messages a

unstable LVM on SLES 12

[Csaba Polgar]

Hello,

In the past, there was an attempt to upgrade a Linux system from SLES11 SP4
to SLES 12 SP4, but it was not successful because of the missing disks
after OS upgrade.
We saw the below error messages in the SLES11 SP4:

hostname:~ # lvs | grep "Attr\|ao--p"
  LV  VG   Attr
LSize   Pool Origin Data%  Move Log Copy%  Convert
  db2db_db2bmtg0_db2data  vg0
-wi-ao--p  60.00g
  db2db_db2bmtg0_db2dump  vg0
-wi-ao--p   2.00g
  is_appname   vg0
-wi-ao--p 700.00g
  is_appname_mclm  vg0
-wi-ao--p  44.25g
  is_appname_tss-mzvg0
-wi-ao--p 250.00g
  opt_IBM_wstemp  vg0
-wi-ao--p  65.00g
hostname:~ #

Please see the last see Attribute, which is "p". It means (see manual
pages):   (p)artial: One or more of the Physical Volumes this Logical
Volume uses is missing from the system.

We thought, that the permanent solution is the migration every data (~80
FileSystem) to a new Volume Group (from the vg0 to vg1). It was performed.
  The old and faulty VG (=Volume Group) (vg0) was not deleted with its LVs
(Logical Volume) and PVs (Physical Volume), but these were NOT used or
mounted.
  After it, the error messages disappeared on the SLES11 from the used
disks (PVs, LVs also). This was the staus till the new attempt of Linux
upgrade.

1 ) After it (on the last week), I started the OS upgrade again. I created
a full backup about the Linux OS (SLES 11) to a new disk before the
upgrade.
(The Linux itself is only on a pure 1 disk (dasd), without LVM. The
applications and their data are on LVM managed PVs, LVs, FSs.)

2) The upgrade was very slow and struggle. (The Linux system was useable
after 3 reboot, and there was many device(dasd)/lvm/FS error.)
In the SLES12 I saw many simlar errror messages:
WARNING: Device for PV x5zvM9-l42o-ifVM-zMWC-NgT5-dZ8G-afApuY not found or
rejected by a filter.
...
Couldn't find device with uuid x5zvM9-l42o-ifVM-zMWC-NgT5-dZ8G-afApuY
...
  There are 24 physical volumes missing.
WARNING: Couldn't find all devices for LV vg0/db2db_db2bmtg0_db2actlog
while checking used and assumed devices.
...

3 ) Many error message came from the old, and unused and corrupt VG (vg0)
and its LVs, and PVs, so I deleted these (the PVs, LVs of vg0).
  After a new reboot, disappeared every error messages (in SLES 12 SP4,
after upgrade).

4 ) At this time, I have checked every filesystem (~80, with fsck), and
every filesystem was good.

5 ) I updated the metadata of LVM ( to lvmetad).

6 ) I performed more (~10) boot on this Linux system to test, and I saw
similar error messages during every boot:
[FAILED] Failed to start LVM2 PV scan on device 94:617.
See 'systemctl status lvm2-pvscan@94:617.service' for details.
[FAILED] Failed to start LVM2 PV scan on device 94:517.
See 'systemctl status lvm2-pvscan@94:517.service' for details.
[FAILED] Failed to start LVM2 PV scan on device 94:473.
See 'systemctl status lvm2-pvscan@94:473.service' for details.
But the PVs, LVs, FSs (FileSystems) were good (without error messages) in
beginning.

7 ) Aftet some reboot, I saw same error messages about the new VG (vg1)
than above (in step 2) about the old and faulty VG (vg0)!;
It means, that one or more of the Physical Volumes is missing from the
Linux system, from the new VG.
My summary was at this point; The situation is better than it was at the
first upgrade attempt, but LVM is still unstable on SLES12, so file systems
are available or not (it is changing after every boot, from good to faulty
and back). The LVM database appears to be permanently corrupted.

8 ) I created the backup about the faulty SLES12 to a new disk, but the
Linux system has been restored to SLES 11 SP4, which provide stable LVs,
FSs so the system is useable.

  As we saw, the SLES12 is more sensitive to the errors than the SLES11, so
the filesystems errors may came up easier on SLES12.
But the customer is very impatient, because of they want to get a stable,
well working SLES 12.

Could somebody please say me, what should be fixed to get a stable PVs,
LVs, FSs on SLES 12?

Regards,

Csaba Polgar

--
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: NSS not possible in SLES 12

[Paul Flint]

Greetings,

Time to disambiguate

I thought this was about Network Security Services...

See:

https://en.wikipedia.org/wiki/NSSs://en.wikipedia.org/wiki/NSS

Regards,

Flint

On Wed, 4 Sep 2019, Dave Jones wrote:


Date: Wed, 4 Sep 2019 12:30:39 -0700
From: Dave Jones 
Reply-To: Linux on 390 Port 
To: LINUX-390@VM.MARIST.EDU
Subject: Re: NSS not possible in SLES 12

++1
You guys are going backwards
DJ

---
DAVID JONES | MANAGING DIRECTOR FOR ZSYSTEMS SERVICES | z/VM, Linux, and
Cloud
703.237.7370 (Office) | 281.578.7544 (CELL)

INFORMATION TECHNOLOGY COMPANY

On 09.04.2019 12:03 PM, Rick Troth wrote:

On 9/4/19 11:39 AM, Christian Borntraeger wrote:

On 04.09.19 16:41, Scott Rohling wrote:

Let's start with who or what said it wasn't possible ?

[...]

Just to be sure, by "nss" I meant Named Saved System.

[...]
what is the reason for nss not being possible with SLES from version 
12?

[...]

The Linux kernel now makes use of self-patching in several places and 
several core
features would no longer work without those.  To make NSS possible, the 
NSS would
need to have a copy-on-write semantics instead of being read-only. With 
global patching

we would copy almost everything over time making the feature not useful.

So the feature was not only removed in SLES but will go away in other 
future distros

and it is no longer part of the upstream kernel.



What's this? a little uptime funk? That's cool as long as it _doesn't
break other things_.   

Seriously? You whacked NSS for live patching? Don't! (Too late.)
https://www.youtube.com/watch?v=SYRlTISvjww    


Bad enough all the PUTTERING around in userland, even INIT, but now the
kernel's borken too. Babies and bath-water both banished. Bummer!


Hey, hey, hey, HAY ... Stop! ... wait a minute ... I'm a fan of advances
(hallelujah!), but not at the cost of flexibility.

I believe y'all killed XIP too, right? That was brilliant. (NOT)


Not all the world's containers (or whatever shiny thing). Don't believe
me? Just watch: I'll introduce you to a container escaper and kubernetes
breaker.


-- R; <><







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


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



Kindest Regards,



☮ Paul Flint
(802) 479-2360 Home
(802) 595-9365 Cell

/
Based upon email reliability concerns,
please send an acknowledgement in response to this note.

Paul Flint
17 Averill Street
Barre, VT
05641

--
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: NSS not possible in SLES 12

[Alan Altmark]

On Thursday, 09/05/2019 at 06:35 GMT, Scott Rohling 
 wrote:
> I think the implications extend beyond NSS though...   is SLES going to
> divorce itself from embedded systems in general?   Are they all in on 
self
> patching kernels and that's that?   Or can it simply be an option to
> exploit when desirable?

As you say, a more general question, perhaps for LKML.  Not really 
relevant to Z in any case.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
IBM Z Delivery Practice
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott


--
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: NSS not possible in SLES 12

[Mark Post]

On 9/5/19 2:35 PM, Scott Rohling wrote:
> I think the implications extend beyond NSS though...   is SLES going to
> divorce itself from embedded systems in general?   Are they all in on self
> patching kernels and that's that?   Or can it simply be an option to
> exploit when desirable?

I don't see how any of this relates to SUSE in particular, or embedded
systems in general. If you think Linus and his fellow developers are
writing off the entire embedded market, I have to believe you're wrong.
(Although I'm willing to accept that it is possible they are doing just
that, and I'm wrong.)

As Christian said, this isn't about live kernel patching, it's about the
kernel doing things internally.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: NSS not possible in SLES 12

[Scott Rohling]

I think the implications extend beyond NSS though...   is SLES going to
divorce itself from embedded systems in general?   Are they all in on self
patching kernels and that's that?   Or can it simply be an option to
exploit when desirable?

Scott Rohling

On Thu, Sep 5, 2019 at 9:57 AM Alan Altmark  wrote:

> On Wednesday, 09/04/2019 at 08:16 GMT, Dave Jones 
> wrote:
> > ++1
> > You guys are going backwards
>
> I haven't seen much traction with the NSS in the field.  Within an
> organization, Linux servers are maintained in a common way across
> platforms, with different servers on different schedules.  NSS messes with
> that concept, for good or ill, and trying to interfere with SOP just
> annoys people.
>
> But I look at it this way, NSSes and DCSSes were a means to an end:
> Conservation of memory.  It was especially important when memory was so
> expensive and sysprogs were a dime a dozen.  (Remember moving the DCSSes
> around for various product so they would all fit?)
>
> The economics have changed.  Setting up an NSS is still easy (once you
> know how!), but trying to persuade busy Linux admins to exploit it and
> change their patching strategies to match is time neither of us have to
> spare.
>
> I'd rather see de-duplication strategies that accomplish the same thing
> with minimal, if any, human involvement.
>
> Alan Altmark
>
> Senior Managing z/VM and Linux Consultant
> IBM Systems Lab Services
> IBM Z Delivery Practice
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
>
>
> --
> 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
>

--
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: NSS not possible in SLES 12

[Marcy Cortes]

I agree 100%.  We decided it was too hard with all the frequent updates of the 
kernel.   Memory is cheaper than it used to be.  I'm not sad to see this go so 
other more important things can take place.  

-Original Message-
From: Linux on 390 Port  On Behalf Of Alan Altmark
Sent: Thursday, September 5, 2019 9:51 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] NSS not possible in SLES 12

On Wednesday, 09/04/2019 at 08:16 GMT, Dave Jones  
wrote:
> ++1
> You guys are going backwards

I haven't seen much traction with the NSS in the field.  Within an 
organization, Linux servers are maintained in a common way across 
platforms, with different servers on different schedules.  NSS messes with 
that concept, for good or ill, and trying to interfere with SOP just 
annoys people.

But I look at it this way, NSSes and DCSSes were a means to an end: 
Conservation of memory.  It was especially important when memory was so 
expensive and sysprogs were a dime a dozen.  (Remember moving the DCSSes 
around for various product so they would all fit?)

The economics have changed.  Setting up an NSS is still easy (once you 
know how!), but trying to persuade busy Linux admins to exploit it and 
change their patching strategies to match is time neither of us have to 
spare.

I'd rather see de-duplication strategies that accomplish the same thing 
with minimal, if any, human involvement.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
IBM Z Delivery Practice
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott


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

--
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: NSS not possible in SLES 12

[Alan Altmark]

On Wednesday, 09/04/2019 at 08:16 GMT, Dave Jones  
wrote:
> ++1
> You guys are going backwards

I haven't seen much traction with the NSS in the field.  Within an 
organization, Linux servers are maintained in a common way across 
platforms, with different servers on different schedules.  NSS messes with 
that concept, for good or ill, and trying to interfere with SOP just 
annoys people.

But I look at it this way, NSSes and DCSSes were a means to an end: 
Conservation of memory.  It was especially important when memory was so 
expensive and sysprogs were a dime a dozen.  (Remember moving the DCSSes 
around for various product so they would all fit?)

The economics have changed.  Setting up an NSS is still easy (once you 
know how!), but trying to persuade busy Linux admins to exploit it and 
change their patching strategies to match is time neither of us have to 
spare.

I'd rather see de-duplication strategies that accomplish the same thing 
with minimal, if any, human involvement.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
IBM Z Delivery Practice
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott


--
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: NSS not possible in SLES 12

[David Boyes]

I’m really curious how the embedded systems folks took this latest 
“improvement”. 

By this argument, Intel and ARM systems running from EPROM are no longer 
viable, or at least will require a forklift upgrade - are they expecting to 
always copy the entire kernel into RAM and allow it to modify itself? There’s 
an awful lot of avionics and industrial controls/IoT hardware deployed out 
there that will stop getting updates because it flat out doesn’t have enough 
onboard RAM to support this approach, and that’s the last thing we need: more 
systems we can’t fix when some other dumb error happens. It also opens up an 
entirely new class of exploits possible by interfering with the running kernel 
image or the transfer of the image to RAM. 

This whole approach seems poorly thought out at best, but I guess that is the 
norm for Linux these days. A little Linus vitriol of old seems in order, IMHO. 


 

--
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: NSS not possible in SLES 12

[Christian Borntraeger]

On 04.09.19 21:03, Rick Troth wrote:
> On 9/4/19 11:39 AM, Christian Borntraeger wrote:
>> On 04.09.19 16:41, Scott Rohling wrote:
>>> Let's start with who or what said it wasn't possible ?
>> [...]
 Just to be sure, by "nss" I meant Named Saved System.
>> [...]
> what is the reason for nss not being possible with SLES from version 12?
>> [...]
>>
>> The Linux kernel now makes use of self-patching in several places and 
>> several core
>> features would no longer work without those.  To make NSS possible, the NSS 
>> would
>> need to have a copy-on-write semantics instead of being read-only. With 
>> global patching
>> we would copy almost everything over time making the feature not useful.
>>
>> So the feature was not only removed in SLES but will go away in other future 
>> distros
>> and it is no longer part of the upstream kernel.
> 
> 
> What's this? a little uptime funk? That's cool as long as it _doesn't
> break other things_.   
> 
> Seriously? You whacked NSS for live patching? Don't! (Too late.)  

Sorry I was not clear enough. 
This is NOT about the live patching in terms of updating your kernel. 

This is about changing the code of the Linux kernel during runtime for several
things like disabling trace points, applying CPU alternatives and choosing
security related instructions. Not having life patching for some of these things
would severely harm the overall performance as this would add additional 
branches
in too many places (e.g. every C function in the kernel) or even in places that
are not usable for a branch.
EVERYBODY (power,x86,arm,...)  now does live patching for these things that can
be dynamically enabled/disabled for a good reason and not doing so would prevent
us from using a big pile of these "smallish" features that will sum up over 
time.

 
> https://www.youtube.com/watch?v=SYRlTISvjww    
> 
> 
> Bad enough all the PUTTERING around in userland, even INIT, but now the
> kernel's borken too. Babies and bath-water both banished. Bummer!
> 
> 
> Hey, hey, hey, HAY ... Stop! ... wait a minute ... I'm a fan of advances
> (hallelujah!), but not at the cost of flexibility.
> 
> I believe y'all killed XIP too, right? That was brilliant. (NOT)

this is now called dax (direct access) and it still part of the dcssblk
device driver. I have not tested that recently though, so I can not say
that this still works but we have not removed that. 

--
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: NSS not possible in SLES 12

[Hamilton, Robert]

++1 2.

I would like to have an operating system that I can boot or reboot on multiple 
servers and know that it's going to be consistent. If there needs to be a 
patch, I really don't want to have that happen in real time; I'd much rather 
have a set of patches that I can stage before applying, which would then let me 
define or create a new, consistent operating system to which I can upgrade my 
servers. We have a policy that patches or fixes have to go through some level 
of testing before they run on a production system. How does patching-on-the-fly 
satisfy any kind of change management? Is there no way to say that I don't want 
patching-on-the-fly for this particular server, or for these hundred servers? 
Is it not possible to stage updates?

R;


Rob Hamilton
Infrastructure Engineer
Chemical Abstracts Service

-Original Message-
From: Linux on 390 Port  On Behalf Of Dave Jones
Sent: Wednesday, September 4, 2019 3:31 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [EXT] Re: NSS not possible in SLES 12

[Actual Sender is owner-linux-...@vm.marist.edu]

++1
You guys are going backwards
DJ

---
DAVID JONES | MANAGING DIRECTOR FOR ZSYSTEMS SERVICES | z/VM, Linux, and
Cloud
703.237.7370 (Office) | 281.578.7544 (CELL)

INFORMATION TECHNOLOGY COMPANY

On 09.04.2019 12:03 PM, Rick Troth wrote:
> On 9/4/19 11:39 AM, Christian Borntraeger wrote:
>> On 04.09.19 16:41, Scott Rohling wrote:
>>> Let's start with who or what said it wasn't possible ?
>> [...]
>>>> Just to be sure, by "nss" I meant Named Saved System.
>> [...]
>>>>> what is the reason for nss not being possible with SLES from 
>>>>> version 12?
>> [...]
>> 
>> The Linux kernel now makes use of self-patching in several places and 
>> several core
>> features would no longer work without those.  To make NSS possible, 
>> the NSS would
>> need to have a copy-on-write semantics instead of being read-only. 
>> With global patching
>> we would copy almost everything over time making the feature not 
>> useful.
>> 
>> So the feature was not only removed in SLES but will go away in other 
>> future distros
>> and it is no longer part of the upstream kernel.
> 
> 
> What's this? a little uptime funk? That's cool as long as it _doesn't
> break other things_.   
> 
> Seriously? You whacked NSS for live patching? Don't! (Too late.)
> https://www.youtube.com/watch?v=SYRlTISvjww    
> 
> 
> Bad enough all the PUTTERING around in userland, even INIT, but now the
> kernel's borken too. Babies and bath-water both banished. Bummer!
> 
> 
> Hey, hey, hey, HAY ... Stop! ... wait a minute ... I'm a fan of 
> advances
> (hallelujah!), but not at the cost of flexibility.
> 
> I believe y'all killed XIP too, right? That was brilliant. (NOT)
> 
> 
> Not all the world's containers (or whatever shiny thing). Don't believe
> me? Just watch: I'll introduce you to a container escaper and 
> kubernetes
> breaker.
> 
> 
> -- R; <><
> 
> 
> 
> 
> 
> 
> 
> --
> 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

--
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
Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from CAS, a division of the American Chemical Society ("ACS"). If you have 
received this transmission in error, be advised that any disclosure, copying, 
distribution, or use of the contents of this information is strictly 
prohibited. Please destroy all copies of the message and contact the sender 
immediately by either replying to this message or calling 614-447-3600.


--
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: NSS not possible in SLES 12

[Dave Jones]

++1
You guys are going backwards
DJ

---
DAVID JONES | MANAGING DIRECTOR FOR ZSYSTEMS SERVICES | z/VM, Linux, and
Cloud
703.237.7370 (Office) | 281.578.7544 (CELL)

INFORMATION TECHNOLOGY COMPANY

On 09.04.2019 12:03 PM, Rick Troth wrote:

On 9/4/19 11:39 AM, Christian Borntraeger wrote:

On 04.09.19 16:41, Scott Rohling wrote:

Let's start with who or what said it wasn't possible ?

[...]

Just to be sure, by "nss" I meant Named Saved System.

[...]
what is the reason for nss not being possible with SLES from 
version 12?

[...]

The Linux kernel now makes use of self-patching in several places and 
several core
features would no longer work without those.  To make NSS possible, 
the NSS would
need to have a copy-on-write semantics instead of being read-only. 
With global patching
we would copy almost everything over time making the feature not 
useful.


So the feature was not only removed in SLES but will go away in other 
future distros

and it is no longer part of the upstream kernel.



What's this? a little uptime funk? That's cool as long as it _doesn't
break other things_.   

Seriously? You whacked NSS for live patching? Don't! (Too late.)
https://www.youtube.com/watch?v=SYRlTISvjww    


Bad enough all the PUTTERING around in userland, even INIT, but now the
kernel's borken too. Babies and bath-water both banished. Bummer!


Hey, hey, hey, HAY ... Stop! ... wait a minute ... I'm a fan of 
advances

(hallelujah!), but not at the cost of flexibility.

I believe y'all killed XIP too, right? That was brilliant. (NOT)


Not all the world's containers (or whatever shiny thing). Don't believe
me? Just watch: I'll introduce you to a container escaper and 
kubernetes

breaker.


-- R; <><







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


--
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: NSS not possible in SLES 12

[Rick Troth]

On 9/4/19 11:39 AM, Christian Borntraeger wrote:
> On 04.09.19 16:41, Scott Rohling wrote:
>> Let's start with who or what said it wasn't possible ?
> [...]
>>> Just to be sure, by "nss" I meant Named Saved System.
> [...]
 what is the reason for nss not being possible with SLES from version 12?
> [...]
>
> The Linux kernel now makes use of self-patching in several places and several 
> core
> features would no longer work without those.  To make NSS possible, the NSS 
> would
> need to have a copy-on-write semantics instead of being read-only. With 
> global patching
> we would copy almost everything over time making the feature not useful.
>
> So the feature was not only removed in SLES but will go away in other future 
> distros
> and it is no longer part of the upstream kernel.


What's this? a little uptime funk? That's cool as long as it _doesn't
break other things_.   

Seriously? You whacked NSS for live patching? Don't! (Too late.)
https://www.youtube.com/watch?v=SYRlTISvjww    


Bad enough all the PUTTERING around in userland, even INIT, but now the
kernel's borken too. Babies and bath-water both banished. Bummer!


Hey, hey, hey, HAY ... Stop! ... wait a minute ... I'm a fan of advances
(hallelujah!), but not at the cost of flexibility.

I believe y'all killed XIP too, right? That was brilliant. (NOT)


Not all the world's containers (or whatever shiny thing). Don't believe
me? Just watch: I'll introduce you to a container escaper and kubernetes
breaker.


-- R; <><







--
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: NSS not possible in SLES 12

[Christian Borntraeger]

On 04.09.19 16:41, Scott Rohling wrote:
> Let's start with who or what said it wasn't possible ?
[...]
>> Just to be sure, by "nss" I meant Named Saved System.
[...]
>>> what is the reason for nss not being possible with SLES from version 12?
[...]

The Linux kernel now makes use of self-patching in several places and several 
core
features would no longer work without those.  To make NSS possible, the NSS 
would
need to have a copy-on-write semantics instead of being read-only. With global 
patching
we would copy almost everything over time making the feature not useful.

So the feature was not only removed in SLES but will go away in other future 
distros
and it is no longer part of the upstream kernel.

Christian

--
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: NSS not possible in SLES 12

[Andras Beke]

On the one hand on the following page at "nss" parameter the Note states
it:
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_chreipl_cmd.html

On the other hand in the following document in Chapter 5. page 64 under
"Attributes for nss" subheading the last paragraph states the same.
https://public.dhe.ibm.com/software/dw/linux390/docu/lhs4dd06.pdf

Neither of these documents give any explanation or background information
and seemingly some other Linux distributions support nss feature so I've
got curious too how hard this limitation may be.


Regards,

András BEKE




From:   Scott Rohling 
To: LINUX-390@VM.MARIST.EDU
Date:   04/09/2019 16:42
Subject:[EXTERNAL] Re: NSS not possible in SLES 12
Sent by:Linux on 390 Port 



Let's start with who or what said it wasn't possible ?

In my experience - most things are possible ... though there maybe
roadblocks.

Scott Rohling



On Wed, Sep 4, 2019 at 5:51 AM Andras Beke  wrote:

> Just to be sure, by "nss" I meant Named Saved System.
>
> Regards,
>
> András BEKE
>
>
> > Dear List,
> >
> > apologies if I'm asking something evident, the reason being I'm a
newbie
> > both on the list and in the speciality, but does any of you happen to
> know
> > what is the reason for nss not being possible with SLES from version
12?
> >
> > Thank you in advance.
> >
> > Regards,
> >
> > András BEKE
> >
> > --
> > 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__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=UQeM-z3sk_TvI2AmyquhsQfNcz24Eo-BLBth57Mf7Kc=qWChJN9xw3kK98SHqgCCaHQ5fY7xhIubh7_0L_Pj4Jk=3928csH9TtaCaTJm3_IIemQ4aGg1sI6HC1RrOcQBYfQ=

> >
>
> --
> 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__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=UQeM-z3sk_TvI2AmyquhsQfNcz24Eo-BLBth57Mf7Kc=qWChJN9xw3kK98SHqgCCaHQ5fY7xhIubh7_0L_Pj4Jk=3928csH9TtaCaTJm3_IIemQ4aGg1sI6HC1RrOcQBYfQ=

>

--
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__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=UQeM-z3sk_TvI2AmyquhsQfNcz24Eo-BLBth57Mf7Kc=qWChJN9xw3kK98SHqgCCaHQ5fY7xhIubh7_0L_Pj4Jk=3928csH9TtaCaTJm3_IIemQ4aGg1sI6HC1RrOcQBYfQ=




--
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: NSS not possible in SLES 12

[Scott Rohling]

Let's start with who or what said it wasn't possible ?

In my experience - most things are possible ... though there maybe
roadblocks.

Scott Rohling



On Wed, Sep 4, 2019 at 5:51 AM Andras Beke  wrote:

> Just to be sure, by "nss" I meant Named Saved System.
>
> Regards,
>
> András BEKE
>
>
> > Dear List,
> >
> > apologies if I'm asking something evident, the reason being I'm a newbie
> > both on the list and in the speciality, but does any of you happen to
> know
> > what is the reason for nss not being possible with SLES from version 12?
> >
> > Thank you in advance.
> >
> > Regards,
> >
> > András BEKE
> >
> > --
> > 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
> >
>
> --
> 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
>

--
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: NSS not possible in SLES 12

[Andras Beke]

Just to be sure, by "nss" I meant Named Saved System.

Regards,

András BEKE


> Dear List,
>
> apologies if I'm asking something evident, the reason being I'm a newbie
> both on the list and in the speciality, but does any of you happen to
know
> what is the reason for nss not being possible with SLES from version 12?
>
> Thank you in advance.
>
> Regards,
>
> András BEKE
>
> --
> 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
>

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

NSS not possible in SLES 12

[Andras Beke]

Dear List,

apologies if I'm asking something evident, the reason being I'm a newbie
both on the list and in the speciality, but does any of you happen to know
what is the reason for nss not being possible with SLES from version 12?

Thank you in advance.

Regards,

András BEKE

--
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: iucvconn setup on SLES 12

[Will, Chris]

Still having issues.  I have upgraded both the terminal server and test guest 
to SLES 12 SP4 which gives a s390tools version of 2.1 or so.  Our requirements 
are to be able to view the console log during shutdown and startup since we no 
longer have access to a 3270 console or HMC.  If you have this working what are 
your grub parms or terminal server setup.  For the terminal server, the only 
changes I made are to define the guests to be monitored and a password.  I can 
get to the logon prompt or emergency repair prompt but the console display 
keeps disconnecting with only a few messages displayed.  Here is /proc/cmdline

root=UUID=ad5a0c5a-1372-474b-97a6-a07ba754a36a hvc_iucv=2 showopts TERM=dumb 
crashkernel=102M console=ttyS0 console=hvc0

Do these look correct?  Anyone using something different that works?

Chris Will




From: Linux on 390 Port  on behalf of Mark Post 

Sent: Wednesday, June 5, 2019 4:48 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: iucvconn setup on SLES 12

ALERT This email was sent from a source external to BCBSM/BCN.
 DO NOT CLICK links or attachments unless you recognize the sender and trust 
the content.


On 5/30/19 1:15 PM, Will, Chris wrote:
> I have this sort of working.  It will display a few messages and then close 
> the connection.  I connect again and it will display a few messages, close, 
> etc.
-snip-
> # ssh nbxdv392@slxmfdev3
> Password:
> Last login: Thu May 30 11:45:26 2019 from 10.96.1.149
> This is a private system.  Unauthorized use is prohibited.
> iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0)
>
> iucvconn: Connecting to the z/VM guest virtual machine failed: Connection 
> refused
> Connection to slxmfdev3 closed.
> (root@slxmfdev3:~)

There are a number of things that might be going here, but it's hard to
tell. One thing is that the cookbook shows "ssh -t" and not just "ssh".
The -t forces allocation of a pseudo-terminal, which might be necessary
here.

I looked back through my old emails, and the problem that I vaguely
remembered was from SLES11, and a kernel change was needed to fix it.
I'm pretty certain that's not the problem you're experiencing. ;)


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://www2.marist.edu/htbin/wlvindex?LINUX-390


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.

--
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: Devices for dracut in sles 12 SP4

[Marcy Cortes]

on its way.  hopefully openable! thank you!

-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Tuesday, June 11, 2019 10:09 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Devices for dracut in sles 12 SP4

On 6/11/19 1:05 PM, Marcy Cortes wrote:
> If you can't, I can email you a copy.

Please, do.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

--
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: Devices for dracut in sles 12 SP4

[Mark Post]

On 6/11/19 1:05 PM, Marcy Cortes wrote:
> If you can't, I can email you a copy.

Please, do.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Devices for dracut in sles 12 SP4

[Marcy Cortes]

Maybe its not the cio-ignore stuff. 
I just posted the whole long rescue/dracut console to the ticket.
Can you look at it ?  If you can't, I can email you a copy.



-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Tuesday, June 11, 2019 8:24 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Devices for dracut in sles 12 SP4

On 6/10/19 3:52 PM, Marcy Cortes wrote:
> Does anyone know how dracut is really supposed to be told about devices? I 
> was under the impression that all devices were allowed unless explicity in a 
> cio_ignore when running under z/VM.

That's been the default for new installations on z/VM for a while now.
However, if a system was upgraded from a version prior to that, the
cio_ignore parameter will still be in your kernel parameters, and can
cause problems like this. (Or, if someone chose to activate device
blacklisting during a new install.)

Check /proc/cmdline to see if it's there. If it is, remove it from
/boot/grub2/grub.cfg, and /etc/default/grub so that the next time you
reboot things should be more reasonable.

> At least that's the impression I get reading this 
> https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_cio_ignore_cmd.html

I'm not sure why you would get that impression from that page. The only
references I see to z/VM on that page relate to adding devices to the
cio_ignore list after booting, and what happens if that device is
detached and later re-attached.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

--
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: Devices for dracut in sles 12 SP4

[Mark Post]

On 6/11/19 11:51 AM, Cohen, Sam wrote:
> I'm going to ask a religious questionif you're running under z/VM and 
> (ideally) giving the virtual machine only what it needs, why would you use 
> cio_ignore at all?

That's exactly why Ihno and I successfully lobbied to get the default
changed for not just z/VM, but KVM as well.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Devices for dracut in sles 12 SP4

[Cohen, Sam]

I'm going to ask a religious questionif you're running under z/VM and 
(ideally) giving the virtual machine only what it needs, why would you use 
cio_ignore at all?  

Thanks,

Sam
(217) 862-9227 (office)
(602) 327-2134 (cell)

-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Tuesday, June 11, 2019 8:24 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Devices for dracut in sles 12 SP4

On 6/10/19 3:52 PM, Marcy Cortes wrote:
> Does anyone know how dracut is really supposed to be told about devices? I 
> was under the impression that all devices were allowed unless explicity in a 
> cio_ignore when running under z/VM.

That's been the default for new installations on z/VM for a while now.
However, if a system was upgraded from a version prior to that, the cio_ignore 
parameter will still be in your kernel parameters, and can cause problems like 
this. (Or, if someone chose to activate device blacklisting during a new 
install.)

Check /proc/cmdline to see if it's there. If it is, remove it from 
/boot/grub2/grub.cfg, and /etc/default/grub so that the next time you reboot 
things should be more reasonable.

> At least that's the impression I get reading this 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2Flinuxonibm%2Fcom.ibm.linux.
> z.lhdd%2Flhdd_r_cio_ignore_cmd.htmldata=02%7C01%7CSam.Cohen%40LRS
> .COM%7C0a41595b36dc47ae1fa908d6ee813b90%7C62af9ccc42164ae2a1d306614c59
> c315%7C0%7C0%7C636958636152651551sdata=WvsnQZwpFYclPqprameZpTTDW8
> vaet45KuaGohzP31E%3Dreserved=0

I'm not sure why you would get that impression from that page. The only 
references I see to z/VM on that page relate to adding devices to the 
cio_ignore list after booting, and what happens if that device is detached and 
later re-attached.


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
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390data=02%7C01%7CSam.Cohen%40LRS.COM%7C0a41595b36dc47ae1fa908d6ee813b90%7C62af9ccc42164ae2a1d306614c59c315%7C0%7C0%7C636958636152661546sdata=EcmxBcaJl2MmxcM1DJXS%2FtGH5d9XvGC4y5WDA4lcbmI%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

Re: Devices for dracut in sles 12 SP4

[Mark Post]

On 6/10/19 3:52 PM, Marcy Cortes wrote:
> Does anyone know how dracut is really supposed to be told about devices? I 
> was under the impression that all devices were allowed unless explicity in a 
> cio_ignore when running under z/VM.

That's been the default for new installations on z/VM for a while now.
However, if a system was upgraded from a version prior to that, the
cio_ignore parameter will still be in your kernel parameters, and can
cause problems like this. (Or, if someone chose to activate device
blacklisting during a new install.)

Check /proc/cmdline to see if it's there. If it is, remove it from
/boot/grub2/grub.cfg, and /etc/default/grub so that the next time you
reboot things should be more reasonable.

> At least that's the impression I get reading this 
> https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_cio_ignore_cmd.html

I'm not sure why you would get that impression from that page. The only
references I see to z/VM on that page relate to adding devices to the
cio_ignore list after booting, and what happens if that device is
detached and later re-attached.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Devices for dracut in sles 12 SP4

[Marcy Cortes]

Resending from other ID – maybe have been blocked for many (like me!)

--

 

After some patching this weekend, we had a few servers go into dracut emergency 
mode.

After a lot of pain and rescue system work,  we found it didn't know about a 
couple of the devices in the VG group that housed some needed stuff.   We found 
this in the dracut /run/initram/rdsosreport.txt you can get in the emergency 
shell.

 

So looking, the missing ones seemed to not be in the rd.cio_accept line in 
there.

Brought the rescue system back up and eventually figured out that those seem to 
be coming out of /boot/zipl/active_devices.txt

That seems to be updated when dasd_configure is run (or now chzdev -e - see 
previous email thread)

I then ran that for each of the devices needed and then ran grub2-install and 
that got me past the missing devices problem.

 

I then ran into dracut choking on the VG with these messages

Read-only locking type set. Write locks are prohibited.

   Recovery of volume group "system" failed.

   Cannot process volume group system

 

I solved that by bringing the rescue system back up and running vgscan and it 
reported:

 

>> 19:14:44   WARNING: Inconsistent metadata found for VG system - updating to 
>> use

 

>> version 23

 

So today I go looking at more servers and pretty much all of them don't have 
all the devices in active_devices.txt nor in rd.cio_accept as evidenced by the 
/var/log/zypp/history.

Hmm.  So maybe if I run grub2-install on one of them I can recreate the fail?   
Nope.  Came up just fine.

 

We have a case open with SUSE who has taken it to their level 3.

But I'm left with so many questions here...

Our builds are based on cloning and so I'm worried that this will strike more 
servers.

 

SP4 now writes udev rules differently in /etc/udev/rules.d/   They start with 
41 now for new disks.  The SP3 and earlier generated ones start with 51.

 

myserver:/etc/udev/rules.d # l

total 64

drwxr-xr-x 2 root root 4096 Jun  8 19:04 ./

drwxr-xr-x 3 root root 4096 Jun  9 00:10 ../

-rw-r--r-- 1 root root  139 Jun  5 17:43 41-cio-ignore.rules

-rw-r--r-- 1 root root  396 Jun  5 17:43 41-dasd-eckd-0.0.800f.rules

-rw-r--r-- 1 root root  347 Aug 12  2016 51-dasd-0.0.0101.rules

-rw-r--r-- 1 root root  347 Aug 12  2016 51-dasd-0.0.0102.rules

-rw-r--r-- 1 root root  347 Aug 12  2016 51-dasd-0.0.0103.rules

-rw-r--r-- 1 root root  347 Aug 12  2016 51-dasd-0.0.0104.rules

-rw-r--r-- 1 root root  347 Sep  8  2016 51-dasd-0.0.8000.rules

-rw-r--r-- 1 root root  536 Dec 15  2016 51-dasd-0.0.ff00.rules

-rw-r--r-- 1 root root  536 Dec 15  2016 51-dasd-0.0.ff01.rules

-rw-r--r-- 1 root root  536 Dec 15  2016 51-dasd-0.0.ff02.rules

-rw-r--r-- 1 root root  538 Dec 15  2016 51-dasd-0.0.ff03.rules

-rw-r--r-- 1 root root 1661 Aug 12  2016 51-qeth-0.0.3000.rules

-rw-r--r-- 1 root root 1661 Aug 12  2016 51-qeth-0.0.4000.rules

-rw-r--r-- 1 root root  594 Jun  8 19:04 70-persistent-net.rules

 

There is also a new 41-cio-ignore.rules that looks like this

# Generated by chzdev

ACTION=="add", SUBSYSTEM=="subsystem", KERNEL=="ccw", RUN{program}+="/bin/sh -c 
'echo free 800f > /proc/cio_ignore'"

 

Does anyone know how dracut is really supposed to be told about devices? I was 
under the impression that all devices were allowed unless explicity in a 
cio_ignore when running under z/VM.

At least that's the impression I get reading this 
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_cio_ignore_cmd.html

 

And what's up with LVM?  If it needed to upgrade itself, why didn't it prior to 
this point?  lvm2 was last patch a month ago.  Should it have done it then?  Or 
did it just become inconsistent when the devices decided to go AWOL?

 

 

Marcy

 

 


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

Devices for dracut in sles 12 SP4

[Marcy Cortes]

After some patching this weekend, we had a few servers go into dracut emergency 
mode.
After a lot of pain and rescue system work,  we found it didn't know about a 
couple of the devices in the VG group that housed some needed stuff.   We found 
this in the dracut /run/initram/rdsosreport.txt you can get in the emergency 
shell.

So looking, the missing ones seemed to not be in the rd.cio_accept line in 
there.
Brought the rescue system back up and eventually figured out that those seem to 
be coming out of /boot/zipl/active_devices.txt
That seems to be updated when dasd_configure is run (or now chzdev -e - see 
previous email thread)
I then ran that for each of the devices needed and then ran grub2-install and 
that got me past the missing devices problem.

I then ran into dracut choking on the VG with these messages
Read-only locking type set. Write locks are prohibited.
   Recovery of volume group "system" failed.
   Cannot process volume group system

I solved that by bringing the rescue system back up and running vgscan and it 
reported:

>> 19:14:44   WARNING: Inconsistent metadata found for VG system - updating to 
>> use

>> version 23

So today I go looking at more servers and pretty much all of them don't have 
all the devices in active_devices.txt nor in rd.cio_accept as evidenced by the 
/var/log/zypp/history.
Hmm.  So maybe if I run grub2-install on one of them I can recreate the fail?   
Nope.  Came up just fine.

We have a case open with SUSE who has taken it to their level 3.
But I'm left with so many questions here...
Our builds are based on cloning and so I'm worried that this will strike more 
servers.

SP4 now writes udev rules differently in /etc/udev/rules.d/   They start with 
41 now for new disks.  The SP3 and earlier generated ones start with 51.

myserver:/etc/udev/rules.d # l
total 64
drwxr-xr-x 2 root root 4096 Jun  8 19:04 ./
drwxr-xr-x 3 root root 4096 Jun  9 00:10 ../
-rw-r--r-- 1 root root  139 Jun  5 17:43 41-cio-ignore.rules
-rw-r--r-- 1 root root  396 Jun  5 17:43 41-dasd-eckd-0.0.800f.rules
-rw-r--r-- 1 root root  347 Aug 12  2016 51-dasd-0.0.0101.rules
-rw-r--r-- 1 root root  347 Aug 12  2016 51-dasd-0.0.0102.rules
-rw-r--r-- 1 root root  347 Aug 12  2016 51-dasd-0.0.0103.rules
-rw-r--r-- 1 root root  347 Aug 12  2016 51-dasd-0.0.0104.rules
-rw-r--r-- 1 root root  347 Sep  8  2016 51-dasd-0.0.8000.rules
-rw-r--r-- 1 root root  536 Dec 15  2016 51-dasd-0.0.ff00.rules
-rw-r--r-- 1 root root  536 Dec 15  2016 51-dasd-0.0.ff01.rules
-rw-r--r-- 1 root root  536 Dec 15  2016 51-dasd-0.0.ff02.rules
-rw-r--r-- 1 root root  538 Dec 15  2016 51-dasd-0.0.ff03.rules
-rw-r--r-- 1 root root 1661 Aug 12  2016 51-qeth-0.0.3000.rules
-rw-r--r-- 1 root root 1661 Aug 12  2016 51-qeth-0.0.4000.rules
-rw-r--r-- 1 root root  594 Jun  8 19:04 70-persistent-net.rules

There is also a new 41-cio-ignore.rules that looks like this
# Generated by chzdev
ACTION=="add", SUBSYSTEM=="subsystem", KERNEL=="ccw", RUN{program}+="/bin/sh -c 
'echo free 800f > /proc/cio_ignore'"

Does anyone know how dracut is really supposed to be told about devices? I was 
under the impression that all devices were allowed unless explicity in a 
cio_ignore when running under z/VM.
At least that's the impression I get reading this 
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_cio_ignore_cmd.html

And what's up with LVM?  If it needed to upgrade itself, why didn't it prior to 
this point?  lvm2 was last patch a month ago.  Should it have done it then?  Or 
did it just become inconsistent when the devices decided to go AWOL?


Marcy

This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


--
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: iucvconn setup on SLES 12

[Mark Post]

On 5/30/19 1:15 PM, Will, Chris wrote:
> I have this sort of working.  It will display a few messages and then close 
> the connection.  I connect again and it will display a few messages, close, 
> etc.
-snip-
> # ssh nbxdv392@slxmfdev3
> Password:
> Last login: Thu May 30 11:45:26 2019 from 10.96.1.149
> This is a private system.  Unauthorized use is prohibited.
> iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0)
>
> iucvconn: Connecting to the z/VM guest virtual machine failed: Connection 
> refused
> Connection to slxmfdev3 closed.
> (root@slxmfdev3:~)

There are a number of things that might be going here, but it's hard to
tell. One thing is that the cookbook shows "ssh -t" and not just "ssh".
The -t forces allocation of a pseudo-terminal, which might be necessary
here.

I looked back through my old emails, and the problem that I vaguely
remembered was from SLES11, and a kernel change was needed to fix it.
I'm pretty certain that's not the problem you're experiencing. ;)


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: dasd_configure in SLES 12 SP4

[Marcy Cortes]

Thanks for the explanation, Mark.
Easy enough for me to change the dasd_configure command in my scripts to chzdev 
so I will do that and not bother reporting that difference from SP3.

The problem with by-path not working is a little more problematic, so I've 
opened a SUSE ticket for that.



-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Friday, May 31, 2019 10:42 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] dasd_configure in SLES 12 SP4

On 5/31/19 6:47 AM, Michael MacIsaac wrote:
> Why?  Doing so will break scripts we have ...

Because they require maintenance, cause bug reports (such as Marcy's),
etc., etc. They're not going away tomorrow, but please plan ahead.

--
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: dasd_configure in SLES 12 SP4

[Michael MacIsaac]

Mark,

Thanks for a thorough reply.

We have been warned :))

-Mike M

On Fri, May 31, 2019 at 1:43 PM Mark Post  wrote:

> On 5/31/19 6:47 AM, Michael MacIsaac wrote:
> > Why?  Doing so will break scripts we have ...
>
> Because they require maintenance, cause bug reports (such as Marcy's),
> etc., etc. They're not going away tomorrow, but please plan ahead.
>
> One of the complaints we hear is that "doing X on SLES for the mainframe
> is different from how it's done on RHEL."  Red Hat hears the same, in
> reverse. SUSE and Red Hat both approached IBM to ask them to write and
> maintain a replacement set of tools for these sorts of scripts. That
> way, the tools to perform persistent and transient configuration will be
> the same across distributions. I haven't looked, but I'm guessing Ubuntu
> for the mainframe is using them as well.
>
> So, IBM came up the lszdev and chzdev utilities. To provide
> compatibility, I modified the existing *_configure scripts to use them
> instead of the previous logic. Moving forward, SUSE will be using the
> lszdev and chzdev commands in our own tools where the *_configure
> scripts have been used in the past. The linuxrc program to set up the
> installation environment is already doing that.
>
> The wrapper scripts were written solely as a means of translating the
> old semantics into the ones required by IBM's commands. The lszdev and
> chzdev commands provide a lot more functionality than the old
> *_configure scripts did. There will be no changes to the *_configure
> scripts unless there's a bug, or for some reason IBM changes the
> parameters their commands accept or require.
>
> If you set an environment variable of DEBUG to "yes", the *_configure
> scripts will display the chzdev command that gets executed, as well as
> actually executing it. Besides helping in debugging, this will allow
> anyone wishing to get ahead of the curve to see exactly what command
> needs to be executed to accomplish the same task as before.
>
> The old scripts will not be removed from the SLES12 product. At this
> point, we're not sure if they will be removed from future service pack
> levels of SLES15 or not. They almost certainly will not be part of the
> follow-on version after SLES15. (After what happened between SLES12 and
> SLES15, I'm not going to even try and outguess Product Management as to
> what name that's going to be.)
>
> Finally, this is Open Source Software. If you decide you're simply not
> going to move to the new commands from IBM, you're welcome to make and
> keep copies of the *_configure scripts for your own use, for ever and ever.
>
>
> 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://www2.marist.edu/htbin/wlvindex?LINUX-390
>


--
 -Mike MacIsaac

--
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: dasd_configure in SLES 12 SP4

[Mark Post]

On 5/31/19 6:47 AM, Michael MacIsaac wrote:
> Why?  Doing so will break scripts we have ...

Because they require maintenance, cause bug reports (such as Marcy's),
etc., etc. They're not going away tomorrow, but please plan ahead.

One of the complaints we hear is that "doing X on SLES for the mainframe
is different from how it's done on RHEL."  Red Hat hears the same, in
reverse. SUSE and Red Hat both approached IBM to ask them to write and
maintain a replacement set of tools for these sorts of scripts. That
way, the tools to perform persistent and transient configuration will be
the same across distributions. I haven't looked, but I'm guessing Ubuntu
for the mainframe is using them as well.

So, IBM came up the lszdev and chzdev utilities. To provide
compatibility, I modified the existing *_configure scripts to use them
instead of the previous logic. Moving forward, SUSE will be using the
lszdev and chzdev commands in our own tools where the *_configure
scripts have been used in the past. The linuxrc program to set up the
installation environment is already doing that.

The wrapper scripts were written solely as a means of translating the
old semantics into the ones required by IBM's commands. The lszdev and
chzdev commands provide a lot more functionality than the old
*_configure scripts did. There will be no changes to the *_configure
scripts unless there's a bug, or for some reason IBM changes the
parameters their commands accept or require.

If you set an environment variable of DEBUG to "yes", the *_configure
scripts will display the chzdev command that gets executed, as well as
actually executing it. Besides helping in debugging, this will allow
anyone wishing to get ahead of the curve to see exactly what command
needs to be executed to accomplish the same task as before.

The old scripts will not be removed from the SLES12 product. At this
point, we're not sure if they will be removed from future service pack
levels of SLES15 or not. They almost certainly will not be part of the
follow-on version after SLES15. (After what happened between SLES12 and
SLES15, I'm not going to even try and outguess Product Management as to
what name that's going to be.)

Finally, this is Open Source Software. If you decide you're simply not
going to move to the new commands from IBM, you're welcome to make and
keep copies of the *_configure scripts for your own use, for ever and ever.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: dasd_configure in SLES 12 SP4

[Christer Solskogen]

On Fri, May 31, 2019 at 12:48 PM Michael MacIsaac 
wrote:

> Mark,
>
> > The wrappers will be removed at some point in the future.
> Why?  Doing so will break scripts we have ...
>
>
Same here. I would urge SuSE to keep them.

--
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: dasd_configure in SLES 12 SP4

[Michael MacIsaac]

Mark,

> The wrappers will be removed at some point in the future.
Why?  Doing so will break scripts we have ...

-Mike

On Thu, May 30, 2019 at 5:06 PM Mark Post  wrote:

> On 5/30/19 4:54 PM, Marcy Cortes wrote:
> > Should I just be using that chzdev command now?
>
> Yes. Starting with SLES12 SP4, the following SUSE-provided scripts:
> ctc_configure
> dasd_configure
> qeth_configure
> zfcp_disk_configure
> zfcp_host_configure
>
> are simply wrappers for the chzdev command. The wrappers will be removed
> at some point in the future.
>
>
> 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://www2.marist.edu/htbin/wlvindex?LINUX-390
>


--
 -Mike MacIsaac

--
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: dasd_configure in SLES 12 SP4

[Marcy Cortes]

Thanks, Mark!

One more if you don't mind

myhost:~ # vgextend app /dev/disk/by-path/ccw-0.0.8002-part1
  Device /dev/disk/by-path/ccw-0.0.8002-part1 excluded by a filter.

myhost:~ # l /dev/disk/by-path/ccw-0.0.8002-part1
lrwxrwxrwx 1 root root 12 May 30 16:00 /dev/disk/by-path/ccw-0.0.8002-part1 -> 
../../dasdk1

myhost:~ # vgextend app /dev/dasdk1
  Volume group "app" successfully extended

I can't use the names with virtual addresses anymore? 

Both SP3 and SP4 seem to have this line in /etc/lvm/lvm.conf
filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", "r|/dev/fd.*|", 
"r|/dev/cdrom|", "a/.*/" ]

So not sure what is up with that...



-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Thursday, May 30, 2019 2:04 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] dasd_configure in SLES 12 SP4

On 5/30/19 4:54 PM, Marcy Cortes wrote:
> Should I just be using that chzdev command now?

Yes. Starting with SLES12 SP4, the following SUSE-provided scripts:
ctc_configure
dasd_configure
qeth_configure
zfcp_disk_configure
zfcp_host_configure

are simply wrappers for the chzdev command. The wrappers will be removed
at some point in the future.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

--
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: dasd_configure in SLES 12 SP4

[Mark Post]

On 5/30/19 4:54 PM, Marcy Cortes wrote:
> Should I just be using that chzdev command now?

Yes. Starting with SLES12 SP4, the following SUSE-provided scripts:
ctc_configure
dasd_configure
qeth_configure
zfcp_disk_configure
zfcp_host_configure

are simply wrappers for the chzdev command. The wrappers will be removed
at some point in the future.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

dasd_configure in SLES 12 SP4

[Marcy Cortes]

So it seems to return an 8 now on SP4 , which messes up my scripting :(

myhost:~ # export DEBUG=yes
myhost:~ # dasd_configure 0.0.8002 1 0
All the parms passed were  -- '0.0.8002' '1' '0'
Found the end of parms indicator: --
chzdev -e dasd --no-root-update 0.0.8002  use_diag=0
ECKD DASD 0.0.8002 configured
DASD 0.0.8002 is unformatted.
myhost:~ # echo $?
8


Should I just be using that chzdev command now?   Seems to do the same thing.
I noticed also that /etc/udev/rules.d names are changed
SP3 name: 51-dasd-0.0.8000.rules
SP4 name: 41-dasd-eckd-0.0.8002.rules

Doesn't seem to be a problem but just throwing that out there.



Marcy

This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


--
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: iucvconn setup on SLES 12

[Will, Chris]

Darn, here is what we are running.

s390-tools-1.34.0-65.5.1.s390x

Chris Will
Enterprise Linux/UNIX (ELU)
(313) 549-9729 Cell
cw...@bcbsm.com

-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Thursday, May 30, 2019 3:42 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: iucvconn setup on SLES 12

 ALERT This email was sent from a source external to BCBSM/BCN.
 DO NOT CLICK links or attachments unless you recognize the sender and trust 
the content.


On 5/30/19 1:15 PM, Will, Chris wrote:
> I have this sort of working.  It will display a few messages and then close 
> the connection.  I connect again and it will display a few messages, close, 
> etc.

That sounds vaguely familiar to me. Let me ask the obligatory question:
are you up to date on maintenance for both systems on either side of that 
connection?


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://www2.marist.edu/htbin/wlvindex?LINUX-390


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.


--
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: iucvconn setup on SLES 12

[Will, Chris]

We are at SLES 12 SP3 ~ sept 2018 patch level

Information for package s390-tools:
---
Repository : SLES12-SP3-Updates:testing
Name   : s390-tools
Version: 1.34.0-65.20.1

Chris Will
Enterprise Linux/UNIX (ELU)
(313) 549-9729 Cell
cw...@bcbsm.com

-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Thursday, May 30, 2019 3:42 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: iucvconn setup on SLES 12

 ALERT This email was sent from a source external to BCBSM/BCN.
 DO NOT CLICK links or attachments unless you recognize the sender and trust 
the content.


On 5/30/19 1:15 PM, Will, Chris wrote:
> I have this sort of working.  It will display a few messages and then close 
> the connection.  I connect again and it will display a few messages, close, 
> etc.

That sounds vaguely familiar to me. Let me ask the obligatory question:
are you up to date on maintenance for both systems on either side of that 
connection?


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://www2.marist.edu/htbin/wlvindex?LINUX-390


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.


--
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: iucvconn setup on SLES 12

[Mark Post]

On 5/30/19 1:15 PM, Will, Chris wrote:
> I have this sort of working.  It will display a few messages and then close 
> the connection.  I connect again and it will display a few messages, close, 
> etc.

That sounds vaguely familiar to me. Let me ask the obligatory question:
are you up to date on maintenance for both systems on either side of
that connection?


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: iucvconn setup on SLES 12

[Will, Chris]

I have this sort of working.  It will display a few messages and then close the 
connection.  I connect again and it will display a few messages, close, etc.

Here is my cmdline

root=UUID=ad5a0c5a-1372-474b-97a6-a07ba754a36a hvc_iucv=8 TERM=dumb 
crashkernel=102M console=ttyS0 console=hvc0

Similar with or without running this with the terminal server.

# ssh nbxdv392@slxmfdev3
Password:
Last login: Thu May 30 11:45:26 2019 from 10.96.1.149
This is a private system.  Unauthorized use is prohibited.
iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0)

iucvconn: Connecting to the z/VM guest virtual machine failed: Connection 
refused
Connection to slxmfdev3 closed.
(root@slxmfdev3:~)
# ssh nbxdv392@slxmfdev3
Password:
Last login: Thu May 30 11:45:39 2019 from 10.96.1.149
This is a private system.  Unauthorized use is prohibited.
iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0)

Connection to slxmfdev3 closed.
(root@slxmfdev3:~)
#
(root@slxmfdev3:~)
# ssh nbxdv392@slxmfdev3
Password:
Last login: Thu May 30 11:45:45 2019 from 10.96.1.149
This is a private system.  Unauthorized use is prohibited.
iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0)

[  OK  ] Found device /dev/user-vg/app-lv.
Connection to slxmfdev3 closed.
(root@slxmfdev3:~)
# ssh nbxdv392@slxmfdev3
Password:
Last login: Thu May 30 11:45:56 2019 from 10.96.1.149
This is a private system.  Unauthorized use is prohibited.
iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0)

[  OK  ] Started File System Check on /dev/user-vg/ibmitm-lv.
Connection to slxmfdev3 closed.   on /dev/user-vg/app-lv 
(21s / no limit)
(root@slxmfdev3:~)
# exit
logout
Connection to slxmfdev3 closed.

Chris Will
Enterprise Linux/UNIX (ELU)
(313) 549-9729 Cell
cw...@bcbsm.com

-Original Message-
From: Linux on 390 Port  On Behalf Of David Boyes
Sent: Saturday, May 25, 2019 3:01 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: iucvconn setup on SLES 12

 ALERT This email was sent from a source external to BCBSM/BCN.
 DO NOT CLICK links or attachments unless you recognize the sender and trust 
the content.


On 5/24/19, 9:16 AM, "Linux on 390 Port on behalf of Alan Altmark" 
 wrote:
>While I've always wanted to see it virtualized and the VM telnet server
>given a way to connect to it (meaning no client/host translations or
>conversions)

Amen to both. Constructing an analogue to a classic terminal server UI as a VM 
application wouldn't be that hard to do if we set our minds to it. Would be a 
clever use of the RSK toolkit or PIPEs.

> I've never heard of a problem with the HMC ASCII console.
> What's the issue?

It's not necessarily a problem with the console function per se, but a 
differing set of expectations on how to use it and how it's expected to 
function when presented to a person familiar with the idea of a serial console 
attached to a terminal server as the default behavior.

It's an unusual setup in that it a) has to be set up within every virtual 
system rather than being the default behavior out of the box (the discrete box 
console/terminal server approach requires no modification to how the target 
system is configured at all, allowing moving between physical and virtual 
environments transparently), b) has been unevenly supported by distribution 
releases over time (in terms of what you have to do being different on 
RH/SuSE/Ubuntu) which has occasionally been a PITA, and c) at various points in 
time it could only be effectively used with one virtual machine at a time. All 
are fixable (with c) being an issue with your HMC ucode level), but they're not 
the out-of-the-box default and it's another gratuitous difference that hostile 
folks use to claim the platform is somehow less appropriate; the fact you can 
accomplish the same goal isn't the same thing as "it can be done the same way 
you manage all your other systems" and it's a lot harder to sell if you have to 
sell a "this is different, so you need to accommodate it" solution to system 
management.

The Linux-based terminal server is closer to how the other platforms behave, 
and most of the common management solutions Just Work with how it operates 
(with some minor tweaks to UI text and behavior, it's a drop-in; changing the 
prompts to be compatible with the default Cisco/Livingston terminal server 
dialog is a fairly minor step and can be done once in a central place). 
Integrating this with things like Kafka and other mass log/event analysis tools 
is a lot easier, which reduces the cost of operation by allowing more common 
investments to cover more infrastructure. Authentication issues (like the one 
with 2-factor auth recently discussed here) can be completely consistent across 
platforms, and support common solutions that don't require acquiring additional 
commercial tooling.




--
For L

Re: iucvconn setup on SLES 12

[David Boyes]

On 5/24/19, 9:16 AM, "Linux on 390 Port on behalf of Alan Altmark" 
 wrote:
>While I've always wanted to see it virtualized and the VM telnet server 
>given a way to connect to it (meaning no client/host translations or 
>conversions)

Amen to both. Constructing an analogue to a classic terminal server UI as a VM 
application wouldn't be that hard to do if we set our minds to it. Would be a 
clever use of the RSK toolkit or PIPEs.

> I've never heard of a problem with the HMC ASCII console. 
> What's the issue?

It's not necessarily a problem with the console function per se, but a 
differing set of expectations on how to use it and how it's expected to 
function when presented to a person familiar with the idea of a serial console 
attached to a terminal server as the default behavior. 

It's an unusual setup in that it a) has to be set up within every virtual 
system rather than being the default behavior out of the box (the discrete box 
console/terminal server approach requires no modification to how the target 
system is configured at all, allowing moving between physical and virtual 
environments transparently), b) has been unevenly supported by distribution 
releases over time (in terms of what you have to do being different on 
RH/SuSE/Ubuntu) which has occasionally been a PITA, and c) at various points in 
time it could only be effectively used with one virtual machine at a time. All 
are fixable (with c) being an issue with your HMC ucode level), but they're not 
the out-of-the-box default and it's another gratuitous difference that hostile 
folks use to claim the platform is somehow less appropriate; the fact you can 
accomplish the same goal isn't the same thing as "it can be done the same way 
you manage all your other systems" and it's a lot harder to sell if you have to 
sell a "this is different, so you need to accommodate it" solution to system 
management. 

The Linux-based terminal server is closer to how the other platforms behave, 
and most of the common management solutions Just Work with how it operates 
(with some minor tweaks to UI text and behavior, it's a drop-in; changing the 
prompts to be compatible with the default Cisco/Livingston terminal server 
dialog is a fairly minor step and can be done once in a central place). 
Integrating this with things like Kafka and other mass log/event analysis tools 
is a lot easier, which reduces the cost of operation by allowing more common 
investments to cover more infrastructure. Authentication issues (like the one 
with 2-factor auth recently discussed here) can be completely consistent across 
platforms, and support common solutions that don't require acquiring additional 
commercial tooling. 




--
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: iucvconn setup on SLES 12

[Alan Altmark]

On Thursday, 05/23/2019 at 07:38 GMT, David Boyes  
wrote:
> IBM tried to introduce an HMC feature to provide a character-mode
> console, but it never worked the way most people wanted it to work, so 
this is
> the result.

While I've always wanted to see it virtualized and the VM telnet server 
given a way to connect to it (meaning no client/host translations or 
conversions), I've never heard of a problem with the HMC ASCII console. 
What's the issue?

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
IBM Z Delivery Practice
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott


--
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: iucvconn setup on SLES 12

[David Boyes]

On 5/23/19, 11:18 AM, "Linux on 390 Port on behalf of Will, Chris" 
 wrote:
>Is there any advantage to setting up a terminal server 

Yes. Think of it as analogous to attaching the console ports of your discrete 
servers without built-in management processors to a hardware terminal server so 
you can connect to them before networking is working. The original purpose of 
the terminal server code was to deal with the case where you bork the network 
and thus can't do anything without dealing with CMS's occasionally weird antics 
wrt terminal access. It lets you use the editors and environment you're 
familiar with in the Unix world to fix what you broke, without learning ed in 
TTY mode. IBM tried to introduce an HMC feature to provide a character-mode 
console, but it never worked the way most people wanted it to work, so this is 
the result.

> and how is this accomplished?  

Cookbook at http://public.dhe.ibm.com/software/dw/linux390/docu/l4n0ht01.pdf

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

iucvconn setup on SLES 12

[Will, Chris]

Currently we have had good success using iucvconn on our SLES 11 SP4 servers.  
We use it mostly for a server that goes into emergency repair mode and we need 
a console.  Based on some one of the newer z/VM cookbooks, I thought this was 
already setup for SLES 12 and there are hvc terminals allocated on the grub 
config file.  However, it looks like we still need to define a "console=hvc0" 
on the /etc/default/grub file.  Is there any advantage to setting up a terminal 
server and how is this accomplished?  The most important feature we need is 
console access (i.e. be able to view boot messages, emergency repair mode, 
etc.).

Chris Will
Enterprise Linux/UNIX (ELU)
(313) 549-9729 Cell
cw...@bcbsm.com



The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.

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

SLES 12 "Tuning/Optimization Guide" for s390x?

[Rodery, Floyd A CIV DISA SEL1 (US)]

As many sites are upgrading from SLES 11 to SLES 12, I was curious if there 
were any specific references or known standards regarding "tunable parameters" 
related to s390x?  Outside of the obvious things like setting the vm.swappiness 
to something other than the default of "60", I was curious if there were any 
"standard configs" for SLES 12 regardless of the application it's running.

For example, on some of our SLES 11 systems, the following notes were made in 
/etc/sysctl.conf regarding "tuning for s390x".  I'm not sure if these are still 
advantageous to carry over and if there should be any additional configuration 
changes:

kernel.sched_min_granularity_ns = 1000
kernel.sched_wakeup_granularity_ns = 1500
kernel.sched_latency_ns = 8000
kernel.sched_tunable_scaling = 0

I was able to find a document on SUSE Blog regarding "SLES 11/12 OS Tuning & 
Optimization Guide", but seems architecture independent and doesn't seem to 
reference anything specific to SLES 12 vs SLES 11.

Reference:  
https://www.suse.com/c/sles-1112-os-tuning-optimisation-guide-part-1/

Floyd Rodery 

--
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: SUSE SLES 12 missing PHP extensions

[Aria Bamdad]

Hi Mark,

Thank you for your reply.  It turns out that I just downloaded the source
from a PHP branch closes to the version delivered by SLES 12 and compiled
the Tidy module and used it in my system.  I reported this as a bug but it
took months to get any answer so I moved on.  Tidy was one of several
modules that were previously available with PHP on SLES but then removed.
Not sure why.  These modules are often used by various packages that are PHP
based.

Thanks again for following up.

Aria

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark
Post
Sent: Friday, September 21, 2018 7:20 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SUSE SLES 12 missing PHP extensions

>>> On 1/2/2018 at 02:42 PM, Aria Bamdad  wrote:
> Hi,
>
>
>
> I have an application that requires the PHP-Tidy extension among others.
> Previously with SLES 11, this extension, among others was provided by SUSE
> for PHP 5.2 that came with SLES 11.  Now with SLES 12, PHP 5.5 and 7 are
> available but for some unknown reason, this extension and other were left
> out.  According to PHP documentation, the PHP-Tidy extension is now
bundled
> with PHP and is available using the --with-tidy configure option.
However,
> the only way to do this is to rebuild PHP from source again.
>
>
>
> I have had a ticket open with SUSE support for over a month and they are
> dragging their feet and not coming up with a solution.  This is crazy.
> Anyone else has had any issue with this and other PHP extensions that are
> part of the base and missing on SLES 12?

Hi, Aria,

I'm sorry that I'm 9 months late in responding to this.  It looks like
php7-tidy is in the SUSE Package Hub.  As such, it's not supported, but
installing it won't cause any problems with your systems being considered
"supportable" by SUSE.  It also means that SUSE Product Management has
decided to not include php7-tidy in the SLES product.  On the plus side, it
appears that it's being kept current on security fixes; a couple of patches
were added just 2 weeks ago.

You'll need to have your system(s) registered either with SCC, or a local
SMT server.  The package should be available via one of the
SUSE-PackageHub-?? channels.


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/

--
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: SUSE SLES 12 missing PHP extensions

[Mark Post]

>>> On 1/2/2018 at 02:42 PM, Aria Bamdad  wrote: 
> Hi,
> 
> 
> 
> I have an application that requires the PHP-Tidy extension among others.
> Previously with SLES 11, this extension, among others was provided by SUSE
> for PHP 5.2 that came with SLES 11.  Now with SLES 12, PHP 5.5 and 7 are
> available but for some unknown reason, this extension and other were left
> out.  According to PHP documentation, the PHP-Tidy extension is now bundled
> with PHP and is available using the --with-tidy configure option.  However,
> the only way to do this is to rebuild PHP from source again.
> 
> 
> 
> I have had a ticket open with SUSE support for over a month and they are
> dragging their feet and not coming up with a solution.  This is crazy.
> Anyone else has had any issue with this and other PHP extensions that are
> part of the base and missing on SLES 12?

Hi, Aria,

I'm sorry that I'm 9 months late in responding to this.  It looks like 
php7-tidy is in the SUSE Package Hub.  As such, it's not supported, but 
installing it won't cause any problems with your systems being considered 
"supportable" by SUSE.  It also means that SUSE Product Management has decided 
to not include php7-tidy in the SLES product.  On the plus side, it appears 
that it's being kept current on security fixes; a couple of patches were added 
just 2 weeks ago.

You'll need to have your system(s) registered either with SCC, or a local SMT 
server.  The package should be available via one of the SUSE-PackageHub-?? 
channels.


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/

Documentation about upgrading from SLES 11 SP4 to SLES 12 SP3 with "silent mode"?

[Csaba Polgar]

Could somebody provide a link, documentation or a draft about upgrading
from SLES 11 SP4 to SLES 12 SP3 with "silent mode" (without interaction)?


Kind Regards,

Csaba Polgar

--
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: Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

[Will, Chris]

Turned out that there was a copy of perl in /usr/local/bin.  No idea how it got 
there.

Chris Will
Enterprise Linux/UNIX (ELU)
(313) 549-9729 Cell
cw...@bcbsm.com

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Friday, March 23, 2018 7:04 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

>>> On 3/19/2018 at 03:03 PM, "Will, Chris" <cw...@bcbsm.com> wrote: 
> I ran the upgrade and everything seemed ok until I ran a perl job (in 
> this case smt-agent).  It seems the @INC variable is still pointing to 
> the older
> 5.10 version and not 5.18 that comes with SLES 12.  Is there any way 
> to refresh this or reinstall perl to correct this?
> 
> # smt-agent
> Can't locate strict.pm in @INC (@INC contains: 
> /usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
> /usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi
> /usr/lib/perl5/site_perl/5.10.0
> /usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at 
> /usr/sbin/smt-agent line 2.
> BEGIN failed--compilation aborted at /usr/sbin/smt-agent line 2.

SMT is written entirely in perl.  As others have said, that looks like at least 
pieces of the older perl have been left on the system.

-snip-
> # perl -V
> Can't locate Config.pm in @INC (@INC contains: 
> /usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0
-snip0
> Another file that seems identical gives the following which is correct.
> 
> # perl5.18.2 -V
> Summary of my perl5 (revision 5 version 18 subversion 2) configuration:
> 
>   Platform:
> osname=linux, osvers=3.12.61-52.101-default, 
> archname=s390x-linux-thread-multi

-snip-
The fact that these two binaries give different results tells us that they are 
_not_ identical.  Running ls -li /usr/bin/perl*

will show whether or not the perl name is hard-linked to perl5.18.2 or not.  
Running md5sum /usr/bin/perl /usr/sbin/perl5.18.2

will show whether or not the contents are identical.  Running rpm -V perl

will show if anything else is wrong with the package.  Just for "fun," running 
which -a perl

show all the executable binaries named perl that are in your $PATH.  I would 
expect to see something like this:
# which -a perl
/usr/bin/perl
/usr/bin/X11/perl

Those are actually the same file, since /usr/bin/X11 is a symbolic link to 
/usr/bin (or should be).

I don't think having DB2 on the system would be the cause of this sort of 
problem, unless the IBM package is doing something _really_ stupid.  (Not 
impossible, but not likely either.)


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/


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.

--
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: Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

[Mark Post]

>>> On 3/19/2018 at 03:03 PM, "Will, Chris" <cw...@bcbsm.com> wrote: 
> I ran the upgrade and everything seemed ok until I ran a perl job (in this 
> case smt-agent).  It seems the @INC variable is still pointing to the older 
> 5.10 version and not 5.18 that comes with SLES 12.  Is there any way to 
> refresh this or reinstall perl to correct this?
> 
> # smt-agent
> Can't locate strict.pm in @INC (@INC contains: 
> /usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
> /usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi 
> /usr/lib/perl5/site_perl/5.10.0 
> /usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi 
> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at 
> /usr/sbin/smt-agent line 2.
> BEGIN failed--compilation aborted at /usr/sbin/smt-agent line 2.

SMT is written entirely in perl.  As others have said, that looks like at least 
pieces of the older perl have been left on the system.

-snip-
> # perl -V
> Can't locate Config.pm in @INC (@INC contains: 
> /usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
-snip0
> Another file that seems identical gives the following which is correct.
> 
> # perl5.18.2 -V
> Summary of my perl5 (revision 5 version 18 subversion 2) configuration:
> 
>   Platform:
> osname=linux, osvers=3.12.61-52.101-default, 
> archname=s390x-linux-thread-multi

-snip-
The fact that these two binaries give different results tells us that they are 
_not_ identical.  Running
ls -li /usr/bin/perl*

will show whether or not the perl name is hard-linked to perl5.18.2 or not.  
Running
md5sum /usr/bin/perl /usr/sbin/perl5.18.2

will show whether or not the contents are identical.  Running
rpm -V perl

will show if anything else is wrong with the package.  Just for "fun," running
which -a perl

show all the executable binaries named perl that are in your $PATH.  I would 
expect to see something like this:
# which -a perl
/usr/bin/perl
/usr/bin/X11/perl

Those are actually the same file, since /usr/bin/X11 is a symbolic link to 
/usr/bin (or should be).

I don't think having DB2 on the system would be the cause of this sort of 
problem, unless the IBM package is doing something _really_ stupid.  (Not 
impossible, but not likely either.)


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/

Re: Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

[Will, Chris]

No luck so far.  I opened a trouble ticket with SUSE and they said it was 
related to having db2 installed.  It seems pretty drastic to have to remove db2 
especially if it is a database server.

Chris Will
Enterprise Linux/UNIX (ELU)
(313) 549-9729 Cell
cw...@bcbsm.com

-Original Message-
From: te...@wellsfargo.com [mailto:te...@wellsfargo.com] 
Sent: Tuesday, March 20, 2018 12:34 PM
To: LINUX-390@VM.MARIST.EDU
Cc: marcy.d.cor...@wellsfargo.com; Will, Chris <cw...@bcbsm.com>
Subject: RE: Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

Check your environment too.  Perl will add things to the list of libraries it 
checks with the PERL5LIB or PERLLIB environment variables.

The two perl binaries should be the same file:
> ls -li /usr/bin/perl /usr/bin/perl5.18.2
17797 -rwxr-xr-x 2 root root 1710088 Nov  3 08:59 /usr/bin/perl
17797 -rwxr-xr-x 2 root root 1710088 Nov  3 08:59 /usr/bin/perl5.18.2

(note that the link count is 2 and they have the same inode number), so 
something got bollixed up in the installation

Ted Rodriguez-Bell
Enterprise Virtualization, z/VM and z/Linux, Wells Fargo
 
Company policy requires:  This message may contain confidential and/or 
privileged information.  If you are not the addressee or authorized to receive 
this for the addressee, you must not use, copy, disclose, or take any action 
based on this message or any information herein.  If you have received this 
message in error, please advise the sender immediately by reply e-mail and 
delete this message.  Thank you for your cooperation.
-Original Message-
From: Marcy Cortes [mailto:marcy.d.cor...@wellsfargo.com]
Sent: Monday, March 19, 2018 12:34 PM
Subject: Re: Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

Looks like you ended up with some of 5.10 still installed

rpm -qa | grep -i perl
and remove any of the 5.10 stuff with rpm -e or zypper remove 

Reinstall perl 5.18 with
zypper install -f perl-base

Use the "zypper packages --orphaned" to make sure you aren't carrying around 
other old stuff that will never get patched.


Marcy

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Will, 
Chris
Sent: Monday, March 19, 2018 12:04 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

I ran the upgrade and everything seemed ok until I ran a perl job (in this case 
smt-agent).  It seems the @INC variable is still pointing to the older 5.10 
version and not 5.18 that comes with SLES 12.  Is there any way to refresh this 
or reinstall perl to correct this?

# smt-agent
Can't locate strict.pm in @INC (@INC contains: 
/usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at 
/usr/sbin/smt-agent line 2.
BEGIN failed--compilation aborted at /usr/sbin/smt-agent line 2.

In the /usr/bin directory

# perl -V
Can't locate Config.pm in @INC (@INC contains: 
/usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .).
BEGIN failed--compilation aborted.

Another file that seems identical gives the following which is correct.

# perl5.18.2 -V
Summary of my perl5 (revision 5 version 18 subversion 2) configuration:

  Platform:
osname=linux, osvers=3.12.61-52.101-default, 
archname=s390x-linux-thread-multi
uname='linux s390lp5 3.12.61-52.101-default #1 smp mon oct 30 16:15:15 utc 
2017 (dc2a32b) s390x s390x s390x gnulinux '
config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl 
-Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true 
-Doptimize=-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 -Wall 
-D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe 
-Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl 
-Dinc_version_list=5.18.0/s390x-linux-thread-multi 5.18.0 
5.18.1/s390x-linux-thread-multi 5.18.1'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV 
-fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',
optimize='-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 
-Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -Wall 
-pipe',
cpp

Re: Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

[Ted Rodriguez-Bell]

Check your environment too.  Perl will add things to the list of libraries it 
checks with the PERL5LIB or PERLLIB environment variables.

The two perl binaries should be the same file:
> ls -li /usr/bin/perl /usr/bin/perl5.18.2
17797 -rwxr-xr-x 2 root root 1710088 Nov  3 08:59 /usr/bin/perl
17797 -rwxr-xr-x 2 root root 1710088 Nov  3 08:59 /usr/bin/perl5.18.2

(note that the link count is 2 and they have the same inode number), so 
something got bollixed up in the installation

Ted Rodriguez-Bell
Enterprise Virtualization, z/VM and z/Linux, Wells Fargo
 
Company policy requires:  This message may contain confidential and/or 
privileged information.  If you are not the addressee or authorized to receive 
this for the addressee, you must not use, copy, disclose, or take any action 
based on this message or any information herein.  If you have received this 
message in error, please advise the sender immediately by reply e-mail and 
delete this message.  Thank you for your cooperation.
-Original Message-
From: Marcy Cortes [mailto:marcy.d.cor...@wellsfargo.com] 
Sent: Monday, March 19, 2018 12:34 PM
Subject: Re: Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

Looks like you ended up with some of 5.10 still installed

rpm -qa | grep -i perl 
and remove any of the 5.10 stuff with rpm -e or zypper remove 

Reinstall perl 5.18 with
zypper install -f perl-base

Use the "zypper packages --orphaned" to make sure you aren't carrying around 
other old stuff that will never get patched.


Marcy

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Will, 
Chris
Sent: Monday, March 19, 2018 12:04 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

I ran the upgrade and everything seemed ok until I ran a perl job (in this case 
smt-agent).  It seems the @INC variable is still pointing to the older 5.10 
version and not 5.18 that comes with SLES 12.  Is there any way to refresh this 
or reinstall perl to correct this?

# smt-agent
Can't locate strict.pm in @INC (@INC contains: 
/usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at 
/usr/sbin/smt-agent line 2.
BEGIN failed--compilation aborted at /usr/sbin/smt-agent line 2.

In the /usr/bin directory

# perl -V
Can't locate Config.pm in @INC (@INC contains: 
/usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .).
BEGIN failed--compilation aborted.

Another file that seems identical gives the following which is correct.

# perl5.18.2 -V
Summary of my perl5 (revision 5 version 18 subversion 2) configuration:

  Platform:
osname=linux, osvers=3.12.61-52.101-default, 
archname=s390x-linux-thread-multi
uname='linux s390lp5 3.12.61-52.101-default #1 smp mon oct 30 16:15:15 utc 
2017 (dc2a32b) s390x s390x s390x gnulinux '
config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl 
-Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true 
-Doptimize=-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 -Wall 
-D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe 
-Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl 
-Dinc_version_list=5.18.0/s390x-linux-thread-multi 5.18.0 
5.18.1/s390x-linux-thread-multi 5.18.1'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV 
-fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',
optimize='-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 
-Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -Wall 
-pipe',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV 
-fno-strict-aliasing -pipe -fstack-protector'
ccversion='', gccversion='4.8.5', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
   ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
alignbytes=8, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
libpth=/lib64 /usr/lib64 /usr/local/lib64
libs=-lm

Re: Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

[Marcy Cortes]

Looks like you ended up with some of 5.10 still installed

rpm -qa | grep -i perl 
and remove any of the 5.10 stuff with rpm -e or zypper remove 

Reinstall perl 5.18 with
zypper install -f perl-base

Use the "zypper packages --orphaned" to make sure you aren't carrying around 
other old stuff that will never get patched.


Marcy

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Will, 
Chris
Sent: Monday, March 19, 2018 12:04 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

I ran the upgrade and everything seemed ok until I ran a perl job (in this case 
smt-agent).  It seems the @INC variable is still pointing to the older 5.10 
version and not 5.18 that comes with SLES 12.  Is there any way to refresh this 
or reinstall perl to correct this?

# smt-agent
Can't locate strict.pm in @INC (@INC contains: 
/usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at 
/usr/sbin/smt-agent line 2.
BEGIN failed--compilation aborted at /usr/sbin/smt-agent line 2.

In the /usr/bin directory

# perl -V
Can't locate Config.pm in @INC (@INC contains: 
/usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .).
BEGIN failed--compilation aborted.

Another file that seems identical gives the following which is correct.

# perl5.18.2 -V
Summary of my perl5 (revision 5 version 18 subversion 2) configuration:

  Platform:
osname=linux, osvers=3.12.61-52.101-default, 
archname=s390x-linux-thread-multi
uname='linux s390lp5 3.12.61-52.101-default #1 smp mon oct 30 16:15:15 utc 
2017 (dc2a32b) s390x s390x s390x gnulinux '
config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl 
-Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true 
-Doptimize=-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 -Wall 
-D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe 
-Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl 
-Dinc_version_list=5.18.0/s390x-linux-thread-multi 5.18.0 
5.18.1/s390x-linux-thread-multi 5.18.1'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV 
-fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',
optimize='-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 
-Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -Wall 
-pipe',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV 
-fno-strict-aliasing -pipe -fstack-protector'
ccversion='', gccversion='4.8.5', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
   ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
alignbytes=8, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
libpth=/lib64 /usr/lib64 /usr/local/lib64
libs=-lm -ldl -lcrypt -lpthread
perllibs=-lm -ldl -lcrypt -lpthread
libc=/lib64/libc-2.19.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.19'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E 
-Wl,-rpath,/usr/lib/perl5/5.18.2/s390x-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector'


Characteristics of this binary (from libperl):
  Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
PERL_PRESERVE_IVUV PERL_SAWAMPERSAND
PERL_USE_SAFE_PUTENV USE_64_BIT_ALL USE_64_BIT_INT
USE_ITHREADS USE_LARGE_FILES USE_LOCALE
USE_LOCALE_COLLATE USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
USE_REENTRANT_API
  Built under linux
  Compiled at Nov  3 2017 13:56:39
  @INC:
/usr/lib/perl5/site_perl/5.18.2/s390x-linux-thread-multi
/usr/lib/perl5/site_perl/5.18.

Problems with perl after sles 11 sp4 to sles 12 sp2 upgrade

[Will, Chris]

I ran the upgrade and everything seemed ok until I ran a perl job (in this case 
smt-agent).  It seems the @INC variable is still pointing to the older 5.10 
version and not 5.18 that comes with SLES 12.  Is there any way to refresh this 
or reinstall perl to correct this?

# smt-agent
Can't locate strict.pm in @INC (@INC contains: 
/usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at 
/usr/sbin/smt-agent line 2.
BEGIN failed--compilation aborted at /usr/sbin/smt-agent line 2.

In the /usr/bin directory

# perl -V
Can't locate Config.pm in @INC (@INC contains: 
/usr/lib/perl5/5.10.0/s390x-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/s390x-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .).
BEGIN failed--compilation aborted.

Another file that seems identical gives the following which is correct.

# perl5.18.2 -V
Summary of my perl5 (revision 5 version 18 subversion 2) configuration:

  Platform:
osname=linux, osvers=3.12.61-52.101-default, 
archname=s390x-linux-thread-multi
uname='linux s390lp5 3.12.61-52.101-default #1 smp mon oct 30 16:15:15 utc 
2017 (dc2a32b) s390x s390x s390x gnulinux '
config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl 
-Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true 
-Doptimize=-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 -Wall 
-D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe 
-Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl 
-Dinc_version_list=5.18.0/s390x-linux-thread-multi 5.18.0 
5.18.1/s390x-linux-thread-multi 5.18.1'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV 
-fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',
optimize='-fmessage-length=0 -grecord-gcc-switches -fstack-protector -O2 
-Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -Wall 
-pipe',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV 
-fno-strict-aliasing -pipe -fstack-protector'
ccversion='', gccversion='4.8.5', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
   ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
alignbytes=8, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
libpth=/lib64 /usr/lib64 /usr/local/lib64
libs=-lm -ldl -lcrypt -lpthread
perllibs=-lm -ldl -lcrypt -lpthread
libc=/lib64/libc-2.19.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.19'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E 
-Wl,-rpath,/usr/lib/perl5/5.18.2/s390x-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector'


Characteristics of this binary (from libperl):
  Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
PERL_PRESERVE_IVUV PERL_SAWAMPERSAND
PERL_USE_SAFE_PUTENV USE_64_BIT_ALL USE_64_BIT_INT
USE_ITHREADS USE_LARGE_FILES USE_LOCALE
USE_LOCALE_COLLATE USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
USE_REENTRANT_API
  Built under linux
  Compiled at Nov  3 2017 13:56:39
  @INC:
/usr/lib/perl5/site_perl/5.18.2/s390x-linux-thread-multi
/usr/lib/perl5/site_perl/5.18.2
/usr/lib/perl5/vendor_perl/5.18.2/s390x-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.18.2
/usr/lib/perl5/5.18.2/s390x-linux-thread-multi
/usr/lib/perl5/5.18.2
/usr/lib/perl5/site_perl



Chris Will
Enterprise Linux/UNIX (ELU)
(313) 549-9729 Cell
cw...@bcbsm.com



The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information

Re: SLES 12 upgrade fails

[Gregg Levine]

Hello!
Alan sadly that must be it. Google Mail and even those ninnies at AT
via Yahoo (email not the rest) were firmly convinced that anything
with Wells Fargo attached like that, is indeed like that. Heck! Every
time someone else on a different list sends something to that list,
from his Yahoo account to that list, I need to pull it out of the
spamtrap. I've complained why this happens and what to do to make it
work. I also did it for Marcy for this list, and even for the one on
UARK  but look where we are are now.
-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."


On Sat, Mar 17, 2018 at 8:41 AM, Alan Altmark <alan_altm...@us.ibm.com> wrote:
> For those who didn't see this
>
> Alan
>
> On Mar 16, 2018, 11:55:58 PM, marcy.d.cor...@wellsfargo.com wrote:
>
> From: marcy.d.cor...@wellsfargo.com
> To: LINUX-390@VM.MARIST.EDU
> Cc:
> Date: Mar 16, 2018, 11:55:58 PM
> Subject: Re: [LINUX-390] SLES 12 upgrade fails
>
>
>  So someone needs to reply and include my comments so all can see but it 
> appears that various mail providers are attempting to protect you from 
> phishing attempts on your bank accounts and going through the listserv 
> creates fishy headers. Lots of information you can find by googling phish 
> prevention and listserv.
>  I guess I will have to use personal email
>  Sent with BlackBerry Work
>  (www.blackberry.com)
>  From: Duerbusch, Tom >
>  Date: Friday, Mar 16, 2018, 9:21 AM
>  To: LINUX-390@VM.MARIST.EDU >
>  Subject: Re: [LINUX-390] SLES 12 upgrade fails
>  Marcy's posts have been going to my spam folder.
>  That just started happening recently.
>  Tom Duerbusch
>  THD Consulting
>  On Wed, Mar 14, 2018 at 9:56 PM, Alan Ackerman
>  wrote:
>  > I have the same problem — I am not seeing Marcy’s posts. I also don’t see
>  > anything about SLES 12 upgrade fails on the web page.
>  >
>  > Sent from my iPhone
>  >
>  > On Mar 14, 2018, at 5:15 PM, Gregg Levine  wrote:
>  >
>  > Hello!
>  >
>  > Mark as interesting as our discussions are, there is a more
>  > interesting problem, I'm not seeing anything by Marcy except as a
>  > response. That is when someone responds to something that Marcy
>  > posted.
>  > -
>  > Gregg C Levine gregg.drw...@gmail.com
>  > "This signature fought the Time Wars, time and again."
>  > --
>  > 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=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=aT7MuLzzQtensF4ftq7MxP9D6kI2OUogXmN6mXDmk8o=
>  > --
>  > For more information on Linux on System z, visit
>  > 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.linuxvm.org_=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=SyS4312VSwaf5IQ9SIfN1y9QNEy8eq7e8KumHXrAZPM=
>  >
>  --
>  --
>  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=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=aT7MuLzzQtensF4ftq7MxP9D6kI2OUogXmN6mXDmk8o=
>  --
>  For more information on Linux on System z, visit
>  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.linuxvm.org_=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=SyS4312VSwaf5IQ9SIfN1y9QNEy8eq7e8KumHXrAZPM=
>  --
>  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=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=aT7MuLzzQtensF4ftq7MxP9D6kI2OUogXmN6mXDmk8o=
>  -

Re: SLES 12 upgrade fails

[Alan Altmark]

For those who didn't see this

Alan

On Mar 16, 2018, 11:55:58 PM, marcy.d.cor...@wellsfargo.com wrote:

From: marcy.d.cor...@wellsfargo.com
To: LINUX-390@VM.MARIST.EDU
Cc: 
Date: Mar 16, 2018, 11:55:58 PM
Subject: Re: [LINUX-390] SLES 12 upgrade fails


 So someone needs to reply and include my comments so all can see but it 
appears that various mail providers are attempting to protect you from phishing 
attempts on your bank accounts and going through the listserv creates fishy 
headers. Lots of information you can find by googling phish prevention and 
listserv.
 I guess I will have to use personal email
 Sent with BlackBerry Work
 (www.blackberry.com)
 From: Duerbusch, Tom >
 Date: Friday, Mar 16, 2018, 9:21 AM
 To: LINUX-390@VM.MARIST.EDU >
 Subject: Re: [LINUX-390] SLES 12 upgrade fails
 Marcy's posts have been going to my spam folder.
 That just started happening recently.
 Tom Duerbusch
 THD Consulting
 On Wed, Mar 14, 2018 at 9:56 PM, Alan Ackerman 
 wrote:
 > I have the same problem — I am not seeing Marcy’s posts. I also don’t see
 > anything about SLES 12 upgrade fails on the web page.
 >
 > Sent from my iPhone
 >
 > On Mar 14, 2018, at 5:15 PM, Gregg Levine  wrote:
 >
 > Hello!
 >
 > Mark as interesting as our discussions are, there is a more
 > interesting problem, I'm not seeing anything by Marcy except as a
 > response. That is when someone responds to something that Marcy
 > posted.
 > -
 > Gregg C Levine gregg.drw...@gmail.com
 > "This signature fought the Time Wars, time and again."
 > --
 > 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=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=aT7MuLzzQtensF4ftq7MxP9D6kI2OUogXmN6mXDmk8o=
 > --
 > For more information on Linux on System z, visit
 > https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.linuxvm.org_=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=SyS4312VSwaf5IQ9SIfN1y9QNEy8eq7e8KumHXrAZPM=
 >
 --
 --
 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=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=aT7MuLzzQtensF4ftq7MxP9D6kI2OUogXmN6mXDmk8o=
 --
 For more information on Linux on System z, visit
 
https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.linuxvm.org_=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=SyS4312VSwaf5IQ9SIfN1y9QNEy8eq7e8KumHXrAZPM=
 --
 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=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=aT7MuLzzQtensF4ftq7MxP9D6kI2OUogXmN6mXDmk8o=
 --
 For more information on Linux on System z, visit
 
https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.linuxvm.org_=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=1Qc9Y1wHnkoEyYaXLr63hlmJYDJo6TQ4t9agOyQhBAk=SyS4312VSwaf5IQ9SIfN1y9QNEy8eq7e8KumHXrAZPM=
 


--
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: SLES 12 upgrade fails

[Marcy Cortes]

So someone needs to reply and include my comments so all can see but it appears 
that various mail providers are attempting to protect you from phishing 
attempts on your bank accounts and going through the listserv creates fishy 
headers. Lots of information you can find by googling phish prevention and 
listserv.

I guess I will have to use personal email


Sent with BlackBerry Work
(www.blackberry.com)

From: Duerbusch, Tom 
<duerbus...@stlouis-mo.gov<mailto:duerbus...@stlouis-mo.gov>>
Date: Friday, Mar 16, 2018, 9:21 AM
To: LINUX-390@VM.MARIST.EDU 
<LINUX-390@VM.MARIST.EDU<mailto:LINUX-390@VM.MARIST.EDU>>
Subject: Re: [LINUX-390] SLES 12 upgrade fails

Marcy's posts have been going to my spam folder.

That just started happening recently.

Tom Duerbusch
THD Consulting


On Wed, Mar 14, 2018 at 9:56 PM, Alan Ackerman <alan.ackerma...@gmail.com>
wrote:

> I have the same problem — I am not seeing Marcy’s posts. I also don’t see
> anything about SLES 12 upgrade fails on the web page.
>
> Sent from my iPhone
>
> On Mar 14, 2018, at 5:15 PM, Gregg Levine <gregg.drw...@gmail.com> wrote:
>
> Hello!
>
> Mark as interesting as our discussions are, there is a more
> interesting problem, I'm not seeing anything by Marcy except as a
> response. That is when someone responds to something that Marcy
> posted.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
> --
> 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/
>



--

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

--
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: SLES 12 upgrade fails

[Duerbusch, Tom]

Marcy's posts have been going to my spam folder.

That just started happening recently.

Tom Duerbusch
THD Consulting


On Wed, Mar 14, 2018 at 9:56 PM, Alan Ackerman <alan.ackerma...@gmail.com>
wrote:

> I have the same problem — I am not seeing Marcy’s posts. I also don’t see
> anything about SLES 12 upgrade fails on the web page.
>
> Sent from my iPhone
>
> On Mar 14, 2018, at 5:15 PM, Gregg Levine <gregg.drw...@gmail.com> wrote:
>
> Hello!
>
> Mark as interesting as our discussions are, there is a more
> interesting problem, I'm not seeing anything by Marcy except as a
> response. That is when someone responds to something that Marcy
> posted.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
> --
> 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/
>



--

--
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: SLES 12 upgrade fails

[Gregg Levine]

Hello!

Normally that's what does happen. But I also checked a different
subscribed address who's spam trapping is rather slipshod. It didn't
grab them there. These are just MIA.
 -
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."


On Thu, Mar 15, 2018 at 8:24 AM, Henry Schaffer <h...@ncsu.edu> wrote:
> This happens consistently for my mail system - her posts are put in the
> spam folder with this explanation:
>
> This message has a from address in wellsfargo.com but has failed
> wellsfargo.com's required tests for authentication.
>
>
> --henry schaffer
>
> On Thu, Mar 15, 2018 at 1:29 AM, Mike Walter <walterthepennyl...@hotmail.com
>> wrote:
>
>> For those missing Marcy's posts, check your junk mail folder.  I've found
>> some of hers go directly to my junk/spam folder.  It happens to a few other
>> posts as well, but not often or consistently enough to diagnose.
>>
>> Mike Walter
>>
>> From: Alan Ackerman
>> Sent: Wednesday, March 14, 9:58 PM
>> Subject: Re: SLES 12 upgrade fails
>> To: linux-390@vm.marist.edu
>>
>>
>> I have the same problem — I am not seeing Marcy’s posts. I also don’t see
>> anything about SLES 12 upgrade fails on the web page. Sent from my iPhone
>> On Mar 14, 2018, at 5:15 PM, Gregg Levine wrote: Hello! Mark as interesting
>> as our discussions are, there is a more interesting problem, I'm not seeing
>> anything by Marcy except as a response. That is when someone responds to
>> something that Marcy posted. - Gregg C Levine gregg.drw...@gmail.com
>> "This signature fought the Time Wars, time and again."
>> --
>> For LINUX-390 subscribe / signoff / archive access instructions, send email
>> to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
>> https://nam01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-
>> 390=02%7C01%7C%7C6dfc3327e7564eeb694508d58a209c35%
>> 7C84df9e7fe9f640afb435%7C1%7C0%7C636566795013345062=
>> ZQCp%2FBzTpZreBZSzhYrFwLNmdANoiVaKLqb%2Bg%2BIXGvE%3D=0
>> --
>> For more information on Linux on System z, visit https://nam01.safelinks.
>> protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%
>> 2F=02%7C01%7C%7C6dfc3327e7564eeb694508d58a209c35%
>> 7C84df9e7fe9f640afb435%7C1%7C0%7C636566795013345062=
>> P62watVQw5MHHa1rK%2BuUT3JSZqXGLIbEPK8tT5nzF1c%3D=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://www.marist.edu/htbin/wlvindex?LINUX-390
>> --
>> For more information on Linux on System z, visit
>> http://wiki.linuxvm.org/
>>
>
> --
> 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/

--
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: SLES 12 upgrade fails

[Stuart, David]

Depending on your email client, you may be able to set up a 'rule' that moves 
Marcy's posts back to your main inbox. If, in fact, that are being directed to 
the junk/spam folder. 


Dave 


Dave Stuart
Principal Info. Systems Support Analyst
County of Ventura
805-662-6731
david.stu...@ventura.org


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mike Riggs
Sent: Thursday, March 15, 2018 5:33 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES 12 upgrade fails

Whew.. I thought it was just me.  It would be great to get this resolved as her 
input/insight has been extremely valuable on more than one occasion.

Mike R
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Henry 
Schaffer
Sent: Thursday, March 15, 2018 8:24 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES 12 upgrade fails

This happens consistently for my mail system - her posts are put in the spam 
folder with this explanation:

This message has a from address in wellsfargo.com but has failed 
wellsfargo.com's required tests for authentication.


--henry schaffer

On Thu, Mar 15, 2018 at 1:29 AM, Mike Walter <walterthepennyl...@hotmail.com
> wrote:

> For those missing Marcy's posts, check your junk mail folder.  I've 
> found some of hers go directly to my junk/spam folder.  It happens to 
> a few other posts as well, but not often or consistently enough to diagnose.
>
> Mike Walter
>
> From: Alan Ackerman
> Sent: Wednesday, March 14, 9:58 PM
> Subject: Re: SLES 12 upgrade fails
> To: linux-390@vm.marist.edu
>
>
> I have the same problem — I am not seeing Marcy’s posts. I also don’t 
> see anything about SLES 12 upgrade fails on the web page. Sent from my 
> iPhone On Mar 14, 2018, at 5:15 PM, Gregg Levine wrote: Hello! Mark as 
> interesting as our discussions are, there is a more interesting 
> problem, I'm not seeing anything by Marcy except as a response. That 
> is when someone responds to something that Marcy posted. - Gregg C 
> Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and 
> again."
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send 
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
> visit https://nam01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-
> 390=02%7C01%7C%7C6dfc3327e7564eeb694508d58a209c35%
> 7C84df9e7fe9f640afb435%7C1%7C0%7C636566795013345062=
> ZQCp%2FBzTpZreBZSzhYrFwLNmdANoiVaKLqb%2Bg%2BIXGvE%3D=0
> --
> For more information on Linux on System z, visit https://nam01.safelinks.
> protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%
> 2F=02%7C01%7C%7C6dfc3327e7564eeb694508d58a209c35%
> 7C84df9e7fe9f640afb435%7C1%7C0%7C636566795013345062=
> P62watVQw5MHHa1rK%2BuUT3JSZqXGLIbEPK8tT5nzF1c%3D=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://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit 
> http://wiki.linuxvm.org/
>

--
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: SLES 12 upgrade fails

[Mike Riggs]

Whew.. I thought it was just me.  It would be great to get this resolved as her 
input/insight has been extremely valuable on more than one occasion.

Mike R
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Henry 
Schaffer
Sent: Thursday, March 15, 2018 8:24 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES 12 upgrade fails

This happens consistently for my mail system - her posts are put in the spam 
folder with this explanation:

This message has a from address in wellsfargo.com but has failed 
wellsfargo.com's required tests for authentication.


--henry schaffer

On Thu, Mar 15, 2018 at 1:29 AM, Mike Walter <walterthepennyl...@hotmail.com
> wrote:

> For those missing Marcy's posts, check your junk mail folder.  I've 
> found some of hers go directly to my junk/spam folder.  It happens to 
> a few other posts as well, but not often or consistently enough to diagnose.
>
> Mike Walter
>
> From: Alan Ackerman
> Sent: Wednesday, March 14, 9:58 PM
> Subject: Re: SLES 12 upgrade fails
> To: linux-390@vm.marist.edu
>
>
> I have the same problem — I am not seeing Marcy’s posts. I also don’t 
> see anything about SLES 12 upgrade fails on the web page. Sent from my 
> iPhone On Mar 14, 2018, at 5:15 PM, Gregg Levine wrote: Hello! Mark as 
> interesting as our discussions are, there is a more interesting 
> problem, I'm not seeing anything by Marcy except as a response. That 
> is when someone responds to something that Marcy posted. - Gregg C 
> Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and 
> again."
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send 
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
> visit https://nam01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-
> 390=02%7C01%7C%7C6dfc3327e7564eeb694508d58a209c35%
> 7C84df9e7fe9f640afb435%7C1%7C0%7C636566795013345062=
> ZQCp%2FBzTpZreBZSzhYrFwLNmdANoiVaKLqb%2Bg%2BIXGvE%3D=0
> --
> For more information on Linux on System z, visit https://nam01.safelinks.
> protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%
> 2F=02%7C01%7C%7C6dfc3327e7564eeb694508d58a209c35%
> 7C84df9e7fe9f640afb435%7C1%7C0%7C636566795013345062=
> P62watVQw5MHHa1rK%2BuUT3JSZqXGLIbEPK8tT5nzF1c%3D=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://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit 
> http://wiki.linuxvm.org/
>

--
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: SLES 12 upgrade fails

[Henry Schaffer]

This happens consistently for my mail system - her posts are put in the
spam folder with this explanation:

This message has a from address in wellsfargo.com but has failed
wellsfargo.com's required tests for authentication.


--henry schaffer

On Thu, Mar 15, 2018 at 1:29 AM, Mike Walter <walterthepennyl...@hotmail.com
> wrote:

> For those missing Marcy's posts, check your junk mail folder.  I've found
> some of hers go directly to my junk/spam folder.  It happens to a few other
> posts as well, but not often or consistently enough to diagnose.
>
> Mike Walter
>
> From: Alan Ackerman
> Sent: Wednesday, March 14, 9:58 PM
> Subject: Re: SLES 12 upgrade fails
> To: linux-390@vm.marist.edu
>
>
> I have the same problem — I am not seeing Marcy’s posts. I also don’t see
> anything about SLES 12 upgrade fails on the web page. Sent from my iPhone
> On Mar 14, 2018, at 5:15 PM, Gregg Levine wrote: Hello! Mark as interesting
> as our discussions are, there is a more interesting problem, I'm not seeing
> anything by Marcy except as a response. That is when someone responds to
> something that Marcy posted. - Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send email
> to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> https://nam01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-
> 390=02%7C01%7C%7C6dfc3327e7564eeb694508d58a209c35%
> 7C84df9e7fe9f640afb435%7C1%7C0%7C636566795013345062=
> ZQCp%2FBzTpZreBZSzhYrFwLNmdANoiVaKLqb%2Bg%2BIXGvE%3D=0
> --
> For more information on Linux on System z, visit https://nam01.safelinks.
> protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%
> 2F=02%7C01%7C%7C6dfc3327e7564eeb694508d58a209c35%
> 7C84df9e7fe9f640afb435%7C1%7C0%7C636566795013345062=
> P62watVQw5MHHa1rK%2BuUT3JSZqXGLIbEPK8tT5nzF1c%3D=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://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

--
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: SLES 12 upgrade fails

[Mike Walter]

For those missing Marcy's posts, check your junk mail folder.  I've found some 
of hers go directly to my junk/spam folder.  It happens to a few other posts as 
well, but not often or consistently enough to diagnose.

Mike Walter

From: Alan Ackerman
Sent: Wednesday, March 14, 9:58 PM
Subject: Re: SLES 12 upgrade fails
To: linux-390@vm.marist.edu


I have the same problem — I am not seeing Marcy’s posts. I also don’t see 
anything about SLES 12 upgrade fails on the web page. Sent from my iPhone On 
Mar 14, 2018, at 5:15 PM, Gregg Levine wrote: Hello! Mark as interesting as our 
discussions are, there is a more interesting problem, I'm not seeing anything 
by Marcy except as a response. That is when someone responds to something that 
Marcy posted. - Gregg C Levine gregg.drw...@gmail.com "This signature 
fought the Time Wars, time and again." 
-- For 
LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit 
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390=02%7C01%7C%7C6dfc3327e7564eeb694508d58a209c35%7C84df9e7fe9f640afb435%7C1%7C0%7C636566795013345062=ZQCp%2FBzTpZreBZSzhYrFwLNmdANoiVaKLqb%2Bg%2BIXGvE%3D=0
 -- For 
more information on Linux on System z, visit 
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%2F=02%7C01%7C%7C6dfc3327e7564eeb694508d58a209c35%7C84df9e7fe9f640afb435%7C1%7C0%7C636566795013345062=P62watVQw5MHHa1rK%2BuUT3JSZqXGLIbEPK8tT5nzF1c%3D=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://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES 12 upgrade fails

[Alan Ackerman]

I have the same problem — I am not seeing Marcy’s posts. I also don’t see 
anything about SLES 12 upgrade fails on the web page. 

Sent from my iPhone

On Mar 14, 2018, at 5:15 PM, Gregg Levine <gregg.drw...@gmail.com> wrote:

Hello!

Mark as interesting as our discussions are, there is a more
interesting problem, I'm not seeing anything by Marcy except as a
response. That is when someone responds to something that Marcy
posted.
-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."
--
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: SLES 12 upgrade fails

[Gregg Levine]

Hello!

Mark as interesting as our discussions are, there is a more
interesting problem, I'm not seeing anything by Marcy except as a
response. That is when someone responds to something that Marcy
posted.
-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."


On Wed, Mar 14, 2018 at 7:40 PM, Mark Post  wrote:
 On 3/14/2018 at 06:20 PM, Marcy Cortes  
 wrote:
>> Victor has already gotten the networking part to work since the VNC portion
>> came up and and enough of the media was loaded to put up the license
>> acceptance and the disk activated
>
> Hi, Marcy,
>
> Yes, I know.  In the past, we've seen all sorts of installation failures that 
> came down to things in the network or installation server not being quite 
> right.  In those cases, I've always recommended using HTTP or FTP servers 
> because it's much easier to get logs and such to figure things out.  I didn't 
> want to just say "use NFS" in this case, because I didn't want someone who 
> wasn't already sure about their setup to see that and run into problems, just 
> to be told "use HTTP or FTP."
>
>
> Mark
>
> --
> 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/

--
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: SLES 12 upgrade fails

[Mark Post]

>>> On 3/14/2018 at 06:20 PM, Marcy Cortes  
>>> wrote: 
> Victor has already gotten the networking part to work since the VNC portion 
> came up and and enough of the media was loaded to put up the license 
> acceptance and the disk activated

Hi, Marcy,

Yes, I know.  In the past, we've seen all sorts of installation failures that 
came down to things in the network or installation server not being quite 
right.  In those cases, I've always recommended using HTTP or FTP servers 
because it's much easier to get logs and such to figure things out.  I didn't 
want to just say "use NFS" in this case, because I didn't want someone who 
wasn't already sure about their setup to see that and run into problems, just 
to be told "use HTTP or FTP."


Mark

--
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: SLES 12 upgrade fails

[Marcy Cortes]

Victor has already gotten the networking part to work since the VNC portion 
came up and and enough of the media was loaded to put up the license acceptance 
and the disk activated




Sent with BlackBerry Work
(www.blackberry.com)

From: Mark Post <mp...@suse.com<mailto:mp...@suse.com>>
Date: Wednesday, Mar 14, 2018, 3:13 PM
To: LINUX-390@VM.MARIST.EDU 
<LINUX-390@VM.MARIST.EDU<mailto:LINUX-390@VM.MARIST.EDU>>
Subject: Re: [LINUX-390] SLES 12 upgrade fails

>>> On 3/13/2018 at 04:02 PM, Victor Echavarry <victor.echava...@evertecinc.com>
wrote:
> PARMFILE
>
> ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumb

For SLES12 you can delete everything on this line except for "TERM=dumb".

> hostip=10.23.11.246 netmask=255.255.248.0 gateway=10.23.11.193

You can specify the IP address this way, or as 10.23.11.246/21 and leave off 
the netmask. I would recommend adding "domain=evertecinc.com" or whatever 
domain name you use internally.

> nameserver=10.23.0.238 portname=none portno=0

Delete "portname=none" from this line.

> instnetdev=osa osainterface=qdio osamedium=eth layer2=1

Delete "osamedium-eth" from this line

> OSAHWaddr=02:78:C1:02:48:00

Specifying OSAHWaddr is almost always a bad idea, unless you're running in an 
LPAR.  If you're running as a z/VM guest, and you want "persistent" MAC 
addresses, specify MACID in USER DIRECT for each guest.

> readchannel=0.0.0360 writechannel=0.0.0361 datachannel=0.0.0362
> usevnc=1 vncpassword=vncpassw
> install=http://10.1.38.158/upgrade/SLE-12-SP3-Server-DVD-s390x-GM-DVD1.iso

If you know your network setup is working, it might be better to use 
"install=nfs://" instead of HTTP.  This will avoid the installer having to 
download the whole ISO image at once.  Alternatively, as Marcy recommended, you 
can loop-back mount the ISO image on the HTTP server so that you can then do 
this:
install=http://10.1.38.158/upgrade/


TERM=dumb
hostip=10.23.11.246/21 gateway=10.23.11.193 domain=evertecinc.com
nameserver=10.23.0.238 portno=0
instnetdev=osa osainterface=qdio layer2=1
OSAHWaddr=
readchannel=0.0.0360 writechannel=0.0.0361 datachannel=0.0.0362
usevnc=1 vncpassword=vncpassw
install=http://10.1.38.158/upgrade/SLE-12-SP3-Server-DVD-s390x-GM-DVD1.iso


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/

--
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: SLES 12 upgrade fails

[Mark Post]

>>> On 3/13/2018 at 04:02 PM, Victor Echavarry 
wrote: 
> PARMFILE
> 
> ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumb

For SLES12 you can delete everything on this line except for "TERM=dumb".

> hostip=10.23.11.246 netmask=255.255.248.0 gateway=10.23.11.193

You can specify the IP address this way, or as 10.23.11.246/21 and leave off 
the netmask. I would recommend adding "domain=evertecinc.com" or whatever 
domain name you use internally.

> nameserver=10.23.0.238 portname=none portno=0

Delete "portname=none" from this line.

> instnetdev=osa osainterface=qdio osamedium=eth layer2=1

Delete "osamedium-eth" from this line

> OSAHWaddr=02:78:C1:02:48:00

Specifying OSAHWaddr is almost always a bad idea, unless you're running in an 
LPAR.  If you're running as a z/VM guest, and you want "persistent" MAC 
addresses, specify MACID in USER DIRECT for each guest.

> readchannel=0.0.0360 writechannel=0.0.0361 datachannel=0.0.0362
> usevnc=1 vncpassword=vncpassw
> install=http://10.1.38.158/upgrade/SLE-12-SP3-Server-DVD-s390x-GM-DVD1.iso

If you know your network setup is working, it might be better to use 
"install=nfs://" instead of HTTP.  This will avoid the installer having to 
download the whole ISO image at once.  Alternatively, as Marcy recommended, you 
can loop-back mount the ISO image on the HTTP server so that you can then do 
this:
install=http://10.1.38.158/upgrade/


TERM=dumb
hostip=10.23.11.246/21 gateway=10.23.11.193 domain=evertecinc.com
nameserver=10.23.0.238 portno=0
instnetdev=osa osainterface=qdio layer2=1
OSAHWaddr=
readchannel=0.0.0360 writechannel=0.0.0361 datachannel=0.0.0362
usevnc=1 vncpassword=vncpassw
install=http://10.1.38.158/upgrade/SLE-12-SP3-Server-DVD-s390x-GM-DVD1.iso


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/

Re: SLES 12 upgrade fails

[Victor Echavarry]

We found the problem, the files were corrupted. We upload a new copy and solve 
the problem.

Thanks,

Victor Echavarry 
System Programmer
Operating Systems


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy 
Cortes
Sent: Wednesday, March 14, 2018 12:29 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES 12 upgrade fails

The problem is the .iso file. You will need to mount that -o loop on the 
webserver and serve out the content.



From: Victor Echavarry 
<victor.echava...@evertecinc.com<mailto:victor.echava...@evertecinc.com>>
Date: Tuesday, Mar 13, 2018, 6:52 PM
To: LINUX-390@VM.MARIST.EDU 
<LINUX-390@VM.MARIST.EDU<mailto:LINUX-390@VM.MARIST.EDU>>
Subject: [LINUX-390] SLES 12 upgrade fails

We are planning a upgrade of all our z/Linux guest from SLES 11 SP4 to SLES 12 
SP3. When executing the upgrade we receive the following message:

Failed to execute /init (error -2)
Kernel panic - not syncing: Requested init /linuxrc failed (error -2).
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.73-5-default #1
   1ee5fcc8 1ee5fd58 0002 
   1ee5fdf8 1ee5fd70 1ee5fd70 00260734
   00ad5ea8 007dc9ee 007ca056 000b
   1ee5fdb8 1ee5fd58  
   04001ee5ff48 00113c36 1ee5fd58 1ee5fdb8 Call 
Trace:
([<00113b2a>] show_trace+0xf2/0x140)  [<00113bea>] 
show_stack+0x72/0xf0  [<00439e7a>] dump_stack+0x82/0xb0  
[<0025f928>] panic+0xf0/0x228  [<0064b428>] 
kernel_init+0xc0/0x118  [<00654e2e>] kernel_thread_starter+0x6/0xc  
[<00654e28>] kernel_thread_starter+0x0/0xc

This are our configuration files:

SLES12   EXEC

/* REXX LOAD EXEC FOR SUSE Linux S/390 VM GUESTS */
/* LOADS SUSE Linux S/390 FILES INTO READER */ SAY ''
SAY 'LOADING SLES12 FILES INTO READER...'
'CP CLOSE PUN *'
'CP CLOSE RDR'
'PURGE RDR ALL'
'SPOOL PUNCH * RDR'
'PUNCH SLES12 Linux * (NOH'
'PUNCH PARMFILE 'USERID() ' * (NOHEADER'
'PUNCH SLES12 INITRD * (NOH'
'CHANGE RDR ALL KEEP NOHOLD'
'CP IPL 000C CLEAR'

PARMFILE

ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumb
hostip=10.23.11.246 netmask=255.255.248.0 gateway=10.23.11.193
nameserver=10.23.0.238 portname=none portno=0 instnetdev=osa osainterface=qdio 
osamedium=eth layer2=1
OSAHWaddr=02:78:C1:02:48:00
readchannel=0.0.0360 writechannel=0.0.0361 datachannel=0.0.0362
usevnc=1 vncpassword=vncpassw
install=http://10.1.38.158/upgrade/SLE-12-SP3-Server-DVD-s390x-GM-DVD1.iso

INITRD and LINUX

SLES12   INITRD   D1 F 80 333414   6512  3/09/18
SLES12   LINUXD1 F 80 139085   2438  3/09/18

Why it can't connect? Our z/VM version is 6.4

Regards,

Victor Echavarry

System Programmer

Operating Systems

EVERTEC, LLC








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

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

--
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: SLES 12 upgrade fails

[Marcy Cortes]

The problem is the .iso file. You will need to mount that -o loop on the 
webserver and serve out the content.



From: Victor Echavarry 
<victor.echava...@evertecinc.com<mailto:victor.echava...@evertecinc.com>>
Date: Tuesday, Mar 13, 2018, 6:52 PM
To: LINUX-390@VM.MARIST.EDU 
<LINUX-390@VM.MARIST.EDU<mailto:LINUX-390@VM.MARIST.EDU>>
Subject: [LINUX-390] SLES 12 upgrade fails

We are planning a upgrade of all our z/Linux guest from SLES 11 SP4 to SLES 12 
SP3. When executing the upgrade we receive the following message:

Failed to execute /init (error -2)
Kernel panic - not syncing: Requested init /linuxrc failed (error -2).
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.73-5-default #1
   1ee5fcc8 1ee5fd58 0002 
   1ee5fdf8 1ee5fd70 1ee5fd70 00260734
   00ad5ea8 007dc9ee 007ca056 000b
   1ee5fdb8 1ee5fd58  
   04001ee5ff48 00113c36 1ee5fd58 1ee5fdb8
Call Trace:
([<00113b2a>] show_trace+0xf2/0x140)
 [<00113bea>] show_stack+0x72/0xf0
 [<00439e7a>] dump_stack+0x82/0xb0
 [<0025f928>] panic+0xf0/0x228
 [<0064b428>] kernel_init+0xc0/0x118
 [<00654e2e>] kernel_thread_starter+0x6/0xc
 [<00654e28>] kernel_thread_starter+0x0/0xc

This are our configuration files:

SLES12   EXEC

/* REXX LOAD EXEC FOR SUSE Linux S/390 VM GUESTS */
/* LOADS SUSE Linux S/390 FILES INTO READER */
SAY ''
SAY 'LOADING SLES12 FILES INTO READER...'
'CP CLOSE PUN *'
'CP CLOSE RDR'
'PURGE RDR ALL'
'SPOOL PUNCH * RDR'
'PUNCH SLES12 Linux * (NOH'
'PUNCH PARMFILE 'USERID() ' * (NOHEADER'
'PUNCH SLES12 INITRD * (NOH'
'CHANGE RDR ALL KEEP NOHOLD'
'CP IPL 000C CLEAR'

PARMFILE

ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumb
hostip=10.23.11.246 netmask=255.255.248.0 gateway=10.23.11.193
nameserver=10.23.0.238 portname=none portno=0
instnetdev=osa osainterface=qdio osamedium=eth layer2=1
OSAHWaddr=02:78:C1:02:48:00
readchannel=0.0.0360 writechannel=0.0.0361 datachannel=0.0.0362
usevnc=1 vncpassword=vncpassw
install=http://10.1.38.158/upgrade/SLE-12-SP3-Server-DVD-s390x-GM-DVD1.iso

INITRD and LINUX

SLES12   INITRD   D1 F 80 333414   6512  3/09/18
SLES12   LINUXD1 F 80 139085   2438  3/09/18

Why it can't connect? Our z/VM version is 6.4

Regards,

Victor Echavarry

System Programmer

Operating Systems

EVERTEC, LLC








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

--
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: SLES 12 upgrade fails

[Michael MacIsaac]

Victor,

Does the virtual machine have at least 1G of memory?

-Mike

On Tue, Mar 13, 2018 at 4:02 PM, Victor Echavarry <
victor.echava...@evertecinc.com> wrote:

> We are planning a upgrade of all our z/Linux guest from SLES 11 SP4 to
> SLES 12 SP3. When executing the upgrade we receive the following message:
>
> Failed to execute /init (error -2)
> Kernel panic - not syncing: Requested init /linuxrc failed (error -2).
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.73-5-default #1
>1ee5fcc8 1ee5fd58 0002 
>1ee5fdf8 1ee5fd70 1ee5fd70 00260734
>00ad5ea8 007dc9ee 007ca056 000b
>1ee5fdb8 1ee5fd58  
>04001ee5ff48 00113c36 1ee5fd58 1ee5fdb8
> Call Trace:
> ([<00113b2a>] show_trace+0xf2/0x140)
>  [<00113bea>] show_stack+0x72/0xf0
>  [<00439e7a>] dump_stack+0x82/0xb0
>  [<0025f928>] panic+0xf0/0x228
>  [<0064b428>] kernel_init+0xc0/0x118
>  [<00654e2e>] kernel_thread_starter+0x6/0xc
>  [<00654e28>] kernel_thread_starter+0x0/0xc
>
> This are our configuration files:
>
> SLES12   EXEC
>
> /* REXX LOAD EXEC FOR SUSE Linux S/390 VM GUESTS */
> /* LOADS SUSE Linux S/390 FILES INTO READER */
> SAY ''
> SAY 'LOADING SLES12 FILES INTO READER...'
> 'CP CLOSE PUN *'
> 'CP CLOSE RDR'
> 'PURGE RDR ALL'
> 'SPOOL PUNCH * RDR'
> 'PUNCH SLES12 Linux * (NOH'
> 'PUNCH PARMFILE 'USERID() ' * (NOHEADER'
> 'PUNCH SLES12 INITRD * (NOH'
> 'CHANGE RDR ALL KEEP NOHOLD'
> 'CP IPL 000C CLEAR'
>
> PARMFILE
>
> ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumb
> hostip=10.23.11.246 netmask=255.255.248.0 gateway=10.23.11.193
> nameserver=10.23.0.238 portname=none portno=0
> instnetdev=osa osainterface=qdio osamedium=eth layer2=1
> OSAHWaddr=02:78:C1:02:48:00
> readchannel=0.0.0360 writechannel=0.0.0361 datachannel=0.0.0362
> usevnc=1 vncpassword=vncpassw
> install=http://10.1.38.158/upgrade/SLE-12-SP3-Server-DVD-s390x-GM-DVD1.iso
>
> INITRD and LINUX
>
> SLES12   INITRD   D1 F 80 333414   6512  3/09/18
> SLES12   LINUXD1 F 80 139085   2438  3/09/18
>
> Why it can't connect? Our z/VM version is 6.4
>
> Regards,
>
> Victor Echavarry
>
> System Programmer
>
> Operating Systems
>
> EVERTEC, LLC
>
>
>
>
>
>
>
>
> --
> 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/
>



--
 -Mike MacIsaac

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

SLES 12 upgrade fails

[Victor Echavarry]

We are planning a upgrade of all our z/Linux guest from SLES 11 SP4 to SLES 12 
SP3. When executing the upgrade we receive the following message:

Failed to execute /init (error -2)
Kernel panic - not syncing: Requested init /linuxrc failed (error -2).
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.73-5-default #1
   1ee5fcc8 1ee5fd58 0002 
   1ee5fdf8 1ee5fd70 1ee5fd70 00260734
   00ad5ea8 007dc9ee 007ca056 000b
   1ee5fdb8 1ee5fd58  
   04001ee5ff48 00113c36 1ee5fd58 1ee5fdb8
Call Trace:
([<00113b2a>] show_trace+0xf2/0x140)
 [<00113bea>] show_stack+0x72/0xf0
 [<00439e7a>] dump_stack+0x82/0xb0
 [<0025f928>] panic+0xf0/0x228
 [<0064b428>] kernel_init+0xc0/0x118
 [<00654e2e>] kernel_thread_starter+0x6/0xc
 [<00654e28>] kernel_thread_starter+0x0/0xc

This are our configuration files:

SLES12   EXEC

/* REXX LOAD EXEC FOR SUSE Linux S/390 VM GUESTS */
/* LOADS SUSE Linux S/390 FILES INTO READER */
SAY ''
SAY 'LOADING SLES12 FILES INTO READER...'
'CP CLOSE PUN *'
'CP CLOSE RDR'
'PURGE RDR ALL'
'SPOOL PUNCH * RDR'
'PUNCH SLES12 Linux * (NOH'
'PUNCH PARMFILE 'USERID() ' * (NOHEADER'
'PUNCH SLES12 INITRD * (NOH'
'CHANGE RDR ALL KEEP NOHOLD'
'CP IPL 000C CLEAR'

PARMFILE

ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumb
hostip=10.23.11.246 netmask=255.255.248.0 gateway=10.23.11.193
nameserver=10.23.0.238 portname=none portno=0
instnetdev=osa osainterface=qdio osamedium=eth layer2=1
OSAHWaddr=02:78:C1:02:48:00
readchannel=0.0.0360 writechannel=0.0.0361 datachannel=0.0.0362
usevnc=1 vncpassword=vncpassw
install=http://10.1.38.158/upgrade/SLE-12-SP3-Server-DVD-s390x-GM-DVD1.iso

INITRD and LINUX

SLES12   INITRD   D1 F 80 333414   6512  3/09/18
SLES12   LINUXD1 F 80 139085   2438  3/09/18

Why it can't connect? Our z/VM version is 6.4

Regards,

Victor Echavarry

System Programmer

Operating Systems

EVERTEC, LLC








--
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: Upgrade from SLES 11 to SLES 12

[Marcy Cortes]

For 16 the command is "zypper packages --orphaned"

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy 
Cortes
Sent: Friday, February 9, 2018 4:37 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Upgrade from SLES 11 to SLES 12

My preferred method is to replace the servers!

First read all of this  (never mind that x86 is in the URL, it does apply to 
both).
https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12-SP3/
Don't forget to check that all of your SW supports it.

While you can upgrade, new servers are less risky and allows you the 
opportunity to backout really easily if something goes wrong.  
We will do just a tiny bit of upgrading here since our applications tend to 
agree about the risk.
It also affords them the opportunity to easily move to new versions of the 
software they might have installed on the servers.
If you don't have things that freak out about a hostname change (like 
authentication products/certificates/etc) you can do the old switcheroo.  Put 
up the new server at another IP and temp hostname and then when all ready, 
shutdown the old server and change the new one's hostname and IP to the old 
ones.

Your Oracle people are probably used to replacement servers as well.   They 
will just unload and reload things.   

My checklist for upgrades includes
1. Backup entire server
2. Enlarge / file system and /usr
3. Shutdown security sw
4. Set root password to something you know
5. Edit /etc/zypp/zypp.conf and change solver.onlyRequires = true   (avoids 
pulling in "recommended" packages - many of which I did not want on our servers)
and comment out # multiversion = provides:multiversion(kernel)
6. Do a chkconfig -l and shutdown and turn off everything that is not SUSE
7. Save /etc/sysctl.conf settings you may have turned on
8. shutdown
9. Login to the virtual machine.  Be in CMS
10. punch files and start the installation - how to do this is documented in 
the installation guide
11.  Choose, Start Installation, Upgrade, configure your network, 
12.  At this point I choose VNC.  You may have another preference.
13.  Click what you need.  I always add the System z HW Crypto support
14.  Go get coffee
15. It will eventually reboot it self
16. When it comes back up, figure out if you have orphaned packages and remove 
- they will never be patched!
17. Remove other things that your installation might not want installed that 
came along for the ride
18. Join it to SMT or SUSE Manager or whatever you use and  zypper update it
19. Upgrade other things that need it - mine need security sw upgrades
20. Customize your stuff. Again, ymmv.  Here's my list
/etc/sysconfig/postfix
/etc/sysctl.conf
/etc/login.defs
/etc/default/grub
/etc/profile.d/WF.sh
/etc/sysconfig/displaymanager
/etc/sysconfig/security
/etc/permissions.local
/etc/sysconfig/storage
/etc/idmapd.conf 
/etc/systemd/system/serial-getty@ttyS0.service
/etc/udev/rules.d/51-dasd-0.0.ff00.rules
/etc/udev/rules.d/51-dasd-0.0.ff01.rules
/etc/udev/rules.d/51-dasd-0.0.ff02.rules
/etc/udev/rules.d/51-dasd-0.0.ff03.rules
/etc/zypp/zypp.conf
/etc/sysconfig/proxy
/etc/snmp/snmpd.conf
/etc/ntp.conf
/etc/sysconfig/nfs
/etc/default/useradd
/etc/sysconfig/cron

 
config.postfix
systemctl enable snmpd.service
systemctl enable ntpd.service
systemctl disable display-manager.service
systemctl set-default multi-user.target

grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install
dracut -f 
chkstat --system --set
mkdir /var/log/journal

21. Turn your services back on
22. Special considerations for GPFS if you have that (kernel cmdline and apply 
a fix pack to get its systemd stuff)
23.  Reboot again.  May sure everything starts OK.

So 2-3 hours maybe per server.  You'd be looking at a couple of weeks, less 
maybe with practice.
If you have a good deploy process, you can probably build 88 in a day or two.  
And then get the app people and dba's to do their stuff.





-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Victor 
Echavarry
Sent: Thursday, February 8, 2018 12:56 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Upgrade from SLES 11 to SLES 12

We have 88 guests with SLES 11SP4 on z/VM 6.4, the majority with oracle 11 and 
12. The cookbook only show how to made a new installation. We want to know is 
there a way to upgrade those servers to SLES12. If true:

  1.  How can we achieved it. DVD, NFS, FTP.
  2.  How many servers can upgrade at the same time.
  3.  This upgrade can be done without graphical interface.
  4.  This could be online or offline.

Regards,

Victor Echavarry

System Programmer

Operating Systems


evertecinc.com



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

Re: Upgrade from SLES 11 to SLES 12

[Marcy Cortes]

My preferred method is to replace the servers!

First read all of this  (never mind that x86 is in the URL, it does apply to 
both).
https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12-SP3/
Don't forget to check that all of your SW supports it.

While you can upgrade, new servers are less risky and allows you the 
opportunity to backout really easily if something goes wrong.  
We will do just a tiny bit of upgrading here since our applications tend to 
agree about the risk.
It also affords them the opportunity to easily move to new versions of the 
software they might have installed on the servers.
If you don't have things that freak out about a hostname change (like 
authentication products/certificates/etc) you can do the old switcheroo.  Put 
up the new server at another IP and temp hostname and then when all ready, 
shutdown the old server and change the new one's hostname and IP to the old 
ones.

Your Oracle people are probably used to replacement servers as well.   They 
will just unload and reload things.   

My checklist for upgrades includes
1. Backup entire server
2. Enlarge / file system and /usr
3. Shutdown security sw
4. Set root password to something you know
5. Edit /etc/zypp/zypp.conf and change solver.onlyRequires = true   (avoids 
pulling in "recommended" packages - many of which I did not want on our servers)
and comment out # multiversion = provides:multiversion(kernel)
6. Do a chkconfig -l and shutdown and turn off everything that is not SUSE
7. Save /etc/sysctl.conf settings you may have turned on
8. shutdown
9. Login to the virtual machine.  Be in CMS
10. punch files and start the installation - how to do this is documented in 
the installation guide
11.  Choose, Start Installation, Upgrade, configure your network, 
12.  At this point I choose VNC.  You may have another preference.
13.  Click what you need.  I always add the System z HW Crypto support
14.  Go get coffee
15. It will eventually reboot it self
16. When it comes back up, figure out if you have orphaned packages and remove 
- they will never be patched!
17. Remove other things that your installation might not want installed that 
came along for the ride
18. Join it to SMT or SUSE Manager or whatever you use and  zypper update it
19. Upgrade other things that need it - mine need security sw upgrades
20. Customize your stuff. Again, ymmv.  Here's my list
/etc/sysconfig/postfix
/etc/sysctl.conf
/etc/login.defs
/etc/default/grub
/etc/profile.d/WF.sh
/etc/sysconfig/displaymanager
/etc/sysconfig/security
/etc/permissions.local
/etc/sysconfig/storage
/etc/idmapd.conf 
/etc/systemd/system/serial-getty@ttyS0.service
/etc/udev/rules.d/51-dasd-0.0.ff00.rules
/etc/udev/rules.d/51-dasd-0.0.ff01.rules
/etc/udev/rules.d/51-dasd-0.0.ff02.rules
/etc/udev/rules.d/51-dasd-0.0.ff03.rules
/etc/zypp/zypp.conf
/etc/sysconfig/proxy
/etc/snmp/snmpd.conf
/etc/ntp.conf
/etc/sysconfig/nfs
/etc/default/useradd
/etc/sysconfig/cron

 
config.postfix
systemctl enable snmpd.service
systemctl enable ntpd.service
systemctl disable display-manager.service
systemctl set-default multi-user.target

grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install
dracut -f 
chkstat --system --set
mkdir /var/log/journal

21. Turn your services back on
22. Special considerations for GPFS if you have that (kernel cmdline and apply 
a fix pack to get its systemd stuff)
23.  Reboot again.  May sure everything starts OK.

So 2-3 hours maybe per server.  You'd be looking at a couple of weeks, less 
maybe with practice.
If you have a good deploy process, you can probably build 88 in a day or two.  
And then get the app people and dba's to do their stuff.





-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Victor 
Echavarry
Sent: Thursday, February 8, 2018 12:56 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Upgrade from SLES 11 to SLES 12

We have 88 guests with SLES 11SP4 on z/VM 6.4, the majority with oracle 11 and 
12. The cookbook only show how to made a new installation. We want to know is 
there a way to upgrade those servers to SLES12. If true:

  1.  How can we achieved it. DVD, NFS, FTP.
  2.  How many servers can upgrade at the same time.
  3.  This upgrade can be done without graphical interface.
  4.  This could be online or offline.

Regards,

Victor Echavarry

System Programmer

Operating Systems


evertecinc.com



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

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.

Upgrade from SLES 11 to SLES 12

[Victor Echavarry]

We have 88 guests with SLES 11SP4 on z/VM 6.4, the majority with oracle 11 and 
12. The cookbook only show how to made a new installation. We want to know is 
there a way to upgrade those servers to SLES12. If true:

  1.  How can we achieved it. DVD, NFS, FTP.
  2.  How many servers can upgrade at the same time.
  3.  This upgrade can be done without graphical interface.
  4.  This could be online or offline.

Regards,

Victor Echavarry

System Programmer

Operating Systems


evertecinc.com



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

SUSE SLES 12 missing PHP extensions

[Aria Bamdad]

Hi,



I have an application that requires the PHP-Tidy extension among others.
Previously with SLES 11, this extension, among others was provided by SUSE
for PHP 5.2 that came with SLES 11.  Now with SLES 12, PHP 5.5 and 7 are
available but for some unknown reason, this extension and other were left
out.  According to PHP documentation, the PHP-Tidy extension is now bundled
with PHP and is available using the --with-tidy configure option.  However,
the only way to do this is to rebuild PHP from source again.



I have had a ticket open with SUSE support for over a month and they are
dragging their feet and not coming up with a solution.  This is crazy.
Anyone else has had any issue with this and other PHP extensions that are
part of the base and missing on SLES 12?


Thanks,

Aria


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

Process to clone SLES 12 guest installed on LUN?

[Rodery, Floyd A CIV DISA SEL2 (US)]

In reference to some of the previous email traffic "Gold On LUN", is there a 
documented method to clone a SLES12 server that is installed on an FCP LUN and 
create a new guest using the cloned LUN?  I know this is routinely done with 
EDEVs, but haven't seen much relating to accomplishing the same using a LUN?

Install gold copy image on a LUN (SLES 12 w/LVM).
Shut the gold copy server down, clone the FCP LUN, create a new zVM guest and 
use the cloned FCP LUN instead of doing a new installation again?

Also not sure if there are "tools" out there that accomplish this, I've seen 
reference to OpenStack, etc?

Floyd Rodery


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


smime.p7s
Description: S/MIME cryptographic signature

Re: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

[Mark Post]

>>> On 8/24/2017 at 01:17 PM, Harley Linker <harley.lin...@ensono.com> wrote: 

> The deployment guide I refenced is the one I obtained from the SLES 12 SP2 
> DVD1 iso file.  I did find the parameter in 
> https://www.suse.com/documentation/sles-12/singlehtml/book_sle_deployment/boo
> k_sle_deployment.html#sec.appdendix.parm.general.

Just, FYI...  SUSE does update the documentation we ship on the ISO images, but 
we can't/don't regenerate those images when such an update happens.  We do make 
the updates to the online documentation, however.  I talked to our 
documentation team, and in this particular example, a bug was reported after 
the ISO images were created so only the online documentation was fixed.

The information on the ISO images is as current as possible when they're 
created.  We include them for people to use in case they don't have an internet 
connection to access them online.  But if you want to make sure you have the 
latest and greatest, https://www.suse.com/documentation/ is where you want to 
look.


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/

Re: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

[Mark Post]

>>> On 8/24/2017 at 12:23 PM, Harley Linker  wrote: 
> I am using a PARMFILE containing the following (sanitized):
> ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc term=dumb
> vmpoff=logoff hostname= mf-syssoft1 hostip=10.17.1.xxx
> gateway=10.17.1.129 nameserver=999.24.8.126
> instnetdev=osa osainterface=qdio layer2=1 portno=0
> netmask=255.255.255.192 broadcast=10.17.1.255
> readchannel=0.0.1f00 writechannel=0.0.1f01 datachannel=0.0.1f02
> install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1
> ssh=1 ssh.password= linuxrclog=/dev/console
> manual=0

You can clean this up a little bit.  Also, by adding "OSAHWAddr=" to it, you 
won't get prompted for it by the installer.
term=dumb vmpoff=logoff hostname= mf-syssoft1 hostip=10.17.1.xxx
usessh=1 sshpassword= OSAHWaddr=
gateway=10.17.1.129 nameserver=999.24.8.126 netmask=255.255.255.192
instnetdev=osa osainterface=qdio layer2=1 portno=0
readchannel=0.0.1f00 writechannel=0.0.1f01 datachannel=0.0.1f02
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1
linuxrclog=/dev/console manual=0

If you have a DHCP server that is set up to handle your guests, you can 
simplify it even more:
term=dumb vmpoff=logoff
usessh=1 sshpassword= 
dhcp portno=0 instnetdev=osa osainterface=qdio layer2=1 OSAHWaddr=
readchannel=0.0.1f00 writechannel=0.0.1f01 datachannel=0.0.1f02
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1
linuxrclog=/dev/console manual=0


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/

Re: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

[Aria Bamdad]

Yes, thanks.  The one on the DVD is perhaps outdated.

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Harley 
Linker
Sent: Thursday, August 24, 2017 1:17 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

Aria,

The deployment guide I refenced is the one I obtained from the SLES 12 SP2 DVD1 
iso file.  I did find the parameter in 
https://www.suse.com/documentation/sles-12/singlehtml/book_sle_deployment/book_sle_deployment.html#sec.appdendix.parm.general.

Thanks again!


Harley

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Aria 
Bamdad
Sent: Thursday, August 24, 2017 11:37 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

Hi Harley,

My environment is not the same as yours and I don't use a complete parameter 
file like you do but I noticed that you said you are upgrading from 11 to 12, 
but I don't see the 'upgrade=1' parameter among your parameter list.

The SUSE upgrade manual for z says you need that parameter when you upgrade 
rather than install from scratch.  Perhaps that's  why yast wanted to format 
your volumes.

Also, when you don't use a more complete param file, you do get that initial 
menu.  When you are upgrading an existing system, I select 'Install' on the 
first menu and then 'Upgrade' on the next menu.  This second menu is the menu 
you describe below.

Perhaps what you are missing is just the 'upgrade=1' parameter in your param 
file.

Aria

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Harley 
Linker
Sent: Thursday, August 24, 2017 12:23 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

Hi,

I am looking to upgrade some of my z/VM based servers from SLES 11 SP4 to SLES 
12 SP2 and am wondering if this is possible on System z.

My guest is defined as:
PROFILE LNXDFLT
 LOGONBY ...
 IPL CMS PARM AUTOCR
 CONSOLE 009 3215 T
 SPOOL 00C 2540 READER A
 SPOOL 00D 2540 PUNCH A
 SPOOL 00E 1403 A
 LINK MAINT 190 190 RR
 LINK MAINT 19D 19D RR
 LINK MAINT 19E 19E RR
 LINK LNXMAINT 191 191 RR


USER SYSSOFT1  3074M 3074M G
 INCLUDE LNXDFLT
 NICDEF 1F00 TYPE QDIO LAN SYSTEM VSWINT1  MDISK 200 3390 001 10016 LN150D MR 
ALL SOME FEW  /
 MDISK 201 FB-512 V-DISK 524288  WV   SWAP
MDISK 990 3390 001 10016 LN150E MR ALL SOME FEW  /OPT MDISK 991 3390 001 10016 
LN150F MR ALL SOME FEW  /OPT

The 200 disk is the boot volume, 201 is a virtual swap disk, and 990 and 991 
are an LV mounted to /opt.

I am using a PARMFILE containing the following (sanitized):
ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc term=dumb vmpoff=logoff 
hostname= mf-syssoft1 hostip=10.17.1.xxx
gateway=10.17.1.129 nameserver=999.24.8.126 instnetdev=osa osainterface=qdio 
layer2=1 portno=0
netmask=255.255.255.192 broadcast=10.17.1.255
readchannel=0.0.1f00 writechannel=0.0.1f01 datachannel=0.0.1f02
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1
ssh=1 ssh.password= linuxrclog=/dev/console
manual=0

I begin the installation by logging onto the SYSSOFT1 guest (which already has 
SLES 11 SP4 installed).  I interrupt the Linux boot with #cp I cms acc (noprof

I then run the SLES12 EXEC which pulls in the PARMFILE above.  The only prompts 
I received on the console are for Specifying a MAC address is optional.
In most cases letting it default is the correct choice.
Provide one only if you know it is truly necessary.
Optional MAC address. (Enter '+++' to abort).

When the installation system finished booting, I PuTTYed into another test 
server and 'ssh -X root@10.17.1.156<mailto:root@10.17.1.156>', replied with the 
password (the one specified in the PARMFILE), then invoked YaST.

I went thru all of the screens and specified what I needed to but when I got to 
the last screen and selected [Install] I received a pop-up that my disk would 
be reformatted and I would lose all of the data that was on it.

I am asking in that I was working with Novell support yesterday and we 
terminated the YaST portion of the install by slecting [Abort].  On the console 
(the VM screen) we received the following:
Start Installation

0) <-- Back <--
1) Installation
2) Upgrade
3) Rescue System
4) Boot Installed System
5) Network Setup

Is there a way to modify the PARMFILE to specify that I wasn't to perform an 
upgrade-in-place?  Do I need to use a PARMFILE with a minimal set of 
parameters?  I tried to change the 
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd
to
upgrade=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1.

The installation system couldn't find the SLES 12 repository.


Thank you.


Harley


Harley Linker Jr.
Sr. Systems Programmer
Ensono
e: harley.lin...@ensono.com<mailto:harley.lin...@ensono.com>
o: 630.944.5111

www.ensono.com<http://www.ensono.com/>


(c) 2017 Ensono, LP. All rights reserved. Ensono is a

Re: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

[Harley Linker]

Aria,

The deployment guide I refenced is the one I obtained from the SLES 12 SP2 DVD1 
iso file.  I did find the parameter in 
https://www.suse.com/documentation/sles-12/singlehtml/book_sle_deployment/book_sle_deployment.html#sec.appdendix.parm.general.

Thanks again!


Harley

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Aria 
Bamdad
Sent: Thursday, August 24, 2017 11:37 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

Hi Harley,

My environment is not the same as yours and I don't use a complete parameter 
file like you do but I noticed that you said you are upgrading from 11 to 12, 
but I don't see the 'upgrade=1' parameter among your parameter list.

The SUSE upgrade manual for z says you need that parameter when you upgrade 
rather than install from scratch.  Perhaps that's  why yast wanted to format 
your volumes.

Also, when you don't use a more complete param file, you do get that initial 
menu.  When you are upgrading an existing system, I select 'Install' on the 
first menu and then 'Upgrade' on the next menu.  This second menu is the menu 
you describe below.

Perhaps what you are missing is just the 'upgrade=1' parameter in your param 
file.

Aria

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Harley 
Linker
Sent: Thursday, August 24, 2017 12:23 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

Hi,

I am looking to upgrade some of my z/VM based servers from SLES 11 SP4 to SLES 
12 SP2 and am wondering if this is possible on System z.

My guest is defined as:
PROFILE LNXDFLT
 LOGONBY ...
 IPL CMS PARM AUTOCR
 CONSOLE 009 3215 T
 SPOOL 00C 2540 READER A
 SPOOL 00D 2540 PUNCH A
 SPOOL 00E 1403 A
 LINK MAINT 190 190 RR
 LINK MAINT 19D 19D RR
 LINK MAINT 19E 19E RR
 LINK LNXMAINT 191 191 RR


USER SYSSOFT1  3074M 3074M G
 INCLUDE LNXDFLT
 NICDEF 1F00 TYPE QDIO LAN SYSTEM VSWINT1  MDISK 200 3390 001 10016 LN150D MR 
ALL SOME FEW  /
 MDISK 201 FB-512 V-DISK 524288  WV   SWAP
MDISK 990 3390 001 10016 LN150E MR ALL SOME FEW  /OPT MDISK 991 3390 001 10016 
LN150F MR ALL SOME FEW  /OPT

The 200 disk is the boot volume, 201 is a virtual swap disk, and 990 and 991 
are an LV mounted to /opt.

I am using a PARMFILE containing the following (sanitized):
ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc term=dumb vmpoff=logoff 
hostname= mf-syssoft1 hostip=10.17.1.xxx
gateway=10.17.1.129 nameserver=999.24.8.126 instnetdev=osa osainterface=qdio 
layer2=1 portno=0
netmask=255.255.255.192 broadcast=10.17.1.255
readchannel=0.0.1f00 writechannel=0.0.1f01 datachannel=0.0.1f02
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1
ssh=1 ssh.password= linuxrclog=/dev/console
manual=0

I begin the installation by logging onto the SYSSOFT1 guest (which already has 
SLES 11 SP4 installed).  I interrupt the Linux boot with #cp I cms acc (noprof

I then run the SLES12 EXEC which pulls in the PARMFILE above.  The only prompts 
I received on the console are for Specifying a MAC address is optional.
In most cases letting it default is the correct choice.
Provide one only if you know it is truly necessary.
Optional MAC address. (Enter '+++' to abort).

When the installation system finished booting, I PuTTYed into another test 
server and 'ssh -X root@10.17.1.156<mailto:root@10.17.1.156>', replied with the 
password (the one specified in the PARMFILE), then invoked YaST.

I went thru all of the screens and specified what I needed to but when I got to 
the last screen and selected [Install] I received a pop-up that my disk would 
be reformatted and I would lose all of the data that was on it.

I am asking in that I was working with Novell support yesterday and we 
terminated the YaST portion of the install by slecting [Abort].  On the console 
(the VM screen) we received the following:
Start Installation

0) <-- Back <--
1) Installation
2) Upgrade
3) Rescue System
4) Boot Installed System
5) Network Setup

Is there a way to modify the PARMFILE to specify that I wasn't to perform an 
upgrade-in-place?  Do I need to use a PARMFILE with a minimal set of 
parameters?  I tried to change the 
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd
to
upgrade=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1.

The installation system couldn't find the SLES 12 repository.


Thank you.


Harley


Harley Linker Jr.
Sr. Systems Programmer
Ensono
e: harley.lin...@ensono.com<mailto:harley.lin...@ensono.com>
o: 630.944.5111

www.ensono.com<http://www.ensono.com/>


(c) 2017 Ensono, LP. All rights reserved. Ensono is a trademark of Ensono, LP. 
The information contained in this communication is confidential, is intended 
only for the use of the recipient named above, and may be legally privileged. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination,

Re: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

[Harley Linker]

Aria,

Thank you!  That parameter for the PARMFILE is not in the deployment manual but 
has changed the installation screens that are presented.  I did find it there 
to be added to the GRUB legacy configuration file.

The update=1 PARMFILE parameter is exactly what I was looking for.  Thank you.


Harley

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Aria 
Bamdad
Sent: Thursday, August 24, 2017 11:37 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

Hi Harley,

My environment is not the same as yours and I don't use a complete parameter 
file like you do but I noticed that you said you are upgrading from 11 to 12, 
but I don't see the 'upgrade=1' parameter among your parameter list.

The SUSE upgrade manual for z says you need that parameter when you upgrade 
rather than install from scratch.  Perhaps that's  why yast wanted to format 
your volumes.

Also, when you don't use a more complete param file, you do get that initial 
menu.  When you are upgrading an existing system, I select 'Install' on the 
first menu and then 'Upgrade' on the next menu.  This second menu is the menu 
you describe below.

Perhaps what you are missing is just the 'upgrade=1' parameter in your param 
file.

Aria

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Harley 
Linker
Sent: Thursday, August 24, 2017 12:23 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

Hi,

I am looking to upgrade some of my z/VM based servers from SLES 11 SP4 to SLES 
12 SP2 and am wondering if this is possible on System z.

My guest is defined as:
PROFILE LNXDFLT
 LOGONBY ...
 IPL CMS PARM AUTOCR
 CONSOLE 009 3215 T
 SPOOL 00C 2540 READER A
 SPOOL 00D 2540 PUNCH A
 SPOOL 00E 1403 A
 LINK MAINT 190 190 RR
 LINK MAINT 19D 19D RR
 LINK MAINT 19E 19E RR
 LINK LNXMAINT 191 191 RR


USER SYSSOFT1  3074M 3074M G
 INCLUDE LNXDFLT
 NICDEF 1F00 TYPE QDIO LAN SYSTEM VSWINT1  MDISK 200 3390 001 10016 LN150D MR 
ALL SOME FEW  /
 MDISK 201 FB-512 V-DISK 524288  WV   SWAP
MDISK 990 3390 001 10016 LN150E MR ALL SOME FEW  /OPT MDISK 991 3390 001 10016 
LN150F MR ALL SOME FEW  /OPT

The 200 disk is the boot volume, 201 is a virtual swap disk, and 990 and 991 
are an LV mounted to /opt.

I am using a PARMFILE containing the following (sanitized):
ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc term=dumb vmpoff=logoff 
hostname= mf-syssoft1 hostip=10.17.1.xxx
gateway=10.17.1.129 nameserver=999.24.8.126 instnetdev=osa osainterface=qdio 
layer2=1 portno=0
netmask=255.255.255.192 broadcast=10.17.1.255
readchannel=0.0.1f00 writechannel=0.0.1f01 datachannel=0.0.1f02
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1
ssh=1 ssh.password= linuxrclog=/dev/console
manual=0

I begin the installation by logging onto the SYSSOFT1 guest (which already has 
SLES 11 SP4 installed).  I interrupt the Linux boot with #cp I cms acc (noprof

I then run the SLES12 EXEC which pulls in the PARMFILE above.  The only prompts 
I received on the console are for Specifying a MAC address is optional.
In most cases letting it default is the correct choice.
Provide one only if you know it is truly necessary.
Optional MAC address. (Enter '+++' to abort).

When the installation system finished booting, I PuTTYed into another test 
server and 'ssh -X root@10.17.1.156<mailto:root@10.17.1.156>', replied with the 
password (the one specified in the PARMFILE), then invoked YaST.

I went thru all of the screens and specified what I needed to but when I got to 
the last screen and selected [Install] I received a pop-up that my disk would 
be reformatted and I would lose all of the data that was on it.

I am asking in that I was working with Novell support yesterday and we 
terminated the YaST portion of the install by slecting [Abort].  On the console 
(the VM screen) we received the following:
Start Installation

0) <-- Back <--
1) Installation
2) Upgrade
3) Rescue System
4) Boot Installed System
5) Network Setup

Is there a way to modify the PARMFILE to specify that I wasn't to perform an 
upgrade-in-place?  Do I need to use a PARMFILE with a minimal set of 
parameters?  I tried to change the 
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd
to
upgrade=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1.

The installation system couldn't find the SLES 12 repository.


Thank you.


Harley


Harley Linker Jr.
Sr. Systems Programmer
Ensono
e: harley.lin...@ensono.com<mailto:harley.lin...@ensono.com>
o: 630.944.5111

www.ensono.com<http://www.ensono.com/>


(c) 2017 Ensono, LP. All rights reserved. Ensono is a trademark of Ensono, LP. 
The information contained in this communication is confidential, is intended 
only for the use of the recipient named above, and may be legally privileged. 
If the reader of this message is not the intended recipient, you are hereby 
notifie

Re: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

[Aria Bamdad]

Hi Harley,

My environment is not the same as yours and I don't use a complete parameter
file like you do but I noticed that you said you are upgrading from 11 to
12, but I don't see the 'upgrade=1' parameter among your parameter list.

The SUSE upgrade manual for z says you need that parameter when you upgrade
rather than install from scratch.  Perhaps that's  why yast wanted to format
your volumes.

Also, when you don't use a more complete param file, you do get that initial
menu.  When you are upgrading an existing system, I select 'Install' on the
first menu and then 'Upgrade' on the next menu.  This second menu is the
menu you describe below.

Perhaps what you are missing is just the 'upgrade=1' parameter in your param
file.

Aria

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Harley
Linker
Sent: Thursday, August 24, 2017 12:23 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

Hi,

I am looking to upgrade some of my z/VM based servers from SLES 11 SP4 to
SLES 12 SP2 and am wondering if this is possible on System z.

My guest is defined as:
PROFILE LNXDFLT
 LOGONBY ...
 IPL CMS PARM AUTOCR
 CONSOLE 009 3215 T
 SPOOL 00C 2540 READER A
 SPOOL 00D 2540 PUNCH A
 SPOOL 00E 1403 A
 LINK MAINT 190 190 RR
 LINK MAINT 19D 19D RR
 LINK MAINT 19E 19E RR
 LINK LNXMAINT 191 191 RR


USER SYSSOFT1  3074M 3074M G
 INCLUDE LNXDFLT
 NICDEF 1F00 TYPE QDIO LAN SYSTEM VSWINT1
 MDISK 200 3390 001 10016 LN150D MR ALL SOME FEW  /
 MDISK 201 FB-512 V-DISK 524288  WV   SWAP
MDISK 990 3390 001 10016 LN150E MR ALL SOME FEW  /OPT
MDISK 991 3390 001 10016 LN150F MR ALL SOME FEW  /OPT

The 200 disk is the boot volume, 201 is a virtual swap disk, and 990 and 991
are an LV mounted to /opt.

I am using a PARMFILE containing the following (sanitized):
ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc term=dumb
vmpoff=logoff hostname= mf-syssoft1 hostip=10.17.1.xxx
gateway=10.17.1.129 nameserver=999.24.8.126
instnetdev=osa osainterface=qdio layer2=1 portno=0
netmask=255.255.255.192 broadcast=10.17.1.255
readchannel=0.0.1f00 writechannel=0.0.1f01 datachannel=0.0.1f02
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1
ssh=1 ssh.password= linuxrclog=/dev/console
manual=0

I begin the installation by logging onto the SYSSOFT1 guest (which already
has SLES 11 SP4 installed).  I interrupt the Linux boot with
#cp I cms
acc (noprof

I then run the SLES12 EXEC which pulls in the PARMFILE above.  The only
prompts I received on the console are for
Specifying a MAC address is optional.
In most cases letting it default is the correct choice.
Provide one only if you know it is truly necessary.
Optional MAC address. (Enter '+++' to abort).

When the installation system finished booting, I PuTTYed into another test
server and 'ssh -X root@10.17.1.156<mailto:root@10.17.1.156>', replied with
the password (the one specified in the PARMFILE), then invoked YaST.

I went thru all of the screens and specified what I needed to but when I got
to the last screen and selected [Install] I received a pop-up that my disk
would be reformatted and I would lose all of the data that was on it.

I am asking in that I was working with Novell support yesterday and we
terminated the YaST portion of the install by slecting [Abort].  On the
console (the VM screen) we received the following:
Start Installation

0) <-- Back <--
1) Installation
2) Upgrade
3) Rescue System
4) Boot Installed System
5) Network Setup

Is there a way to modify the PARMFILE to specify that I wasn't to perform an
upgrade-in-place?  Do I need to use a PARMFILE with a minimal set of
parameters?  I tried to change the
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd
to
upgrade=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1.

The installation system couldn't find the SLES 12 repository.


Thank you.


Harley


Harley Linker Jr.
Sr. Systems Programmer
Ensono
e: harley.lin...@ensono.com<mailto:harley.lin...@ensono.com>
o: 630.944.5111

www.ensono.com<http://www.ensono.com/>


(c) 2017 Ensono, LP. All rights reserved. Ensono is a trademark of Ensono,
LP. The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged. If the reader of this message is not the intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please resend this communication to the sender and
delete the original message or any copy of it from your computer system.

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

Upgrade of SLES 11 SP4 to SLES 12 SP2 on System z

[Harley Linker]

Hi,

I am looking to upgrade some of my z/VM based servers from SLES 11 SP4 to SLES 
12 SP2 and am wondering if this is possible on System z.

My guest is defined as:
PROFILE LNXDFLT
 LOGONBY ...
 IPL CMS PARM AUTOCR
 CONSOLE 009 3215 T
 SPOOL 00C 2540 READER A
 SPOOL 00D 2540 PUNCH A
 SPOOL 00E 1403 A
 LINK MAINT 190 190 RR
 LINK MAINT 19D 19D RR
 LINK MAINT 19E 19E RR
 LINK LNXMAINT 191 191 RR


USER SYSSOFT1  3074M 3074M G
 INCLUDE LNXDFLT
 NICDEF 1F00 TYPE QDIO LAN SYSTEM VSWINT1
 MDISK 200 3390 001 10016 LN150D MR ALL SOME FEW  /
 MDISK 201 FB-512 V-DISK 524288  WV   SWAP
MDISK 990 3390 001 10016 LN150E MR ALL SOME FEW  /OPT
MDISK 991 3390 001 10016 LN150F MR ALL SOME FEW  /OPT

The 200 disk is the boot volume, 201 is a virtual swap disk, and 990 and 991 
are an LV mounted to /opt.

I am using a PARMFILE containing the following (sanitized):
ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc term=dumb
vmpoff=logoff hostname= mf-syssoft1 hostip=10.17.1.xxx
gateway=10.17.1.129 nameserver=999.24.8.126
instnetdev=osa osainterface=qdio layer2=1 portno=0
netmask=255.255.255.192 broadcast=10.17.1.255
readchannel=0.0.1f00 writechannel=0.0.1f01 datachannel=0.0.1f02
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1
ssh=1 ssh.password= linuxrclog=/dev/console
manual=0

I begin the installation by logging onto the SYSSOFT1 guest (which already has 
SLES 11 SP4 installed).  I interrupt the Linux boot with
#cp I cms
acc (noprof

I then run the SLES12 EXEC which pulls in the PARMFILE above.  The only prompts 
I received on the console are for
Specifying a MAC address is optional.
In most cases letting it default is the correct choice.
Provide one only if you know it is truly necessary.
Optional MAC address. (Enter '+++' to abort).

When the installation system finished booting, I PuTTYed into another test 
server and 'ssh -X root@10.17.1.156<mailto:root@10.17.1.156>', replied with the 
password (the one specified in the PARMFILE), then invoked YaST.

I went thru all of the screens and specified what I needed to but when I got to 
the last screen and selected [Install] I received a pop-up that my disk would 
be reformatted and I would lose all of the data that was on it.

I am asking in that I was working with Novell support yesterday and we 
terminated the YaST portion of the install by slecting [Abort].  On the console 
(the VM screen) we received the following:
Start Installation

0) <-- Back <--
1) Installation
2) Upgrade
3) Rescue System
4) Boot Installed System
5) Network Setup

Is there a way to modify the PARMFILE to specify that I wasn't to perform an 
upgrade-in-place?  Do I need to use a PARMFILE with a minimal set of 
parameters?  I tried to change the 
install=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd
to
upgrade=nfs://10.17.1.yyy/media/s390x/sles12sp2/dvd1.

The installation system couldn't find the SLES 12 repository.


Thank you.


Harley


Harley Linker Jr.
Sr. Systems Programmer
Ensono
e: harley.lin...@ensono.com<mailto:harley.lin...@ensono.com>
o: 630.944.5111

www.ensono.com<http://www.ensono.com/>


(c) 2017 Ensono, LP. All rights reserved. Ensono is a trademark of Ensono, LP. 
The information contained in this communication is confidential, is intended 
only for the use of the recipient named above, and may be legally privileged. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this communication in error, 
please resend this communication to the sender and delete the original message 
or any copy of it from your computer system.

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

[Mark Post]

>>> On 7/5/2017 at 09:29 AM, Steffen Maier  wrote: 
-snip-
> 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?

No, it doesn't.  It takes you to the production system.


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/

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: Single user (rescue target) in SLES 12

[Mark Post]

>>> On 6/27/2017 at 09:33 AM, Dave Jones <djo...@itconline.com> wrote: 
> Hi, Mark.
> 
> Is there a list or doc someplace that has all of the valid PARM values
> for IPL-ing SLES 12 in addition to the "PARM S" for getting into single
> user mode?

Mostly they're just kernel parameters, so 
/usr/src/linux/Documentation/kernel-parameters.txt would be one place. Then 
there are dracut and systemd parameters that can be passed, but I'm not aware 
of a consolidated place they're all discussed.


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/

Re: Single user (rescue target) in SLES 12

[Ray Mansell]

On the subject of #CP VI VMSG... my brain/finger combination often had
problems trying to enter the command I wanted before the timeout
occurred. Eventually it dawned on me that I could enter '#CP' on its own
(or use PA1) to enter CP READ, after which I could take my time entering
the VI VMSG command correctly before restarting the virtual machine.

I'm sure this is old news to many of you, but I thought it worth
mentioning.

Ray

On 2017-06-26 15:26, Marcy Cortes 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?
>
> Marcy
>
> This message may contain confidential and/or privileged information. If you 
> are not the addressee or authorized to receive this for the addressee, you 
> must not use, copy, disclose, or take any action based on this message or any 
> information herein. If you have received this message in error, please advise 
> the sender immediately by reply e-mail and delete this message. Thank you for 
> your cooperation.
>
> --
> 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/

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

[Dave Jones]

Hi, Mark.

Is there a list or doc someplace that has all of the valid PARM values
for IPL-ing SLES 12 in addition to the "PARM S" for getting into single
user mode?
Thanks.
DJ

On 06/26/2017 05:14 PM, Mark Post wrote:
> PARM S

--
ITC-email-sig

*David Jones **|**Managing Director for zSystems Services **|**z/VM,
Linux, and Cloud
703.237.7370 (Office) **|**281.578.7544 (Cell)*

*Information Technology Company <http://www.itconline.com/>*

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

[Marcy Cortes]

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

There are systemd specific parms you can pass, but I find this much easier to 
remember.


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/

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

[Mark Post]

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

There are systemd specific parms you can pass, but I find this much easier to 
remember.


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/