Re: lsdasd is gone?

[Marcy Cortes]

It's part of the s390-tools package on SLES 15 so you'd think it'd be on RH9 as 
well.

Try rpm -qil s390-tools | grep lsdasd 

On SLES it is in /sbin so if you aren't root, you'd need the full path



-Original Message-
From: Linux on 390 Port  On Behalf Of Martha McConaghy
Sent: Wednesday, May 10, 2023 2:01 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] lsdasd is gone?

I have just started working with RHEL 9 on z, only building my 2nd server.  I 
went to add another ECKD DASD to the system and, to my shock, lsdasd doesn't 
seem to be there.  The dasdfmt and fdasd commands are still there, but no 
lsdasd.  I went through the Rhel 9 install guide on redhat.com and there is no 
mention of it in the section on adding DASD to the system.  Anyone know more 
about this?  It was a hugely helpful tool, why would they get rid of it.  (I 
tried googling and didn't find any mention of it being retired.)

Is there a package I can install to get it back?

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

Marist College IT

Poughkeepsie, NY 12601


--
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.com/v3/__http://www2.marist.edu/htbin/wlvindex?LINUX-390__;!!F9svGWnIaVPGSwU!uMdwbmn8ZexVXUCoYBB_nppdhv-GRA6jj5WJA2iWh_ZXJ_O1vpZM7XezqENCXDkcTswaU5AQhsCFPo3TnPmkqRMcjrLh9EtUCvRjTQ$
 

--
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: Edit grub from 3270 console

[Marcy Cortes]

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

Is that what you are trying to do?

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

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

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


Mark Post

> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU]On Behalf Of 
> Rich Smrcina
> Sent: Thursday, May 04, 2023 5:55 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Edit grub from 3270 console
> 
> 
> Victor,
> 
> The only options that I can think of are ed and sed. Your Unix people 
> should know how to use them.
> 
> Rich Smrcina
> Sr. Systems Engineer
> 
> Velocity Software Inc.
> Main: (650) 964-8867
> Main: (877) 964-8867
> r...@velocitysoftware.com 
> 
> 
> > On May 4, 2023, at 4:04 PM, Victor Echavarry
>  wrote:
> > 
> > Hello
> > 
> > Some of our Unix people asked is there a way to add or
> modify the grub file at start up from a 3270 screen? Is there are 
> instructions for this?
> > 
> > Regards,
> > 
> > Víctor Echavarry
> > System Programmer
> > EVERTEC LLC
> > 
> > 
> > WARNING: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or 
> entity to whom they are addressed. If you have received this email in 
> error please delete it immediately.
> Please note that any views or opinions presented in this email are 
> solely those of the author and do not necessarily represent those of 
> EVERTEC, Inc. or its affiliates. Finally, the integrity and security 
> of this message cannot be guaranteed on the Internet, and as such 
> EVERTEC, Inc. and its affiliates accept no liability for any damage 
> caused by any virus transmitted by this email.
> > 
> > 
> --
> > 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.com/v3/__http://www2.marist.edu/htbin/wlvindex?LI
> > NUX-390__;!!F9svGWnIaVPGSwU!rlbh7E4EmQQVhmHvNqU5d5dgNMAAEm0Hq87IwquV
> > a3M7tMHyThAIoev8zt4SWKfNR-xtXkCVyUB2yJ2ZfxCoQ0w$
> > 
> 
> 
> --
> 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.com/v3/__http://www2.marist.edu/htbin/wlvindex?LINU
> X-390__;!!F9svGWnIaVPGSwU!rlbh7E4EmQQVhmHvNqU5d5dgNMAAEm0Hq87IwquVa3M7
> tMHyThAIoev8zt4SWKfNR-xtXkCVyUB2yJ2ZfxCoQ0w$
> 

--
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.com/v3/__http://www2.marist.edu/htbin/wlvindex?LINUX-390__;!!F9svGWnIaVPGSwU!rlbh7E4EmQQVhmHvNqU5d5dgNMAAEm0Hq87IwquVa3M7tMHyThAIoev8zt4SWKfNR-xtXkCVyUB2yJ2ZfxCoQ0w$
 

--
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: Diag 288 vs SLES 15

[marcy cortes]

Thanks Duane!   I’m told it’s also broken in SP2.  This helps determine
when it stopped working.

For anyone running GDPS xDR this is used in xdrwatchdog.

We have cases open.



On Tue, Jan 24, 2023 at 7:55 PM Duane Beyer  wrote:

> SLES 15SP4:
> modprobe diag288_wdt
> modprobe: ERROR: could not insert 'diag288_wdt': Invalid argument
>
> SLES 15 SP3
> modprobe diag288_wdt
> modprobe: ERROR: could not insert 'diag288_wdt': Invalid argument
>
> SLES 15 SP1
> modprobe diag288_wdt
> (no error, but no output)
>
> Duane
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of marcy
> cortes
> Sent: Tuesday, January 24, 2023 7:09 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Diag 288 vs SLES 15
>
> Does anyone have a SLES 15 SP4 system that they could try this command on?
>
> modprobe diag288_wdt
>
> If it fails do you have an earlier 15 SP that it does work with?
>
> Marcy
> --
> 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
>
> --
> 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
>
-- 
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

Diag 288 vs SLES 15

[marcy cortes]

Does anyone have a SLES 15 SP4 system that they could try this command on?

modprobe diag288_wdt

If it fails do you have an earlier 15 SP that it does work with?

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

Re: Warning if upgrading SLES12 to SLES15 SP3

[Marcy Cortes]

Great! 

 I also have the SUSE_REMOVE_LINUX_ROOT_PARAM=true as well.
And I set the GRUB_CMDLINE_LINUX_ 
DEFAULT="root=/dev/disk/by-path/ccw-0.0.0101-part1 hvc_iucv=8 TERM=dumb 
crashkernel=103M vmhalt=LOGOFF vmpoff=LOGOFF"

101 is our boot disk.



-Original Message-
From: Linux on 390 Port  On Behalf Of Aria Bamdad
Sent: Thursday, October 14, 2021 6:10 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Warning if upgrading SLES12 to SLES15 SP3

Marcy,  thank you for pointing that out.  I have that in my documentation since 
SLES12 also but when I checked, I noticed that for the server I upgraded from 
12 to 15, this option was commented out!  I also add 
SUSE_REMOVE_LINUX_ROOT_PARAM="true" but this option was still there.  So it 
turns out that this entire thing could be avoided by the 
GRUB_DISABLE_LINUX_UUID=true.  I point to my root device via the root= kernel 
option and point to the device number by-path.  Thank you for reminding me to 
look for this option.  Don't know how it got commented out or perhaps it was 
never uncommented. 

Thanks again,
Aria



-Original Message-
From: Linux on 390 Port  On Behalf Of Marcy Cortes
Sent: Wednesday, October 13, 2021 6:36 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Warning if upgrading SLES12 to SLES15 SP3

Aria, I've had in our build stuff since the sles 12 days to put this in 
/etc/default/grub
GRUB_DISABLE_LINUX_UUID=true

I think that might help your boot duplicate issues? 
My brain cells that contained why I did that seem to have been reused for 
another purpose though, so maybe it was something else.  I know it had to do 
with clones. 

Marcy

--
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.com/v3/__http://www2.marist.edu/htbin/wlvindex?LINUX-390__;!!F9svGWnIaVPGSwU!8zh6EniZeHuF4uWzF57F-64BUQ-NFR7rsJIjy4XQUA97WecCCDT0gp0u-6QcX9NS0A4B1I4$
 

--
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: Warning if upgrading SLES12 to SLES15 SP3

[Marcy Cortes]

Aria, I've had in our build stuff since the sles 12 days to put this in 
/etc/default/grub
GRUB_DISABLE_LINUX_UUID=true

I think that might help your boot duplicate issues? 
My brain cells that contained why I did that seem to have been reused for 
another purpose though, so maybe it was something else.  I know it had to do 
with clones. 

Marcy

-Original Message-
From: Linux on 390 Port  On Behalf Of Aria Bamdad
Sent: Wednesday, October 13, 2021 2:00 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Warning if upgrading SLES12 to SLES15 SP3

Peter,  thank you again for an amazing analysis of what is happening.
Your udev rules idea is an interesting one.  I do use this to assign
consistent device names to LTO tape drives on my TSM/Spectrum Protect
server across boots.  However, for this situation, I think it would be
overkill.

I think what is important is what I at least have learned from this
process and what things to watch out for and avoid if/when one mounts
or activates root partitions from one system onto another.  The
practice of resetting file system UUIDs after cloning may be something
to consider doing going forward.

Aria


Quoting Peter Oberparleiter :

> On 08.10.2021 18:08, Aria Bamdad wrote:
>> Quoting Peter Oberparleiter :
>>
>> Peter, thank you for your excellent analysis and clarification of how
>> this works. It now makes perfect sense to me.
>
> I'm glad that you found the information I provided to be helpful.
>
> [...]
>
>
>> I tested the what you said above.  Sure enough, if you have dasda1 as
>> your root device for the active system, you will find properly defined
>> device names in by-id, by-path and by-uuid for this disk.  Then if you
>> were to activate/enable a clone of that disk, say as dasdf1, what
>> happens is that by-id and by-path are still correct (they point to
>> dasdf1) but chzdev will replace the existing symbolic link in by-uuid
>> pointing to dasda1 with a new one pointing to dasdf1 (as it should) so
>> now you will overwrite the previous UUID symbolic link that pointed to
>> dasda1 with one that points to dasdf1.
>
> Small correction: the links are not created by chzdev, but by udev which
> is a core part of Linux OS distributions.
>
>> We no longer have one for
>> dasda1 which is the true root file system since we can't have two
>> files with the same name here. chzdev does this without any warning.
>> Shouldn't it at least give a message or better yet, no replace the
>> file in by-uuid?
>
> Unfortunately there's no easily consumable way for udev to issue
> warnings like that. And chzdev cannot check a device's UUID without
> activating it - and then it would already be too late.
>
>> Perhaps it would be good to present the same warning
>> as it currently does when you try to disable/deactivate a disk and it
>> detects conflicting UUIDs.  In my opinion, that would be a good thing
>> as it prompts the user that they are about to do something that may
>> result in a system being in a inconsistent state.  Not creating the
>> link in by-uuid in situations like this would avoid the problem all
>> together.
>
> Indeed udev *does* provide a level of control over how the situation
> with conflicting UUIDs - or more generally: conflicting link targets -
> is handled. A udev rule can assign a link-priority value to a device. If
> two devices with the same symlink target are found, the device with the
> higher link-priority value will take precedence.
>
> From my own experience writing a udev rule isn't always
> straight-forward, so I'll provide an example to support the discussion.
> This example assumes two DASDs, each with a single partition containing
> an ext-filesystem:
>
>   - 0.0.1000: dasdb1
>   - 0.0.2000: dasdc1
>
> By default all devices are assigned a link-priority of 0. To quote the
> udev man page:
>
>   If no link_priority is specified, the order of the devices
>   (and which one of them owns the link) is undefined.
>
> The usual effect though will be that the device that is registered last
> will take precedence.
>
> The following sequence of commands demonstrates the problem by assigning
> the same file system label first to dasdb1, then to dasdc1. The output
> of readlink shows the resulting link target:
>
>   $ e2label /dev/dasdb1 test
>   $ readlink /dev/disk/by-label/test
>   ../../dasdb1
>   $ e2label /dev/dasdc1 test
>   $ readlink /dev/disk/by-label/test
>   ../../dasdc1
>
> As you can see, dasdc1 overwrites the previous dasdb1 link target.
>
> Now if you create a udev rule that assigns a different link-priority,
> the device with the higher value will take precedence.
>
> Here's an example udev rule file that assigns a link-priority of -1 to
> all partitions on the DASD with device number 2000.
>
> ACTION=="add|change", KERNEL=="dasd*", ENV{DEVTYPE}=="partition",
> ENV{ID_PATH}=="ccw-0.0.2000", OPTIONS="link_priority=-1"
>
> The rule can be activated by storing it as a single line to a file with
> a name ending in .rules in 

Re: Warning if upgrading SLES12 to SLES15 SP3

[Marcy Cortes]

So you must not have added any disks since 12 SP4, Mark. 
This is 12 SP5 server that's been through a lot of upgrades (and upgrades 
within the support period). 

me@x:/home/me> ls -alt /etc/udev/rules.d/*dasd*
-rw-r--r-- 1 root root 363 Jul 24  2020 
/etc/udev/rules.d/41-dasd-eckd-0.0.10bf.rules
-rw-r--r-- 1 root root 363 Jan 10  2020 
/etc/udev/rules.d/41-dasd-eckd-0.0.6000.rules
-rw-r--r-- 1 root root 396 Sep  5  2019 
/etc/udev/rules.d/41-dasd-eckd-0.0.8002.rules
-rw-r--r-- 1 root root 396 Jun  9  2019 
/etc/udev/rules.d/41-dasd-eckd-0.0.8008.rules
-rw-r--r-- 1 root root 347 Apr 10  2019 /etc/udev/rules.d/51-dasd-0.0.8008.rules
-rw-r--r-- 1 root root 347 Dec 10  2018 /etc/udev/rules.d/51-dasd-0.0.8007.rules
-rw-r--r-- 1 root root 538 Dec 15  2016 /etc/udev/rules.d/51-dasd-0.0.ff03.rules
-rw-r--r-- 1 root root 536 Dec 15  2016 /etc/udev/rules.d/51-dasd-0.0.ff00.rules
-rw-r--r-- 1 root root 536 Dec 15  2016 /etc/udev/rules.d/51-dasd-0.0.ff02.rules
-rw-r--r-- 1 root root 536 Dec 15  2016 /etc/udev/rules.d/51-dasd-0.0.ff01.rules
-rw-r--r-- 1 root root 347 Nov  6  2013 /etc/udev/rules.d/51-dasd-0.0.8006.rules
-rw-r--r-- 1 root root 347 Aug 27  2013 /etc/udev/rules.d/51-dasd-0.0.8005.rules
-rw-r--r-- 1 root root 347 Aug 27  2013 /etc/udev/rules.d/51-dasd-0.0.8004.rules
-rw-r--r-- 1 root root 347 Jun 19  2013 /etc/udev/rules.d/51-dasd-0.0.8003.rules
-rw-r- 1 root root 347 Aug 26  2011 /etc/udev/rules.d/51-dasd-0.0.8001.rules
-rw-r- 1 root root 347 Aug 26  2011 /etc/udev/rules.d/51-dasd-0.0.8000.rules
-rw-r--r-- 1 root root 347 Jun 18  2010 /etc/udev/rules.d/51-dasd-0.0.0102.rules
-rw-r--r-- 1 root root 347 Jun 18  2010 /etc/udev/rules.d/51-dasd-0.0.0101.rules

The newer disks are all 41's.

We probably won't do many if any upgrades to 15.  It'll be replacement servers. 
 But it sounds like if we do, re-doing them as 41s would be a good idea.
Which presumably would just be erasing them and doing a chzdev -e again.



-Original Message-
From: Linux on 390 Port  On Behalf Of Aria Bamdad
Sent: Friday, August 20, 2021 2:09 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Warning if upgrading SLES12 to SLES15 SP3

Quoting Mark Post :

> On 8/19/21 6:17 PM, Aria Bamdad wrote:
>> The upgrade to SP3 appears to
>> cause a change in the udev definitions for the DASD defined on the server
>> (in /etc/udev/rules.d) .  For SLES 12 systems, these rules are
>> 51-dasd-0.0.0xxx.rules files but it seems that for SLES15, they change
>> format and number to 41-dasd-eckd-0.0.0xxx.rules.
>
>
> This change actually happened with SLES12 SP4, when the chzdev and
> lszdev tools were introduced to s390-tools by IBM.
>
>

That's odd because none of my SLES 12 SP4 or SP5 systems have 41
rules.  In fact
none of my upgraded servers from 12 to 15 have them even for 15 SP1 or
SP2.  This
happens at SP3 for me.



>> However, this change does
>> not happen for an upgraded SLES12 system to SLES15 until you upgrade to
>> SLES15SP3.  Once you upgrade to SP3, then the old 51-dasd rules are renamed
>> with the '.legacy' extensions, new 41- rules are created.  The rules for the
>> vdisk for swap are left alone and thus after the upgrade, the swap
>> partitions are no longer activated.  There is more to this but I will not go
>> into detail.
>
> Question, for each of the udev rules renamed to .legacy, is there an
> equivalent 41-* rule present?
>


Only the eckd device rules were renamed from 51 to 51 with .legacy
extension.  Then
new 41 rules defined for them.  The FBA devices, namely the two vdisk
swap disks were
left alone with 51 rules and not 41 rules were defined.  There are
messages in the y2log
file from mkinitrd stating it is skipping 51 rule devices.  I have
reported these to SUSE but
they tech said she has no access to Z system so is testing on another
architecture.  I don't
think that will help!

Aria



>
> 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://urldefense.com/v3/__http://www2.marist.edu/htbin/wlvindex?LINUX-390__;!!F9svGWnIaVPGSwU!7IhAnfBAvEEizayUvnXC9GvMEe2vaWACz4SktcsbZjL8DahBsSXQwOt-9aRJfDNXF_zy0Oo$
>  

--
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.com/v3/__http://www2.marist.edu/htbin/wlvindex?LINUX-390__;!!F9svGWnIaVPGSwU!7IhAnfBAvEEizayUvnXC9GvMEe2vaWACz4SktcsbZjL8DahBsSXQwOt-9aRJfDNXF_zy0Oo$
 

--
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: Warning if upgrading SLES12 to SLES15 SP3

[Marcy Cortes]

Thanks for the heads up Aria!
We have a lot of them that upgraded from 12 to Sp1, then sp2, and now SP3 is 
being tested.  Many have the 41's and 51's.
We'll look for this and report it if it happens here too. 



-Original Message-
From: Linux on 390 Port  On Behalf Of Aria Bamdad
Sent: Thursday, August 19, 2021 3:18 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Warning if upgrading SLES12 to SLES15 SP3

Hi,

I found yesterday a problem which could result in a server failing to boot
once it is upgraded from SLES 12 to 15 and then to recently released SP3.  I
thought I should warn those here just in case.


My environment is running under z/VM, the servers use defined minidisks for
/, /usr and /var and two swap partitions defined as vdisks and formatted
using swapgen prior to boot.



What I found is that if you have a server that is SLES 12, then upgraded to
SLES 15 GA or SP1 or SP2, all works fine.  However, if you then upgrade the
same server to SP3 OR if you simply upgrade directly from SLES12SP5 to
SLES15SP3, then you will encounter this problem. You will not see this
problem if this was a fresh install of SLES 15 and upgrading to SP3.



The problem only surfaces when you go to SP3.  The upgrade to SP3 appears to
cause a change in the udev definitions for the DASD defined on the server
(in /etc/udev/rules.d) .  For SLES 12 systems, these rules are
51-dasd-0.0.0xxx.rules files but it seems that for SLES15, they change
format and number to 41-dasd-eckd-0.0.0xxx.rules.  However, this change does
not happen for an upgraded SLES12 system to SLES15 until you upgrade to
SLES15SP3.  Once you upgrade to SP3, then the old 51-dasd rules are renamed
with the '.legacy' extensions, new 41- rules are created.  The rules for the
vdisk for swap are left alone and thus after the upgrade, the swap
partitions are no longer activated.  There is more to this but I will not go
into detail.


However, that's not the problem.  At this point, if you attempt to do any
change to the bootloader or run mkinitrd, for instance if you use Yast to
update DASD and 'Activate' the swap disks or any disk for that matter,
causing mkinitrd to run as well as grub2-intall, this will write a faulty
boot loader and the system will no longer boot if it were to be rebooted.
You can use a rescue system to fix the broken boot but if you were to run
the above process again, the same will happen.  This is risky because you
may not reboot for 6 months and then you find out this is the case.



I have reported to SUSE but no response as of now.



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
https://urldefense.com/v3/__http://www2.marist.edu/htbin/wlvindex?LINUX-390__;!!F9svGWnIaVPGSwU!9O5MNPss40ij3_1wRuURkrrjLNOaqETnR3jGNnULN_Nt8xdId85OvGWw4vl1R2RvWJBLymI$
 

--
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: integrated console overflow from the Linux installer

[Marcy Cortes]

I had that exact problem on Tuesday. 
Ended up taking my volume back to VM, dedicating the OSAs, and fixing my config 
there. 

Keep linux under VM where god intended it to be is my advice ;) 

If you figure it out, please share.  In my experience, the sysascii prompt pops 
up way after tons of messages fly by.  


-Original Message-
From: Linux on 390 Port  On Behalf Of Alan Altmark
Sent: Thursday, June 10, 2021 1:43 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] integrated console overflow from the Linux installer

A colleague is installing RHEL 8.4 in an LPAR via ftp server.   The system 
loads, but early in the installer boot process there's a network error 
that he can't scroll back to look at because the Operating System Messages 
console "rolls off" after about 475-500 messages. 

Can he update the  generic.prm file to reference the integrated ASCII 
console instead?  And will that give him better console management to let 
him see early boot errors?

Regards,
Alan 
Alan Altmark
Senior Managing z/VM Consultant
IBM Lab Services
Phone: 607-429-3323 | Mobile: 607-321-7556
E-mail: altma...@us.ibm.com 
  Endicott, NY  USA


--
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.com/v3/__http://www2.marist.edu/htbin/wlvindex?LINUX-390__;!!F9svGWnIaVPGSwU!4mNyTra0X0P0Tn2Ks6fVxC97Li7Y54FqxXinfr3SOl1t3gYGydUPql2i2t0PEAq8E7xuG9g$
 

--
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: Has anyone managed to install OpenShift? How many resources?

[Marcy Cortes]

Well, I'd be thrilled if something new only needed 72G ;)
I know, that doesn't help, but it seems like a not unreasonable amount these 
days. 


-Original Message-
From: Linux on 390 Port  On Behalf Of Rick Barlow
Sent: Wednesday, April 21, 2021 11:44 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Has anyone managed to install OpenShift? How many 
resources?

We are attempting to install OpenShift on z/VM. Based on the 
installation instructions, it requires a minimum of 3 IFLs (preferrably 
6) running with SMT enabled, 3 control virtual machines with 16GB of 
memory, and 2 workers with 12GB of memory. We are constantly running out 
memory and driving excessive paging rates. This is very reminiscent of 
previous offerings like IBM Director and CMA. I know that the IBM 
LinuxONE Community Cloud is using this. I am looking for other sites who 
have gotten it running.

Has anyone successfully installed OpenShift on there own system(s)?
How many resources did you have on the environment? IFLs? Memory?

Feel free to respond on the list or offline directly to me.

Thanks,
Rick

Rick Barlow
Senior z/VM Specialist
ri...@velocitysoftware.com
Velocity Software, Inc.
https://urldefense.com/v3/__http://www.velocitysoftware.com__;!!F9svGWnIaVPGSwU!7Q_vNJ_WHr0jkXW_6TdH1cHH6lYtRbeox_c117dMGN2DL1O3CsXE_FOLhlSR5N9GS_-djn0$
 



--
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.com/v3/__http://www2.marist.edu/htbin/wlvindex?LINUX-390__;!!F9svGWnIaVPGSwU!7Q_vNJ_WHr0jkXW_6TdH1cHH6lYtRbeox_c117dMGN2DL1O3CsXE_FOLhlSR5N9Gb3ej694$
 

--
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: Sharing dasd between linux

[Marcy Cortes]

You need software that provides a clustered file system.  Spectrum Scale is one 
such piece of SW. 
SUSE has HAE as well.   Not sure what RH has. 

Marcy

-Original Message-
From: Linux on 390 Port  On Behalf Of Rinaldo Akio 
Uehara
Sent: Monday, February 8, 2021 3:31 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Sharing dasd between linux

I read the page [ 
https://www.ibm.com/support/knowledgecenter/SSB27U_6.4.0/com.ibm.zvm.v640.hcpa5/dsbmvm.htm
 | 
https://www.ibm.com/support/knowledgecenter/SSB27U_6.4.0/com.ibm.zvm.v640.hcpa5/dsbmvm.htm
 ] , and I was unsure if that could work on linux (more specifically RHEL 8). 

If I share disk between 4 RHEL guests as mentioned in the link, all of them 
could read/write without risk of integrity? 


Thanks! 


Rinaldo Akio Uehara 

Analista 

Superintendência de Produtos e Serviços-Centro de Dados 

Diretoria de Operações 

+55 (11)2173-3228 



--
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: Experience IBM Spectrum Scale

[Marcy Cortes]

We make extensive use of it for sharing file systems between servers.   We 
haven't used it with OpenShift or NFS, though.  Haven't had a need for that 
yet.  It works well for us!
Marcy


-Original Message-
From: Linux on 390 Port  On Behalf Of Mittelstädt, 
David
Sent: Tuesday, January 19, 2021 8:38 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Experience IBM Spectrum Scale

Hi everyone,

Sometime ago I asked for a HA NFS solution on Linux on Z. One answer was using 
IBM Spectrum Scale for that. Currently we are looking for persistent storage 
for our OpenShift environment. If I understand it correctly, Spectrum Scale 
could be a solution for that. Does someone have experience with IBM Spectrum 
Scale? What is good, what is not so good with it? Would Spectrum Scale be a 
good choice for OpenShift environments and HA NFS?

Best regards,
David Mittelstädt

--
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: Linux and 5 digit address

[Marcy Cortes]

Thanks Peter!
I also had to adjust cio_ignore stuff since not under VM, but I'm good now!

-Original Message-
From: Linux on 390 Port  On Behalf Of Peter 
Oberparleiter
Sent: Thursday, January 14, 2021 1:24 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Linux and 5 digit address

On 14.01.2021 02:11, Marcy Cortes wrote:
> I tried to bring it up today, but it failed to find the ipl volume.
> I figured out that it was because we are on site 2 disk this week and the
> real address to use in the HMC is 5 digit, starting with a 1, say 10F57.
> I need to add that to the linux config.   Linux sees things as
> 0.0.0f57 under VM.Is the 5 digit Linux address in the LPAR going to
> be 0.1.0F57 or 1.0.0F57?

The first digit in a 5 digit device number as entered on the HMC load
panel is the SSID (Subchannel Set ID). In Linux this is reflected in the
second number of the device number triplet.

To put it another way: X (HMC) => 0.X. (Linux)

> I think I’ll need to make another udev rule for that (this is SLES 15 SP2).

That should work as udev rules are only triggered for devices that Linux
can see. The extra rule should have no adverse effect in the z/VM guest
where the device in subchannel set 1 is missing.

Something like the following should do the trick:

$ chzdev -ep dasd-eckd 0.1.0f57


-- 
Peter Oberparleiter
Linux on Z Development - IBM Germany

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

Linux and 5 digit address

[Marcy Cortes]

(Cross-posted to IBMVM and Linux-390)

So I have this server that once in a while needs to be in a LPAR manage crypto 
keys, but I want him under VM because it’s just better there 

I tried to bring it up today, but it failed to find the ipl volume.  I figured 
out that it was because we are on site 2 disk this week and the real address to 
use in the HMC is 5 digit, starting with a 1, say 10F57.
I need to add that to the linux config.   Linux sees things as 0.0.0f57 under 
VM.Is the 5 digit Linux address in the LPAR going to be 0.1.0F57 or 
1.0.0F57?  I think I’ll need to make another udev rule for that (this is SLES 
15 SP2).



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: SLES 15 SP2 kernel issue with random number generator (crng)

[Marcy Cortes]

So poking around z90crypt.service comes with libica-tools packages on sles15 
sp2.
It's not installed by default.
I put it on and started it with systemctl start and does start but throws this 
error
z90crypt[40815]: modprobe: FATAL: Module zcrypt_pcixcc not found in directory 
/lib/modules/5.3.18-24.37-default

Not sure exactly what that means.  This is on a z15 with APVIRT using Crypto 
Express 7 in coprocessor mode.
 It looks like the service simply modprobe's these things:   pkey zcrypt_pcixcc 
zcrypt_cex2a zcrypt_cex4 zcrypt rng_core
A little googling says a pcixcc is available on a z990 and z890.   Maybe that 
needs to go 


-Original Message-
From: Linux on 390 Port  On Behalf Of Aria Bamdad
Sent: Friday, December 18, 2020 9:58 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SLES 15 SP2 kernel issue with random number generator 
(crng)

Thank you Berthold.  I am running on a z13s but I am saving up for at z15!
No special crypto express hardware either other than CPICF that is standard.
I will look into your suggestions.  I am seeing this only on SLES15 SP2
later kernel.  They recently changed random number generation within the
kernel.

Thanks,
Aria

-Original Message-
From: Linux on 390 Port  On Behalf Of Berthold
Gunreben
Sent: Friday, December 18, 2020 12:26 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES 15 SP2 kernel issue with random number generator (crng)

Hi Aria,

on what hardware do you operate? There is several possibilities to
consider, the easiest would be if you got a z15, because there is a RNG
in the CPU there. If you got an older machine with crypto express,
there is also a RNG in there, but you would need a crypto domain to
have that available to your guest.

To the question, why there is no rng-tools, the reason is, that
rng-tools would be a step backwards compared to what SUSE does. With
rng-tools, you got a software RNG and a userland process that copies
the produced random numbers to the entropy pool of the kernel.

You might read more about this in
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Lin
uxRNG/LinuxRNG_EN_V4_1.pdf
especially "3.9.2 Hardware Random Number Generator Framework"

With SUSE, the entropy pool of the kernel can be seeded by lots of
different rngs. You even can give those RNGs a specific trust, and tell
how many bits you would trust to be really random. It also overcomes
the need for a userspace process like rngd, and uses a kernel thread
instead.

I would have to install SLES15 to reproduce (still have SLES12 running
as well as Tumbleweed), but what you have to do to enable hardware RNGs
is basically start the crypto services. This used to be z90crypt, with
Tumbleweed, it is just the cryptsetup.target.

You can of course also enable the haveged service to get more entropy,
however that is software based entropy from within virtualization, and
that obviously does not have the same amount of real entropy like
hardware.

One thing that I would check is, if there is a entropy seed available
at /var/lib/systemd/random-seed. This is used to have more randomness
at startup.

Just for you to compare: On a z15, I get more than 300MB/s of entropy
from the hardware RNG. You might try this as well:

systemctl stop haveged
dd if=/dev/random of=/dev/null bs=1k count=2

Unfortunately it is hard to debug further or give more hints without
more detail of the setup. Hope that helped a bit.

Berthold

Am Wed, 16 Dec 2020 10:30:09 -0500
schrieb Aria Bamdad :

> Thanks Neale.  No, rng-tools is not an available package for SLES15.
> That's why I tried haveged which was what was installed on SLES12 and
> is still available for 15 but when you install 15 fresh, it does not
> install haveged.  SUSE support says that engineering is working on
> the issue but that's been going on for a while.
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Neale
> Ferguson Sent: Tuesday, December 15, 2020 11:19 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: SLES 15 SP2 kernel issue with random number generator
> (crng)
>
> What happens in you install rng-tools and start the service (assuming
> this is a package available on SLES15)?
>
> Neale
>
>
> --
> 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

Re: Oracle client for SLES 15?

[Marcy Cortes]

Really?  It's like 2.5 years since 15 was released.   You'd think that would be 
enough time to certify :( 
I understand a database would be a big deal, but I just need the client.  I 
guess they are stuck together. 


-Original Message-
From: Linux on 390 Port  On Behalf Of Aaron Graves
Sent: Tuesday, December 15, 2020 10:37 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Oracle client for SLES 15?


Hi Marcy,

The certification for Oracle on SLES15 has not completed yet.  Your work
around is what is recommended if you want to test on SLES15 in the interim.

Regards,
Aaron Graves
IBM Z Dallas ISV Center
aaron.gra...@ibm.com
845-433-3672



From:   Marcy Cortes 
To: LINUX-390@VM.MARIST.EDU
Date:   12/14/2020 06:51 PM
Subject:[EXTERNAL] Re: Oracle client for SLES 15?
Sent by:Linux on 390 Port 



I got it to install by adding a line to the cvu_config file

CV_ASSUME_DISTID=SUSE12

Hmm.   Looks like we are missing SLES 15 support from Oracle :(


From: Cortes, Marcy D. [PRINCIPAL ENGINEER]
Sent: Monday, December 14, 2020 1:32 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Oracle client for SLES 15?

Oracle 19c.
Has anyone found a client for Oracle for sles 15?   I can't believe there
wouldn't be one.

Using this one LINUX.ZSERIES64_193000_client.zip - Oracle Database 19c
Client (19.3) for IBM: Linux on System z (64 bit)
results in
[WARNING] [INS-08101] Unexpected error while executing the action at state:
'clientSupportedOSCheck'
   CAUSE: No additional information available.
   ACTION: Contact Oracle Support Services or refer to the software manual.
   SUMMARY:
   - java.lang.NullPointerException


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





--
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 15 SP2 kernel issue with random number generator (crng)

[Marcy Cortes]

We have haveged on our sles 15 SP2 servers.  We didn't consciously put it there 
:)   All of ours were upgrades from SP1, though.  So maybe that had it?   We've 
not had any issues.  


-Original Message-
From: Linux on 390 Port  On Behalf Of Aria Bamdad
Sent: Tuesday, December 15, 2020 10:53 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SLES 15 SP2 kernel issue with random number generator 
(crng)

Hi,



At a point during SLES15 SP2 release, an update to the kernel switched to
the new crng random number generator.  This is causing the random number
generator to take 2 minutes on my system to generate enough entropy, causing
the message:   "kernel: random: crng init done" to appear about 2 minutes
after boot completes.  This results in anything that depends on random
number generation such as OpenSSL to fail at boot.  This includes the SSH,
Apache, etc.



Once the message is displayed, then you can manually start the services that
failed.  I have confirmed that this is related to random number entropy by
manually installing the 'haveged' daemon.  On SLES12, this daemon was
installed by default but is not on SLES15.  With haveged installed, the
problem goes away.  I am running on a z13s and z/VM.  I can find similar
complaints for the same problem on some other architectures.



I reported the problem to SUSE the end of October but no resolution so far.
Is anyone else having this problem?   Is it safe to use havegd?



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://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: Oracle client for SLES 15?

[Marcy Cortes]

I got it to install by adding a line to the cvu_config file

CV_ASSUME_DISTID=SUSE12

Hmm.   Looks like we are missing SLES 15 support from Oracle :(


From: Cortes, Marcy D. [PRINCIPAL ENGINEER]
Sent: Monday, December 14, 2020 1:32 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Oracle client for SLES 15?

Oracle 19c.
Has anyone found a client for Oracle for sles 15?   I can't believe there 
wouldn't be one.

Using this one LINUX.ZSERIES64_193000_client.zip - Oracle Database 19c Client 
(19.3) for IBM: Linux on System z (64 bit)
results in
[WARNING] [INS-08101] Unexpected error while executing the action at state: 
'clientSupportedOSCheck'
   CAUSE: No additional information available.
   ACTION: Contact Oracle Support Services or refer to the software manual.
   SUMMARY:
   - java.lang.NullPointerException


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

Oracle client for SLES 15?

[Marcy Cortes]

Oracle 19c.
Has anyone found a client for Oracle for sles 15?   I can't believe there 
wouldn't be one.

Using this one LINUX.ZSERIES64_193000_client.zip - Oracle Database 19c Client 
(19.3) for IBM: Linux on System z (64 bit)
results in
[WARNING] [INS-08101] Unexpected error while executing the action at state: 
'clientSupportedOSCheck'
   CAUSE: No additional information available.
   ACTION: Contact Oracle Support Services or refer to the software manual.
   SUMMARY:
   - java.lang.NullPointerException


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: LVM does not come online after reboot. PVMOVE used to migrate data.

[Marcy Cortes]

That was going to my next question.   We have run into similar with LVM with 
ECKD stuff after new disks have been added.  We opened tickets and all have 
been fixed with updates to various pieces (lvm2 being one I remembered). 

-Original Message-
From: Linux on 390 Port  On Behalf Of Duane Beyer
Sent: Monday, December 7, 2020 10:25 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] LVM does not come online after reboot. PVMOVE used to 
migrate data.

Marcy

I was getting ready to call this in to SuSE and figured I should put the latest 
service on the system first (Because that is the first thing they will ask).   
Looks like that resolved the issue.  

The system was at: 
 The system is a SLES 12 SP4:  Linux lxnebnp2 4.12.14-95.16-default 
#1 SMP Mon May 6 09:58:58 UTC 2019 (1da26c7) s390x s390x s390x GNU/Linux 
Multipath  Version: 
multipath-tools-0.7.3+129+suse.e8ca031-2.8.1.s390x

The system is now: 
 SLES 12 SP4: Linux lxnebnp2 4.12.14-95.54-default #1 SMP Thu Jun 4 
12:49:28 UTC 2020 (892ef1f) s390x s390x s390x GNU/Linux
 multipath-tools-0.7.3+153+suse.80d9ed4-2.16.1.s390x
lvm2-2.02.180-9.34.8.s390x


Thanks everyone for helping out with this.  I got a lot of good information and 
learned a lot about the internals of LVM.   Still far from an expert, but at 
least a I will panic less next time.  
From what I read on a number of forms,  there were a number of things fixed in 
multipath and lvm on SLES 12 SP4.  

Duane


--
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: LVM does not come online after reboot. PVMOVE used to migrate data.

[Marcy Cortes]

When it's up, try running 
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install
dracut -f


-Original Message-
From: Linux on 390 Port  On Behalf Of Duane Beyer
Sent: Sunday, December 6, 2020 8:14 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] LVM does not come online after reboot. PVMOVE used to 
migrate data.

Thanks Mike, 

That is the temporary plan as a work around,  but I really need to fix the root 
cause.   
I did receive a message external to the list about checking the global_filter 
in  /etc/lvm/lvm.conf.  That’s what I am going to look at today.   I'll post my 
results. 

Duane

-Original Message-
From: Linux on 390 Port  On Behalf Of Michael MacIsaac
Sent: Sunday, December 6, 2020 7:07 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: LVM does not come online after reboot. PVMOVE used to migrate data.

Duane,

> Issuing lvchange -ay /dev/xxx/xxx changes the status to available.
A bit kludgy perhaps, but could you define a service that does the lvchange 
before /etc/fstab is read?

-Mike M

On Sat, Dec 5, 2020 at 6:18 PM Duane Beyer  wrote:

> Marcio
>
> The FCP devices are online and active after a reboot and the LUNS are
> showing up in multipath. The system is dropping into emergency mode
> because the LV's are defined in /etc/fstab.  If I remove them,  the 
> fstab, the system IPL's with no issues.  The LV's are just in Not 
> Available status.
>
> Issuing lvchange -ay /dev/xxx/xxx changes the status to available.
>
> My guess is it is something in the LV's metadata that get reread/reset 
> when the lvchange command is issued.  The problem is that's not 
> persistent,  so the next reboot,  we are in the same situation.
>
> Duane
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Marcio 
> da Silva Nunes
> Sent: Saturday, December 5, 2020 2:58 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: LVM does not come online after reboot. PVMOVE used to 
> migrate data.
>
> Duane,
>
>
> A possibility that can be verified.
>
>
> When use the text-based interface yast zfcp. If cio_ignore is enabled, 
> you might need to free blacklisted FCP devices before by using yast cio.
>
>
> Can this be the problem?
>
>
>
> Marcio da Silva Nunes
> Analista
> Superintendência de Produtos e Serviços-Centro de Dados Diretoria de 
> Operações
> +55 (61)2021-9099
> +55 (61) 99981-0376
>
> - Mensagem original -
> De: "Duane Beyer" 
> Para: "Linux on 390 Port" 
> Enviadas: Sábado, 5 de dezembro de 2020 12:28:39
> Assunto: Re: LVM does not come online after reboot. PVMOVE used to 
> migrate data.
>
> Marcio,
>
> All of the disks are for data.  The root file system is ECKD.
>
> The FCP LUNs were added via yast so all the configuration was done 
> with yast.  I do see the associated rules files and the correct fcp 
> definitions in /dev/disk/
> The system is a SLES 12 SP4:  Linux lxnebnp2 4.12.14-95.16-default #1 
> SMP Mon May 6 09:58:58 UTC 2019 (1da26c7) s390x s390x s390x GNU/Linux 
> Multipath
> Version: multipath-tools-0.7.3+129+suse.e8ca031-2.8.1.s390x
>
> /etc/udev/rules.d/41-zfcp-host-0.0.4000.rules
> /etc/udev/rules.d/41-zfcp-lun-0.0.5000.rules
> /etc/udev/rules.d/41-zfcp-lun-0.0.4000.rules
> /etc/udev/rules.d/41-zfcp-host-0.0.5000.rules
> /dev/disk/by-path/ccw-0.0.5000-zfcp-0x5005076810264e3c:0x00010
> 000
> /dev/disk/by-path/ccw-0.0.4000-zfcp-0x5005076810154da7:0x00020
> 000
> /dev/disk/by-path/ccw-0.0.4000-zfcp-0x5005076810154da7:0x00030
> 000
>  cut to save space 
> /dev/disk/by-path/ccw-0.0.4000-zfcp-0x5005076810154e3c:0x00010
> 000
> /dev/disk/by-path/ccw-0.0.4000-zfcp-0x5005076810154e3a:0x0
> 000
>
> Duane
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Marcio 
> da Silva Nunes
> Sent: Saturday, December 5, 2020 9:27 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: LVM does not come online after reboot. PVMOVE used to 
> migrate data.
>
> Duane,
>
> Let's see if it helps.
>
> Were the new FCP that are not associated with root included in the 
> zfcp.conf file?
>
> If they are part of the root system disk then they must be in zipl.conf.
>
> Maybe it works.
>
>
> Marcio da Silva Nunes
> Analista
> Superintendência de Produtos e Serviços-Centro de Dados Diretoria de 
> Operações
> +55 (61)2021-9099
> +55 (61) 99981-0376
>
> - Mensagem original -
> De: "Duane Beyer" 
> Para: LINUX-390@VM.MARIST.EDU
> Enviadas: Sexta-feira, 4 de dezembro de 2020 18:01:08
> Assunto: Re: LVM does not come online after reboot. PVMOVE used to 
> migrate data.
>
> I should have included this.   Status, NOT available
>
> This is what LVDISPLAY displays for the LVM disks:
>   --- Logical volume ---
>   LV Path/dev/u01/u01
>   LV Nameu01
>   VG Nameu01
>   LV UUID6qzW2g-xJr4-osII-ULfn-d9nb-VscF-saGdBL
>   LV Write Accessread/write
>   LV Creation host, time lxnebnp2, 2019-06-25 13:18:38 -0400
>   LV Status  

Re: Modify ifcfg-encw0.0.nnnn at DR

[Marcy Cortes]

>I'm also beginning to detect a pattern in DR environments:  The z/VM 
>systems themselves aren't replicated.  There is as often as not a 
>cold/warm/hot z/VM system already in the DR site with a site-specific 
>configuration.  Linux data is replicated, plus any "utility" data used by 
>the sysprogs.

That's a little scary.  directory updates better be there and no one had better 
mistakenly put a Linux disk on a VM non-replicated volume.

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

Re: Modify ifcfg-encw0.0.nnnn at DR

[Marcy Cortes]

You can do something like
sed -i -e 's/16/24/g'  filename

Or you can change the info with the IP command, and then get in and fix with VI

 

-Original Message-
From: Linux on 390 Port  On Behalf Of Frank M. 
Ramaekers
Sent: Tuesday, October 6, 2020 8:07 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Modify ifcfg-encw0.0. at DR

How can I change the IP address of a network adapter at D/R.  Since the IP 
address is unusable, I cannot ssh to the machine.   Attempting vi from the VM 
console is a mess.
I have two lines to change:

IPADDR="10.1.20.88"
PREFIX="16"(to 24)

Ideas?

Frank M. Ramaekers Jr.  | Systems Senior Administrator | CIS Mainframe Services
Unisys | (512)-387-3949 | Francis.Ramaekers at Unisys.Com

[unisys_logo]

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is for use only by the intended recipient. If you received this in 
error, please contact the sender and delete the e-mail and its attachments from 
all devices.
[Grey_LI]  [Grey_TW] 
  [Grey_GP] 
 [Grey_YT] 
 [Grey_FB] 
 [Grey_Vimeo]  
[Grey_UB] 

--
This message contains information which is privileged and confidential and is 
solely for the use of the intended recipient. If you are not the intended 
recipient, be aware that any review, disclosure, copying, distribution, or use 
of the contents of this message is strictly prohibited. If you have received 
this in error, please destroy it immediately and notify us at 
privacy...@globe.life.

--
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: Spectrum Scale and z/VM

[Marcy Cortes]

I wouldn't think so.   You'd need a client on VM.  
Marcy


-Original Message-
From: Linux on 390 Port  On Behalf Of Jim Elliott
Sent: Monday, September 28, 2020 7:58 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Spectrum Scale and z/VM

Can Spectrum Scale (GPFS) be used as the disk to install z/VM? I know we
can use it for Linux on Z, but wondering if I can get away without any
V disk.

Jim Elliott
Senior IT Consultant - GlassHouse Systems Inc.

--
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: Encryption again - Question on TKE use to CCA

[marcy cortes]

Yes, 1 catcher with control/usage on 1 domain and control on the rest to load 
all the keys on a card.
If we did it on the Linux guest that will actually use the key, I would have to 
move all those guests around to 8 different CEC's in two different datacenters. 
  That's just not going to happen.  I have to have the keys there before it 
gets to the other data center.   So hence a Linux whose only purpose in life is 
to run catcher (hmmm,  how about delivering this as an SSC?)

I don't envision a situation where we have to do lots quickly since the other 
CEC's are available all the time.  We'd just move the servers to where the key 
is available. z/OS has been using keys for a while and they load when a new CEC 
comes in or if a card dies.  And that's about it. 

Linux in an LPAR is a pain, especially in a GPDS and hyperswap environment 
where it's considered a foreign system and so would need its own LCU. We will 
likely just put it on non-replicated disk. The console is the HMC ascii, which 
isn't accessible to Linux engineers- we'd have to get an operator to screen 
share.   So if that Linux doesn't boot after patching, we're looking at some 
fun in recovery.

My thought was to have one per data center.  Bring it up in the LPAR reserved 
for key loading when needed, but then put it back under z/VM (where Linux 
belongs __ ) on a routine basis.  No, I can't just leave it down due to 
compliance reasons (must be subject to scanning and other asset management 
policy tools).

IP changes would be problematic to the authentication software we use.   


On 9/24/20, 10:37 PM, "Linux on 390 Port on behalf of Timothy Sipples" 
 wrote:

Marcy,

It seems like what you're envisioning is to have a "service" image to run 
catcher.exe (slight correction: it's actually catcher.exe rather than 
panel.exe) to facilitate TKE Workstation interactions with various Crypto 
Express CCA mode physical features (and associated domains) spread across 
several machines. That all seems fine to me, but one threshold question 
that comes to mind is whether sharing a single IP address supports "fast 
enough" operations. What I mean is that with a single IP address you'll 
only be able to have one instance of this service image running at any one 
time. If you're in a future situation where you have to perform lots of 
TKE operations across multiple machines/features/domains very quickly -- 
some sort of calamity involving rapid fire TKE operations -- your 
operational "throughput" *could* be significantly limited with only one 
running service image at a time.

A slight, simple variation here would be to have a single service image 
with a default startup IP address but then allow an authorized operator to 
switch the image to a different IP address once that image starts up. That 
way you could have multiple instances of this service image running as 
long as only one of them is starting up at any one time.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.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://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: Encryption again - Question on TKE use to CCA

[Marcy Cortes]

It would have the same IP and hostname.   Disk and network is accessible to all 
CECs .
Thanks for checking!

From: Reinhard Buendgen 
Sent: Thursday, September 24, 2020 9:53 AM
To: Cortes, Marcy D. [PRINCIPAL ENGINEER] 
Cc: LINUX-390@VM.MARIST.EDU
Subject: RE: Encryption again - Question on TKE use to CCA

Hm, wouldn't that "same Linux" (I assume you mean to boot the same image on 
different CECs) have different IP addresses, depending on where you boot it?

I am afraid the TKE could be confused if you really used the same IP address on 
different CECs, but I guess it couldwork and it would "think" you just replaced 
all adapters (assuming the TKE looks at adapter S/Ns).

But if each Linux instance has its own IP address then the TKE should be good 
at connecting to all of them and doing some work in parallel in particular if 
you want to configure the same master keys on multiple adapte domains.

But to be on  the safe side I will check with an TKE expert.

Mit freundlichen Grüßen/Best Regards/Cordialement

Reinhard


Dr. Reinhard Bündgen
Product Owner Security Linux on Z
Linux on Z Development



Mail:buend...@de.ibm.com<mailto:buend...@de.ibm.com>
Phone: ++49-(0)7031-16-1130
Fax: ++49-(0)7031-16-3456




IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294






- Original message -
From: mailto:marcy.d.cor...@wellsfargo.com>>
To: mailto:buend...@de.ibm.com>>
Cc: mailto:LINUX-390@VM.MARIST.EDU>>
Subject: [EXTERNAL] RE: Encryption again - Question on TKE use to CCA
Date: Thu, Sep 24, 2020 6:32 PM


Thank you!



One more question, would TKE be totally confused if I used the same linux, 
moving it CEC to CEC (in an LPAR) to load keys on say 8 boxes?

Or would each CEC need to have its own Linux?



Marcy



From: Reinhard Buendgen mailto:buend...@de.ibm.com>>
Sent: Thursday, September 24, 2020 6:03 AM
To: Cortes, Marcy D. [PRINCIPAL ENGINEER] 
mailto:marcy.d.cor...@wellsfargo.com>>
Cc: LINUX-390@VM.MARIST.EDU<mailto:LINUX-390@VM.MARIST.EDU>
Subject: Re: Encryption again - Question on TKE use to CCA



Hi Marcy,



when using CCA (i.e. the TKE is configured to communicate with panel.exe) no 
authentication will be perfromed.

You need neither enter an ID nor a password just click OK.

This is not considered insecure because all the catcher does is to forward 
signed requests to the crypto adapter.



For EP11 (i.e. if the TKE is configured to communicate with the ep11TKEd) it 
must a Linux user and password configured for the ep11TKEd as described here 
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lxce/lxce_installing_hostpart.html
 (The default setting is to allow any user that has a password configured and 
is member of the ep11tke group to gain access through the ep11TKEd daemon.)



Mit freundlichen Grüßen/Best Regards/Cordialement

Reinhard





Dr. Reinhard Bündgen
Product Owner Security Linux on Z
Linux on Z Development





Mail:buend...@de.ibm.com<mailto:buend...@de.ibm.com>
Phone: ++49-(0)7031-16-1130
Fax: ++49-(0)7031-16-3456





IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


____







- Original message -
From: Marcy Cortes 
mailto:marcy.d.cor...@wellsfargo.com>>
Sent by: Linux on 390 Port 
mailto:LINUX-390@VM.MARIST.EDU>>
To: LINUX-390@VM.MARIST.EDU<mailto:LINUX-390@VM.MARIST.EDU>
Cc:
Subject: [EXTERNAL] Encryption again - Question on TKE use to CCA
Date: Thu, Sep 24, 2020 12:11 AM


In this doc http://public.dhe.ibm.com/software/dw/linux390/docu/l91xct00.pdf 
page 13, what are these credentials?   Where are they defined?


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<mailto:lists...@vm.marist.edu> with the 
message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390<https://urldefense.proofpoint.com/v2/url?u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwMGaQ=jf_iaSHvJObTbx-siA1ZOg=gDiditHI8xOAKhJe7-PksxYsvTcY

Re: Encryption again - Question on TKE use to CCA

[Marcy Cortes]

Thank you!

One more question, would TKE be totally confused if I used the same linux, 
moving it CEC to CEC (in an LPAR) to load keys on say 8 boxes?
Or would each CEC need to have its own Linux?

Marcy

From: Reinhard Buendgen 
Sent: Thursday, September 24, 2020 6:03 AM
To: Cortes, Marcy D. [PRINCIPAL ENGINEER] 
Cc: LINUX-390@VM.MARIST.EDU
Subject: Re: Encryption again - Question on TKE use to CCA

Hi Marcy,

when using CCA (i.e. the TKE is configured to communicate with panel.exe) no 
authentication will be perfromed.
You need neither enter an ID nor a password just click OK.
This is not considered insecure because all the catcher does is to forward 
signed requests to the crypto adapter.

For EP11 (i.e. if the TKE is configured to communicate with the ep11TKEd) it 
must a Linux user and password configured for the ep11TKEd as described here 
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lxce/lxce_installing_hostpart.html
 (The default setting is to allow any user that has a password configured and 
is member of the ep11tke group to gain access through the ep11TKEd daemon.)

Mit freundlichen Grüßen/Best Regards/Cordialement

Reinhard


Dr. Reinhard Bündgen
Product Owner Security Linux on Z
Linux on Z Development



Mail:buend...@de.ibm.com<mailto:buend...@de.ibm.com>
Phone: ++49-(0)7031-16-1130
Fax: ++49-(0)7031-16-3456




IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294






- Original message -----
From: Marcy Cortes 
mailto:marcy.d.cor...@wellsfargo.com>>
Sent by: Linux on 390 Port 
mailto:LINUX-390@VM.MARIST.EDU>>
To: LINUX-390@VM.MARIST.EDU<mailto:LINUX-390@VM.MARIST.EDU>
Cc:
Subject: [EXTERNAL] Encryption again - Question on TKE use to CCA
Date: Thu, Sep 24, 2020 12:11 AM

In this doc http://public.dhe.ibm.com/software/dw/linux390/docu/l91xct00.pdf 
page 13, what are these credentials?   Where are they defined?


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

Encryption again - Question on TKE use to CCA

[Marcy Cortes]

In this doc http://public.dhe.ibm.com/software/dw/linux390/docu/l91xct00.pdf 
page 13, what are these credentials?   Where are they defined?


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: db2 and systemd?

[marcy cortes]

Yea, I don't have a pidfile and it all seems to keep track of which processes.  
I used Type=forking

On 8/19/20, 11:03 AM, "Linux on 390 Port on behalf of Mark Post" 
 wrote:

On 8/18/20 10:47 PM, Grzegorz Powiedziuk wrote:
> Do you specify the pidfile and does the wrapper
> script update pidfile? Without it, systemd probably is not able to figure
> out if service is running or not and probably would make stopping the
> service  with systemctl command difficult.

That should happen automatically within systemd. I would say try without
doing that yourselves, and see if the appropriate pid file shows up
somewhere under /run. If it doesn't show up, then you'll need to write
something yourselves.


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: vmrelocate and quiescence time

[Marcy Cortes]

Why not use DB2 HADR and then you can just do the takeover command?

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

Re: db2 and systemd?

[marcy cortes]

It's not fun...

We have a .service file of type forking that calls a script of ours to
start it and stop it.
systemd is cool with that.
However, if you stop and then start db2 outside of db2 it's no longer
associated with that service and systemd whacks its processes at shutdown
time, resulting generally in a database that needs repair :(   (MQ qmgrs
have the same issue).
So one must remember to always use "systemctl stop/start" instead.
That requires root authority.
DBA's don't get that.
We have something in place for them to use a script authorized in our
security system.  Think sudo on steroids.
Now what if they forget?   Well, we also had to make a monitoring process
that detects if db2 is not started under systemd and nags them to stop it
and start it the correct way.

Hope that helps.

On Tue, Aug 18, 2020 at 3:07 PM Grzegorz Powiedziuk 
wrote:

> Hello, I realize that this is not a typical s390 question but I hope that's
>
> ok if I ask anyway. There is a high chance we have people here who run db2
>
> on zLinux.
>
> How do you solve auto start and more importantly auto stop of DB2 on
>
> start/reboot/shutdowns ?
>
> Seems like the autostart may be handled by a db2fmcd service and db2iauto
>
> but what about autostops when reboot/shutdown is issued.
>
> I am afraid that db2 will be simply killed, am I right? I am not even sure
>
> if having my own stop script would do the trick as systemd might just kill
>
> the db2 processes before my script stops it gracefully
>
> thank you
>
> Gregory
>
>
>
> --
>
> 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
>
> --
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

Re: HA NFS Cluster on RHEL 7

[marcy cortes]

I don’t suppose you have a license for Spectrum Scale either?   ( formerly
known as GPFS)

On Tue, Aug 18, 2020 at 8:34 AM Mittelstädt, David <
david.mittelsta...@dataport.de> wrote:

> Hi everyone,
>
>
>
> In my company I need to set up a HA NFS cluster on RHEL 7 running on z/VM
> 7.1. But my company doesn't have a subscription for the Red Hat High
> Availability or the Resilient Storage Add-On. So I build the packages for
> pacemaker and pcs, used the drbd packages from the epel repository (
> http://download.sinenomine.net/epel/epel-7/s390x/) and build the drbd
> kernel module (kmod-drbd). But this setup doesn't work for me. After
> enabling the kernel module und creating a shared storage device, I couldn't
> boot up the servers anymore (dracut emergency shell). Maybe this was a
> misconfiguration. But I think it would be very difficult to keep the
> software up to date because of the different repositories and ways the
> software will be provided to our servers.
>
>
>
> Do someone know a possibility or has a running HA NFS cluster on RHEL
> without the subscription for the Add-Ons?
>
>
>
> Why is kmod-drbd not part of the epel repository?
>
>
>
> Thanks in advance.
>
>
>
>
>
> Best regards,
>
> David Mittelstädt
>
>
>
> --
>
> 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
>
> --
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

Re: Overcommitting zLinux CPU

[Marcy Cortes]

Each virtual cpu will need to run on a real cpu.So those will end up 
waiting behind themselves and make things worse. 

-Original Message-
From: Linux on 390 Port  On Behalf Of Mariusz Walczak
Sent: Friday, July 31, 2020 4:46 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Overcommitting zLinux CPU

Hello Group,

We have 4 IFL on Mainframe box, 4 IFL on zVM and 4 cpu on zLinux. I'd like
to gain zLinux capacity (run more processes) and increase to 16 cpu. Will I
degrade performance of a single threaded workload if I do this?

All the best,
Mariusz

--
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: z15 on-board compression

[Marcy Cortes]

I didn't see an answer.   
You need 
1. Linux
2. a z15
3. Java 1.8 - any level
4. Something that uses the Java api's to compress/decompress data.

Basically, it can create a compressed thing that is missing an end of file 
marker and deflating it goes into a loop.
WAS has dealt with the deflate problem with iFix PH27505.  The true fix is to 
Java update to be released in August.
In WAS's case, it is cluster description data so it doesn't get very far :)   
Other things that exploit Java's API for it could have the issue.  

Marcy

-Original Message-
From: Linux on 390 Port  On Behalf Of Martha McConaghy
Sent: Wednesday, July 22, 2020 6:20 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] z15 on-board compression

Bill,
Is this issue specific to WAS then?   What about other Java implementations 
such as TomCat?  Would they see the same problem?

Martha

--
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: SYSASCII console use for Linux

[Marcy Cortes]

You might want to take a look at this
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaaf/lnz_r_ht.html



-Original Message-
From: Linux on 390 Port  On Behalf Of Davis, Larry 
(National VM Capability)
Sent: Thursday, July 23, 2020 3:41 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SYSASCII console use for Linux

I found this statement in the Linux-390 archives from Rick Troth and was 
wondering if any one has used this interface or if there are more details on 
using it

*Linux sees an ASCII "system console"*

This is where I had to do a little digging. They don't let me on the HMC
so I have never gotten access to the SYSASCII interface. Sounds like a
great idea. IBM realizes that some mainframe operating systems are
better served with a byte-at-a-time interface. (Call it "ASCII", but the
significant feature is not the character set. Character sets are so 1980.)

z/VM can attach a SYSASCII to a Linux guest. Linux can then use the
SYSASCII console interface and a non-mainframe Linux person would be
perfectly comfortable.


We need a way to give our Linux admins real terminal access to an ASCII 
terminal for Boot Messages and to fix issues that prevent Network access.

The Linux Admins do use an HMC access method for the AIX systems they support 
and want to use the same thing for z/VM Linux servers


  1.  Is this possible if the HMC has access to the z/VM LPAR
  2.  Are there specific Steps to activate the SYSASCII console when attached 
to Linux
 *   Even if I attach SYSASCII to a Linux server it is not actually active

q sysascii

SYSASCII attached to GLTRHEL8 inactive

 *   How to I get SYSACSII activated



Larry Davis
Senior z/VM systems Architect, Enterprise Services
T +1.813.394.4240
DXC Technology dxc.technology


DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 
22102, USA.
DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates. It is intended exclusively for 
the addressee. The substance of this message, along with any attachments, may 
contain proprietary, confidential or privileged information or information that 
is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose. --.

--
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: VM system name

[Marcy Cortes]

+2

-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Monday, July 20, 2020 12:16 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] VM system name

On 7/20/20 1:09 PM, Stewart, Lee wrote:
> +1

OK, that's one (sorry, but retirees who won't use the tool don't help
the business case). Anyone else?


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: VM system name

[Marcy Cortes]

Late to the game, but I would probably make a .service file that did something 
like

ExecStart= echo $(/sbin/vmcp q userid | awk '{print $3}') > /etc/vmsysname

and then anything could look at the file.

An LGR'd guest would be wrong, but I don't think you use that. 

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

Re: Loading vmcp on boot

[Marcy Cortes]

I don't have any SLES 11 to check, but I'm pretty sure there is a 
/etc/modprode.d  or /etc/modprobe.conf that it goes into 



--
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: Loading vmcp on boot

[marcy cortes]

The correct way would be to use /etc/mod probe.d/ for SUSE



On Tue, Jun 30, 2020 at 10:24 AM Edgington, Jerry <
jerry.edging...@westernsouthernlife.com> wrote:

> Here is an example for Redhat.
>
> [root@u060rh7gld system]# more vmcpdetach.target
> [Unit]
> Description= Detach z/VM mdisk
> Requires=local-fs.target
> After=local-fs.target
>
> [Install]
> WantedBy=multi-user.target
> [root@u060rh7gld system]# more vmcpdetach.service
> [Unit]
> Description=Detach z/VM Mdisk
> Requires=findself.target
> After=findself.target
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> StandardError=syslog+console
> ExecStart=/usr/local/bin/vmcpdetach.sh
>
> [Install]
> WantedBy=vmcpdetach.target
> Also=vmcpdetach.target
>
> For /etc/rc.d/init.d
>
> ○ Vmcpdetach
> Chkconfig vmcpdetach on
>
>
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Frank Wolfe
> Sent: Tuesday, June 30, 2020 12:46 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Loading vmcp on boot
>
> This message was sent from an external source outside of Western &
> Southern's network. Do not click links or open attachments unless you
> recognize the sender and know the contents are safe.
>
> 
>
> Hi,
>
> I need the modprobe vmcp module to be loaded on boot which it is not on
> SLES11. Can anyone please tell me how to enable this?
>
> Regards,
> Frank
>
> --
> 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
>
-- 
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

Encrypted volumes opening at boot time - crypttab fail

[Marcy Cortes]

   01.002d
Key file name: /etc/zkey/repository/xtskey-e000.skey
Sector size  : 4096 bytes
Volume type  : LUKS2
Verification pattern : cbd966000f0da3bf675923fc44332bac
   84100bb540f6b00f596b76ceacf9cb41
Created  : 2020-06-25 19:12:33
Changed  : 2020-06-26 11:47:02
Re-enciphered: (never)

Marcy Cortes

VP/Principal Engineer, z/VM and Linux on IBM z Systems
Technology Infrastructure / Core Engineering / Mainframe/Midrange Services (MMS)

Wells Fargo Bank | MAC A2809-010  | San Francisco
Cell 415-517-0895

marcy.d.cor...@wellsfargo.com<mailto:marcy.d.cor...@wellsfargo.com>

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

Encrypted volumes opening at boot time - crypttab fail

[marcy cortes]

 size   : 512 bits

XTS type key : Yes

Volumes  : /dev/disk/by-id/ccw-0XE000-part1:enc-e000

APQNs: 00.002d

   01.002d

Key file name: /etc/zkey/repository/xtskey-e000.skey

Sector size  : 4096 bytes

Volume type  : LUKS2

Verification pattern : cbd966000f0da3bf675923fc44332bac

   84100bb540f6b00f596b76ceacf9cb41

Created  : 2020-06-25 19:12:33

Changed  : 2020-06-26 11:47:02

Re-enciphered: (never)



Marcy Cortes



VP/Principal Engineer, z/VM and Linux on IBM z Systems

Technology Infrastructure / Core Engineering / Mainframe/Midrange Services
(MMS)



Wells Fargo Bank | MAC A2809-010  | San Francisco

Cell 415-517-0895



marcy.d.cor...@wellsfargo.com



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.


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

Re: Dracut error after Booting default (grub) message

[Marcy Cortes]

We ran into similar again on a couple of servers a week or two ago for unknown 
reasons.   Neither had recent disk changes.
This solved it for us

Boot with rescue media
vary on the devices with chzdev -e
Make a chroot environment with the following (your filesystems may vary) 

mount /dev/dasda1 /mnt
mount -t proc none /mnt/proc
mount --rbind /dev /mnt/dev
mount --rbind /sys /mnt/sys
mount /dev/mapper/system-var--lv /mnt/var
mount /dev/mapper/system-usr--lv /mnt/usr
mount /dev/mapper/system-tmp--lv /mnt/tmp
mount /dev/mapper/system-home--lv /mnt/home
mount /dev/mapper/system-opt--lv /mnt/opt
chroot /mnt /bin/bash
mount -a

Then this solved it:
rescue:/ # vgs
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Not repairing metadata for VG system.
Recovery of volume group "system" failed.
rescue:/ # vgscan
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Reading all physical volumes. This may take a while...
WARNING: Inconsistent metadata found for VG system - updating to use version 10
Found volume group "system" using metadata type lvm2
rescue:/ # vgscan
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Reading all physical volumes. This may take a while...
Found volume group "system" using metadata type lvm2 
rescue:/ # vgs
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
VG #PV #LV #SN Attr VSize VFree
system 2 5 0 wz--n- 15.10g 88.00m


The second server told us it was "updating to use version 11"

Not sure what that means - both had the same software on them.  



-Original Message-
From: Linux on 390 Port  On Behalf Of Victor Echavarry
Sent: Wednesday, May 13, 2020 1:02 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Dracut error after Booting default (grub) message

After various testing we found that the issue making the system doesn't boot is 
when expanding the LVM OS file system, ex. /opt, /var. The Unix administrator 
send a photo of a message when he resized the filesystem.

https://imgur.com/j57a7aL

When he reboots the system, the system stop under Booting default (grub2) for a 
couple of minutes and then show the Dracut message going to Give root password 
for maintenance
(or press Control-D to continue):

Right now there an open case under SUSE waiting for a solution.

Regards,

Victor Echavarry
System Programmer
Operating Systems
EVERTEC, LLC



-Original Message-
From: Linux on 390 Port  On Behalf Of Marcy Cortes
Sent: Wednesday, April 29, 2020 7:54 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Dracut error after Booting default (grub) message

you aren't the only one.

Something's definitely different.  Open a case with your Linux support.

For all least all of the system volumes (ones needed to boot) , consider 
erasing the 51-dasd* rules in /etc/udev/rules.d and then using "chzdev -e " to 
put back new 41-dasd-eckd* rules.
Then running mkinitrd
Then running grub2-mkconfig -o /boot/grub2/grub.cfg; grub2-install

These things or some combo of them have solved it when we hit it (after using 
rescue system get to a point where we could do this)

You can also "cat /run/initramfs/rdsosreport.txt" to get more info.  It will 
like complain of some missing devices or maybe  you simply have to vgscan or 
vgchange -ay that rootvg

Or boot with parm rd.debug as Mark Post mentioned here last week.





-Original Message-
From: Linux on 390 Port  On Behalf Of Victor Echavarry
Sent: Wednesday, April 29, 2020 2:40 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Dracut error after Booting default (grub) message

Hi:

The Unix Group is having an internment issue patching SLES Linux guest. They 
patch every Linux guest on a monthly basis. A server patch various month 
without a problem and for some unexplained reason after a successful  
patch and  reboot or IPL the guest, shows a warning error and go to Emergency 
Shell

DIAG swap disk defined at virtual address 160 (24789 4K pages of swap space) 
Enter a non-blank character and ENTER (or two ENTERs) within 10 seconds to 
interrupt Linux IPL.
DMSCYW2246I 16:31:36 WAKEUP in (10 sec).
DASD 0190 DETACHED
DASD 0191 DETACHED
DASD 019E DETACHED
Booting default (grub2)

dracut-initqueue[347]: Warning: dracut-initqueue timeout - starting timeout 
scripts
dracut-initqueue[347]: Warning: dracut-initqueue timeout - starting timeout 
scripts
dracut-initqueue[347]: Warning: dracut-initqueue timeout - starting timeout 
scripts .
.
.
.
dracut-initqueue[347]: Warning: Could not boot.
 Starting Dracut Emergency Shell...
Warning: /dev/mapper/rootvg-usrlv does not exist
Warning: /dev/rootvg/usrlv 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 t

Re: FW: Dracut error after Booting default (grub) message

[marcy cortes]

> you aren't the only one.
>
> Something's definitely different.  Open a case with your Linux support.
>
> For at least all of the system volumes (ones needed to boot) , consider
> erasing the 51-dasd* rules in /etc/udev/rules.d and then using "chzdev -e "
> to put back new 41-dasd-eckd* rules.
> Then running mkinitrd
> Then runninggrub2-mkconfig -o /boot/grub2/grub.cfg; grub2-install
>
> These things or some combo of them have solved it when we hit it (after
> using rescue system get to a point where we could do this)
>
> You can also "cat /run/initramfs/rdsosreport.txt" to get more info.  It
> will like complain of some missing devices or maybe  you simply have to
> vgscan or vgchange -ay that rootvg
>
> Or boot with parm rd.debug as Mark Post mentioned here last week



Marcy


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

Re: Dracut error after Booting default (grub) message

[Marcy Cortes]

you aren't the only one.

Something's definitely different.  Open a case with your Linux support. 

For all least all of the system volumes (ones needed to boot) , consider 
erasing the 51-dasd* rules in /etc/udev/rules.d and then using "chzdev -e " to 
put back new 41-dasd-eckd* rules. 
Then running mkinitrd
Then runninggrub2-mkconfig -o /boot/grub2/grub.cfg; grub2-install

These things or some combo of them have solved it when we hit it (after using 
rescue system get to a point where we could do this)

You can also "cat /run/initramfs/rdsosreport.txt" to get more info.  It will 
like complain of some missing devices or maybe  you simply have to vgscan or 
vgchange -ay that rootvg 

Or boot with parm rd.debug as Mark Post mentioned here last week. 





-Original Message-
From: Linux on 390 Port  On Behalf Of Victor Echavarry
Sent: Wednesday, April 29, 2020 2:40 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Dracut error after Booting default (grub) message

Hi:

The Unix Group is having an internment issue patching SLES Linux guest. They 
patch every Linux guest on a monthly basis. A server patch various month 
without a problem and for some unexplained reason after a successful  
patch and  reboot or IPL the guest, shows a warning error and go to Emergency 
Shell

DIAG swap disk defined at virtual address 160 (24789 4K pages of swap space)
Enter a non-blank character and ENTER (or two ENTERs) within 10
seconds to interrupt Linux IPL.
DMSCYW2246I 16:31:36 WAKEUP in (10 sec).
DASD 0190 DETACHED
DASD 0191 DETACHED
DASD 019E DETACHED
Booting default (grub2)

dracut-initqueue[347]: Warning: dracut-initqueue timeout - starting timeout 
scripts
dracut-initqueue[347]: Warning: dracut-initqueue timeout - starting timeout 
scripts
dracut-initqueue[347]: Warning: dracut-initqueue timeout - starting timeout 
scripts
.
.
.
.
dracut-initqueue[347]: Warning: Could not boot.
 Starting Dracut Emergency Shell...
Warning: /dev/mapper/rootvg-usrlv does not exist
Warning: /dev/rootvg/usrlv 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):

Does anyone saw this before and tell us what to do? We have SLES 12 SP5 under 
z/VM 6.4.

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

--
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: BCACHE errors on lvextend, on reboot goes to dracut emergency mode

[marcy cortes]

Try when you are in that shell
vgchange -ay system

You may have to chzdev -e first



On Tue, Apr 21, 2020 at 9:21 AM Will, Chris  wrote:

> This has now happened on two SLES 12 SP4 that have had any of the LVM root
> file system (/var /tmp, etc) expanded (lvextend).  Here is the error
> message.
> sles12osdev2:~ # lvextend -L +2G /dev/mapper/system--vg-opt--lv
> scan_dev_close /dev/dasda2 no DEV_IN_BCACHE set
> scan_dev_close /dev/dasdc1 no DEV_IN_BCACHE set
> Size of logical volume system-vg/opt-lv changed from 4.00 GiB (1024
> extents) to 6.00 GiB (1536 extents).
> Logical volume system-vg/opt-lv successfully resized.
> close /dev/dasdc1 errno 9
> sles12osdev2:~ # xfs_growfs /opt
> meta-data=/dev/mapper/system--vg-opt--lv isize=512 agcount=4,
> agsize=262144 blks
> = sectsz=4096 attr=2, projid32bit=1
> = crc=1 finobt=0 spinodes=0 rmapbt=0
> = reflink=0
> data = bsize=4096 blocks=1048576, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0 ftype=1
> log =internal bsize=4096 blocks=2560, version=2
> = sectsz=4096 sunit=1 blks, lazy-count=1
> realtime =none extsz=4096 blocks=0, rtextents=0
> data blocks changed from 1048576 to 1572864ere are the error messages
>
> In this case I was able to get into the Dracut emergency console, I was
> able to chroot and it seemed to fix whatever was wrong by running a lvscan.
>
>
> I exited the Dracut shell and it went to a disabled wait. Brought it up in
> emergency mode, set up chroot and got the following. The lvscan seemed to
> repair the system-vg metadata. Now the system will boot.
>
> nbxdv0392:/ # mount -a
> Failed to connect to bus: No such file or directory
> mount.nfs: rpc.statd is not running but is required for remote locking.
> mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
>
> nbxdv0392:/ # pvs
> WARNING: Failed to connect to lvmetad. Falling back to device scanning.
> Not repairing metadata for VG system-vg.
> Recovery of volume group "system-vg" failed.
> Cannot process volume group system-vg
> nbxdv0392:/ # lvscan < WARNING: Failed to connect to lvmetad. Falling back to device scanning.
> WARNING: Inconsistent metadata found for VG system-vg - updating to use
> version 8 n 8
> ACTIVE '/dev/system-vg/home-lv' [4.00 GiB] inherit
> ACTIVE '/dev/system-vg/opt-lv' [4.00 GiB] inherit
> ACTIVE '/dev/system-vg/tmp-lv' [6.00 GiB] inherit
> ACTIVE '/dev/system-vg/usr-lv' [4.00 GiB] inherit
> ACTIVE '/dev/system-vg/var-lv' [4.00 GiB] inherit
> nbxdv0392:/ # vgscan
> WARNING: Failed to connect to lvmetad. Falling back to device scanning.
> Reading all physical volumes. This may take a while...
> Found volume group "system-vg" using metadata type lvm2
> nbxdv0392:/ # pvs
> WARNING: Failed to connect to lvmetad. Falling back to device scanning.
> PV VG Fmt Attr PSize PFree
> /dev/dasda2 system-vg lvm2 a-- 18.49g 504.00m
> /dev/dasdb1 system-vg lvm2 a-- 22.49g 18.49g
>
> Has anyone run into something like this?  I would like to fix this
> proactively and not wait until the server dies and I have to go into
> emergency mode.  This could be an issue with all our servers.
>
> 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.
>
> --
> 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
>
--
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

Re: BCACHE errors on lvextend, on reboot goes to dracut emergency mode

[marcy cortes]

Yes, we had this in two forms.   Both fixed by the dracut fix (and
rerunning it)



Subject: SR101238520451 Re dracut timeout problems after
patching



Marcy,

   We released this fix in maint
(dracut-044.2-10.15.2.s390x).  The other issue related to this:



SR101237346921 Re: SLES Sp4 problem with
lvm and device names




On Tue, Apr 21, 2020 at 10:26 AM Mark Post  wrote:

> On 4/21/20 12:11 PM, Will, Chris wrote:
> > Has anyone run into something like this?  I would like to fix this
> proactively and not wait until the server dies and I have to go into
> emergency mode.  This could be an issue with all our servers.
>
>
> Hi, Chris,
>
> I really thing the BCACHE messages are a red herring. I'm not at all
> sure what the real cause of the problem is, but I don't think it's that.
>
> Have you opened a problem with your support provider? I think a lot more
> information is going to be needed to help you with this.
>
> As far as being proactive, there are a number of things you can try. I
> don't know that any of them will actually prevent the problem, since we
> don't really know what's causing it. The "Inconsistent metadata found
> for VG system-vg - updating to use version 8 n 8" message is the most
> interesting data point from what I can tell.
>
> If you possibly can, I would try to clone the DASD volume(s) that make
> up one of your other existing SLES12 SP4 systems, and see if you can
> recreate the problem. If so, then re-clone the volume(s), and try doing
> something like this:
> pvscan
> vgscan
> pvck /dev/dasd?? (for each physical volume)
> lvscan
>
> Then try extending a logical volume again and see if the problem
> reoccurs or not. This is very much stabbing in the dark, but it might
> provide some relief.
>
>
> 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
>
--
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

Re: BCACHE errors on lvextend, on reboot goes to dracut emergency mode

[Marcy Cortes]

Yes, we had this in two forms.   Both fixed by the dracut fix (and rerunning 
it) 

Subject: SR101238520451 Re dracut timeout problems after patching

Marcy, 
We released this fix in maint (dracut-044.2-10.15.2.s390x).  
The other issue related to this:

SR101237346921 Re: SLES Sp4 problem with lvm and device names



-Original Message-
From: Linux on 390 Port  On Behalf Of Will, Chris
Sent: Tuesday, April 21, 2020 9:12 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] BCACHE errors on lvextend, on reboot goes to dracut 
emergency mode

This has now happened on two SLES 12 SP4 that have had any of the LVM root file 
system (/var /tmp, etc) expanded (lvextend).  Here is the error message.
sles12osdev2:~ # lvextend -L +2G /dev/mapper/system--vg-opt--lv
scan_dev_close /dev/dasda2 no DEV_IN_BCACHE set
scan_dev_close /dev/dasdc1 no DEV_IN_BCACHE set
Size of logical volume system-vg/opt-lv changed from 4.00 GiB (1024 extents) to 
6.00 GiB (1536 extents).
Logical volume system-vg/opt-lv successfully resized.
close /dev/dasdc1 errno 9
sles12osdev2:~ # xfs_growfs /opt
meta-data=/dev/mapper/system--vg-opt--lv isize=512 agcount=4, agsize=262144 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=0 spinodes=0 rmapbt=0
= reflink=0
data = bsize=4096 blocks=1048576, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 1048576 to 1572864ere are the error messages

In this case I was able to get into the Dracut emergency console, I was able to 
chroot and it seemed to fix whatever was wrong by running a lvscan.


I exited the Dracut shell and it went to a disabled wait. Brought it up in 
emergency mode, set up chroot and got the following. The lvscan seemed to 
repair the system-vg metadata. Now the system will boot.

nbxdv0392:/ # mount -a
Failed to connect to bus: No such file or directory
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.

nbxdv0392:/ # pvs
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Not repairing metadata for VG system-vg.
Recovery of volume group "system-vg" failed.
Cannot process volume group system-vg
nbxdv0392:/ # lvscan 

Re: Adding disk to root LVM with RHEL 7

[Marcy Cortes]

..."
Warning: /dev/mapper/rhel_opncl41-root 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.






Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Vice President

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Marcy Cortes 

Sent: Wednesday, April 15, 2020 11:42 AM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Adding disk to root LVM with RHEL 7

I'm kind of assuming RH7 works like sles11 and doesn't use grub2, but did you 
"mkinird; zipl" after getting that disk online?

You can also "cat / run/initramfs/rdsosreport.txt" in that emergency mode to 
get more details.




-Original Message-
From: Linux on 390 Port  On Behalf Of Rick Troth
Sent: Wednesday, April 15, 2020 8:26 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Adding disk to root LVM with RHEL 7

Looks like you did everything right: online, dasdfmt, fdasd, lvextend,
vgextend, and using "1" instead of the whole disk (because it's ECKD and
requires the VTOC).

The first block where you get an error is 16380912. Maybe that's a clue?
Looks like cylinder #109206 (150 4K blocks per ECKD cyl). Someone check
my math? And the (new) root FS looks like 110100 cyls.
The VG has two disks, correct? How big are they?
So where is this troublesome block in the grand scheme?

I don't recall resizing a filesystem *down*, but I think it can be done.
I'm always nervous about that last block (or several) in any filesystem,
any backing store (CKD, FBA, SCSI/SAN), anymode (LVM, partitioned, whole).
Never know when the system or some program will walk to the end "just
because".

-- R; <><


On 4/15/20 10:58 AM, Martha McConaghy wrote:
> I have servers that I'm setting up with RHEL 7.8 on ECKD disk.  I installed 
> it with root in an LVM, all of that worked fine.  Now, I'm testing adding a 
> 2nd ECKD disk to the LVM as I know that will be required in the future, but 
> I'm running into a confusing problem.  Everything works as I expect and the 
> disk space shows up in / as it should.  When I reboot the server, however, it 
> goes to heck and ends up in emergency mode.  The most prominent feature of 
> the console are a bunch of I/O errors on device dm-2, which is the disk I 
> just added.  Below are the steps I followed to add the disk.  Before doing 
> this, I had activated the disk, added it to /etc/dasd.conf and run zipl.  
> After doing that, I rebooted to ensure that the disk came up online, which it 
> did.  So, I'm confident that the disk is there when the system rebooted the 
> 2nd time.
>
> I have a lot of colleagues who work with Linux all the time, but don't 
> usually have root as an LVM.  They haven't seen this problem before, but they 
> work mainly on X.  Could this be specific problem to using ECKD?  I have 
> thought of going to an FBA LUN, but had spare ECKD to use.
>
> Martha
>
>
> [root@opncl42 ~]# cio_ignore -r 0.0.0200
> [root@opncl42 ~]# chccwdev --online 0.0.0200
> Setting device 0.0.0200 online
> Done
> [root@opncl42 ~]# lsdasd
> Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
> ==
> 0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
> 0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
> [root@opncl42 ~]# vi /etc/dasd.conf
> [root@opncl42 ~]# zipl
> Using config file '/etc/zipl.conf'
> Building bootmap in '/boot'
> Building menu 'zipl-automatic-menu'
> Adding #1: IPL section '3.10.0-1127.el7.s390x' (default)
> Adding #2: IPL section '3.10.0-1127.el7.s390x_with_debugging'
> Adding #3: IPL section 'linux'
> Preparing boot device: dasda (0150).
> Done.
> [root@opncl42 ~]# reboot
> ---
> [root@opncl42 ~]# lsdasd
> Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
> ==
> 0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
> 0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
>
> [root@opncl42 ~]# dasdfmt -p -f /dev/dasdb
> Please enter the blocksize of the formatting [4096]:
> Drive Geometry: 32759 Cylinders * 15 Heads =  491385 Tracks
>
> I am going to format the device /dev/dasdb in the following way:
>Device number of device : 0x200
>Labelling device: yes
>Disk label  : VOL1
>Disk identifier : 0

Re: Adding disk to root LVM with RHEL 7

[Marcy Cortes]

Martha not Marcy :) 


-Original Message-
From: Linux on 390 Port  On Behalf Of Cohen, Sam
Sent: Wednesday, April 15, 2020 8:55 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Adding disk to root LVM with RHEL 7

Marcy,

Did you check zipl.conf to see if you need to list the disk in the rd.dasd line 
or cio_ignore (which is so unnecessary when running under z/VM).

Thanks,

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

-Original Message-
From: Linux on 390 Port  On Behalf Of Marcy Cortes
Sent: Wednesday, April 15, 2020 8:43 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Adding disk to root LVM with RHEL 7

I'm kind of assuming RH7 works like sles11 and doesn't use grub2, but did you 
"mkinird; zipl" after getting that disk online?

You can also "cat / run/initramfs/rdsosreport.txt" in that emergency mode to 
get more details.




-Original Message-
From: Linux on 390 Port  On Behalf Of Rick Troth
Sent: Wednesday, April 15, 2020 8:26 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Adding disk to root LVM with RHEL 7

Looks like you did everything right: online, dasdfmt, fdasd, lvextend, 
vgextend, and using "1" instead of the whole disk (because it's ECKD and 
requires the VTOC).

The first block where you get an error is 16380912. Maybe that's a clue?
Looks like cylinder #109206 (150 4K blocks per ECKD cyl). Someone check my 
math? And the (new) root FS looks like 110100 cyls.
The VG has two disks, correct? How big are they?
So where is this troublesome block in the grand scheme?

I don't recall resizing a filesystem *down*, but I think it can be done.
I'm always nervous about that last block (or several) in any filesystem, any 
backing store (CKD, FBA, SCSI/SAN), anymode (LVM, partitioned, whole).
Never know when the system or some program will walk to the end "just because".

-- R; <><


On 4/15/20 10:58 AM, Martha McConaghy wrote:
> I have servers that I'm setting up with RHEL 7.8 on ECKD disk.  I installed 
> it with root in an LVM, all of that worked fine.  Now, I'm testing adding a 
> 2nd ECKD disk to the LVM as I know that will be required in the future, but 
> I'm running into a confusing problem.  Everything works as I expect and the 
> disk space shows up in / as it should.  When I reboot the server, however, it 
> goes to heck and ends up in emergency mode.  The most prominent feature of 
> the console are a bunch of I/O errors on device dm-2, which is the disk I 
> just added.  Below are the steps I followed to add the disk.  Before doing 
> this, I had activated the disk, added it to /etc/dasd.conf and run zipl.  
> After doing that, I rebooted to ensure that the disk came up online, which it 
> did.  So, I'm confident that the disk is there when the system rebooted the 
> 2nd time.
>
> I have a lot of colleagues who work with Linux all the time, but don't 
> usually have root as an LVM.  They haven't seen this problem before, but they 
> work mainly on X.  Could this be specific problem to using ECKD?  I have 
> thought of going to an FBA LUN, but had spare ECKD to use.
>
> Martha
>
>
> [root@opncl42 ~]# cio_ignore -r 0.0.0200
> [root@opncl42 ~]# chccwdev --online 0.0.0200 Setting device 0.0.0200 
> online Done
> [root@opncl42 ~]# lsdasd
> Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
> ==
> 0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
> 0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
> [root@opncl42 ~]# vi /etc/dasd.conf
> [root@opncl42 ~]# zipl
> Using config file '/etc/zipl.conf'
> Building bootmap in '/boot'
> Building menu 'zipl-automatic-menu'
> Adding #1: IPL section '3.10.0-1127.el7.s390x' (default) Adding #2: 
> IPL section '3.10.0-1127.el7.s390x_with_debugging'
> Adding #3: IPL section 'linux'
> Preparing boot device: dasda (0150).
> Done.
> [root@opncl42 ~]# reboot
> ---
> [root@opncl42 ~]# lsdasd
> Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
> ==
> 0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
> 0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
>
> [root@opncl42 ~]# dasdfmt -p -f /dev/dasdb Please enter the blocksize 
> of the formatting [4096]:
> Drive Geometry: 32759 Cylinders * 15 Heads =  491385 Tracks
>
> I am going to format the device /dev/dasdb in the following way:
>Device number of device : 0x200
>Labelling device: yes
>Disk label  : VOL1
>Disk identifier : 0X0200
>Extent start (trk no)   : 0
>Extent e

Re: Adding disk to root LVM with RHEL 7

[Marcy Cortes]

I'm kind of assuming RH7 works like sles11 and doesn't use grub2, but did you 
"mkinird; zipl" after getting that disk online?

You can also "cat / run/initramfs/rdsosreport.txt" in that emergency mode to 
get more details.




-Original Message-
From: Linux on 390 Port  On Behalf Of Rick Troth
Sent: Wednesday, April 15, 2020 8:26 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Adding disk to root LVM with RHEL 7

Looks like you did everything right: online, dasdfmt, fdasd, lvextend,
vgextend, and using "1" instead of the whole disk (because it's ECKD and
requires the VTOC).

The first block where you get an error is 16380912. Maybe that's a clue?
Looks like cylinder #109206 (150 4K blocks per ECKD cyl). Someone check
my math? And the (new) root FS looks like 110100 cyls.
The VG has two disks, correct? How big are they?
So where is this troublesome block in the grand scheme?

I don't recall resizing a filesystem *down*, but I think it can be done.
I'm always nervous about that last block (or several) in any filesystem,
any backing store (CKD, FBA, SCSI/SAN), anymode (LVM, partitioned, whole).
Never know when the system or some program will walk to the end "just
because".

-- R; <><


On 4/15/20 10:58 AM, Martha McConaghy wrote:
> I have servers that I'm setting up with RHEL 7.8 on ECKD disk.  I installed 
> it with root in an LVM, all of that worked fine.  Now, I'm testing adding a 
> 2nd ECKD disk to the LVM as I know that will be required in the future, but 
> I'm running into a confusing problem.  Everything works as I expect and the 
> disk space shows up in / as it should.  When I reboot the server, however, it 
> goes to heck and ends up in emergency mode.  The most prominent feature of 
> the console are a bunch of I/O errors on device dm-2, which is the disk I 
> just added.  Below are the steps I followed to add the disk.  Before doing 
> this, I had activated the disk, added it to /etc/dasd.conf and run zipl.  
> After doing that, I rebooted to ensure that the disk came up online, which it 
> did.  So, I'm confident that the disk is there when the system rebooted the 
> 2nd time.
>
> I have a lot of colleagues who work with Linux all the time, but don't 
> usually have root as an LVM.  They haven't seen this problem before, but they 
> work mainly on X.  Could this be specific problem to using ECKD?  I have 
> thought of going to an FBA LUN, but had spare ECKD to use.
>
> Martha
>
>
> [root@opncl42 ~]# cio_ignore -r 0.0.0200
> [root@opncl42 ~]# chccwdev --online 0.0.0200
> Setting device 0.0.0200 online
> Done
> [root@opncl42 ~]# lsdasd
> Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
> ==
> 0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
> 0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
> [root@opncl42 ~]# vi /etc/dasd.conf
> [root@opncl42 ~]# zipl
> Using config file '/etc/zipl.conf'
> Building bootmap in '/boot'
> Building menu 'zipl-automatic-menu'
> Adding #1: IPL section '3.10.0-1127.el7.s390x' (default)
> Adding #2: IPL section '3.10.0-1127.el7.s390x_with_debugging'
> Adding #3: IPL section 'linux'
> Preparing boot device: dasda (0150).
> Done.
> [root@opncl42 ~]# reboot
> ---
> [root@opncl42 ~]# lsdasd
> Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
> ==
> 0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
> 0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
>
> [root@opncl42 ~]# dasdfmt -p -f /dev/dasdb
> Please enter the blocksize of the formatting [4096]:
> Drive Geometry: 32759 Cylinders * 15 Heads =  491385 Tracks
>
> I am going to format the device /dev/dasdb in the following way:
>Device number of device : 0x200
>Labelling device: yes
>Disk label  : VOL1
>Disk identifier : 0X0200
>Extent start (trk no)   : 0
>Extent end (trk no) : 491384
>Compatible Disk Layout  : yes
>Blocksize   : 4096
>Mode: Full
>
> --->> ATTENTION! <<---
> All data of that device will be lost.
> Type "yes" to continue, no will leave the disk untouched: yes
> Formatting the device. This may take a while (get yourself a coffee).
> cyl   32759 of   32759 |#|100% [2m 43s]
> Finished formatting the device.
> Rereading the partition table... ok
> [root@opncl42 ~]# pvcreate /dev/dasdb1
>   Device /dev/dasdb1 not found.
> [root@opncl42 ~]# fdasd /dev/dasdb
> reading volume label ..: VOL1
> reading vtoc ..: ok
>
> Command action
>m   print this menu
>p   print the partition table
>n   add a new partition
>d   delete a partition
>v   change volume serial
>t   change partition type
>r   re-create VTOC and 

Re: Quick question on single user mode

[Marcy Cortes]

There's been quite a lot of fixes to the lvm2 package.  are you current?


-Original Message-
From: Linux on 390 Port  On Behalf Of Will, Chris
Sent: Monday, April 6, 2020 9:26 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Quick question on single user mode

Here is the error message we are getting when expanding one of the lvm root 
directories.  When we try to reboot the server it goes to a disabled wait or 
asking for a root password which it keeps rejecting.  We were able to expand 
the root file system on SLES 12 SP3 with no issues.

sles12osdev2:~ # lvextend -L +2G /dev/mapper/system--vg-opt--lv
  scan_dev_close /dev/dasda2 no DEV_IN_BCACHE set << On Behalf Of Mark Post
Sent: Sunday, April 05, 2020 4:06 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Quick question on single user mode

[External email]


On 3/13/20 10:26 AM, Will, Chris wrote:
> Is there any way to avoid the emergency mode asking for a password for both 
> the /boot/zipl initial boot and /boot/grub2.

One way to do that is to specify "init=/bin/bash" on the IPL command. Of course 
that means you have to do *everything* the system would have done for you 
before it failed. But, if what you need is the biggest hammer you can find, 
that's 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


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

--
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: Quick question on single user mode

[Marcy Cortes]

Here's what I have in my notes from when we had issues with SP4 vs new disks

Once you get the rescue system loaded, activate the devices
chzdev -e 0101-01ff
vgscan
if you think you might have an LVM problem and it went inactivate, activate VG 
perhaps (vgchange -ay vgname)

If you need to rewrite zipl or grub and need a chroot environment, I did this
mount /dev/dasda1 /mnt
mount -t proc none /mnt/proc
mount --rbind /dev /mnt/dev
mount --rbind /sys /mnt/sys
mount /dev/mapper/system-var /mnt/var
mount /dev/mapper/system-usr /mnt/usr
mount /dev/mapper/system-tmp /mnt/tmp
mount /dev/mapper/system-home /mnt/home
mount /dev/mapper/system-opt /mnt/opt
chroot /mnt /bin/bash
mount -a

Now you can run zipl or grub2install -f  or perhaps passwd change on root 




-Original Message-
From: Linux on 390 Port  On Behalf Of Will, Chris
Sent: Friday, March 13, 2020 7:26 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Quick question on single user mode

I was able to get a rescue system put together, activated dasd, mounted file 
systems and the chroot and everything looked "perfect".  I changed the root 
password but on the reboot it still rejected what I was entering.  That leads 
to suspect that this is crashing during the initial boot and it cannot find the 
boot partition or some other error.  Our boot partition not only has the /boot 
directory but the /etc directory so if it can't find that it would not have 
access to the root password.  Is there any way to avoid the emergency mode 
asking for a password for both the /boot/zipl initial boot and /boot/grub2.  I 
would guess that any updates for the grug2 config would be made to 
/etc/default/grub.

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

-Original Message-
From: Will, Chris 
Sent: Thursday, March 12, 2020 10:55 AM
To: i_mugz...@securiteam.co.il; LINUX-390@VM.MARIST.EDU
Subject: RE: Quick question on single user mode

Hello and thanks for all the help.  I am trying to put together a rescue 
system, we have some parms we used for upgrading our system and I think I would 
have to change "upgrade=1" to "rescue=1".

What I would like to do is via ssh:

1. fix root password
2. verify vg name and lv for our xfs root file systems (/usr /var /home /opt 
/tmp) 3. Possibly run mkinitrd

ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc TERM=dumb upgrade=1 
< On Behalf Of ITschak Mugzach
Sent: Thursday, March 12, 2020 3:07 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Quick question on single user mode

[External email]


Mark,

I was able not to specify password and fix my SLES issues. the disks are 
mounted but the file system is organized differently. If I remember correctly, 
I reach such pages because I didn't have the root password. not sure thi is the 
OP issue.

ITschak
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring for 
z/OS, x/Linux & IBM I **| z/VM comming son  *




On Wed, Mar 11, 2020 at 9:31 PM Mark Post  wrote:

> On 3/11/20 9:39 AM, Will, Chris wrote:
> > Sorry about that, since our move to zCloud I do not have access to 
> > the
> 3270 console and all I received was a picture of the console messages.  
> I pulled out as much text as possible and here it is.
>
> How are you specifying the IPL command and any parameters then? I 
> think we need to understand how things are supposed to work for you so 
> that we can better provide assistance.
>
> If you can't get to the console of the guest, then trying to get into 
> single user mode or anything like that isn't going to help at all. One 
> possibility might be to try and specify "hvc_iucv=8 console=hvc0 
> init=/bin/bash" on the command line, and use the terminal server tools 
> from another guest to get access.
>
>
> 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


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.

Re: Quick question on single user mode

[Marcy Cortes]

if you delete stuff, it will just prompt you for it.  Which is good.


-Original Message-
From: Linux on 390 Port  On Behalf Of Will, Chris
Sent: Thursday, March 12, 2020 7:55 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Quick question on single user mode

Hello and thanks for all the help.  I am trying to put together a rescue 
system, we have some parms we used for upgrading our system and I think I would 
have to change "upgrade=1" to "rescue=1".

What I would like to do is via ssh:

1. fix root password
2. verify vg name and lv for our xfs root file systems (/usr /var /home /opt 
/tmp)
3. Possibly run mkinitrd

ramdisk_size=131072 root=/dev/ram1 ro init=/linuxrc TERM=dumb upgrade=1 
< On Behalf Of ITschak Mugzach
Sent: Thursday, March 12, 2020 3:07 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Quick question on single user mode

[External email]


Mark,

I was able not to specify password and fix my SLES issues. the disks are 
mounted but the file system is organized differently. If I remember correctly, 
I reach such pages because I didn't have the root password. not sure thi is the 
OP issue.

ITschak
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring for 
z/OS, x/Linux & IBM I **| z/VM comming son  *




On Wed, Mar 11, 2020 at 9:31 PM Mark Post  wrote:

> On 3/11/20 9:39 AM, Will, Chris wrote:
> > Sorry about that, since our move to zCloud I do not have access to 
> > the
> 3270 console and all I received was a picture of the console messages.  
> I pulled out as much text as possible and here it is.
>
> How are you specifying the IPL command and any parameters then? I 
> think we need to understand how things are supposed to work for you so 
> that we can better provide assistance.
>
> If you can't get to the console of the guest, then trying to get into 
> single user mode or anything like that isn't going to help at all. One 
> possibility might be to try and specify "hvc_iucv=8 console=hvc0 
> init=/bin/bash" on the command line, and use the terminal server tools 
> from another guest to get access.
>
>
> 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


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

--
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: Quick question on single user mode

[Marcy Cortes]

Do you have current maintenance on LVM and the kernel?   We went through some 
of this shortly after SP4 went in.   We have since received fixes. 

The way we got out of it was pulling out the media and using the rescue system. 
  Have you done that before?


-Original Message-
From: Linux on 390 Port  On Behalf Of Will, Chris
Sent: Tuesday, March 10, 2020 4:02 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Quick question on single user mode

Thanks we are having issues booting a guest and all we see are messages about 
rdsosreport.txt message.  I was hoping that single user mode would bypass the 
enter root password prompt but it does not.  Our root password vault product 
must have not synced properly since I cannot get into the shell to see what the 
issue is.  All started when expanding a SLES 12 SP4 XFS file system that 
contained the /var file system.

Get Outlook for iOS

From: Linux on 390 Port  on behalf of Edgington, Jerry 

Sent: Monday, March 9, 2020 12:38:29 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Quick question on single user mode

[External email]


If you are running under z/VM, then you can shut down the server, mount the 
root mini-disk to another Linux server, correct the configuration issue and 
restart the server.

-Original Message-
From: Linux on 390 Port  On Behalf Of Will, Chris
Sent: Monday, March 9, 2020 12:29 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Quick question on single user mode

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


Have a broken sles 12 server.  I believe at one point there was an option on 
the "ipl 100" to go into single user mode.  Any help?

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


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

--
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: configuring a new disk comes up ro ?

[Marcy Cortes]

What OS is this?   
dasd_configure is replaced by chzdev 

anything in /var/log/messages?  or journal?

We've seen linux not be happy with things that might have been leftover on a 
reused disk.
I'd run cpfmtxa over the entire volume just to be sure nothing like that is 
happening.



-Original Message-
From: Linux on 390 Port  On Behalf Of Fred Bader
Sent: Wednesday, January 29, 2020 12:41 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] configuring a new disk comes up ro ?


I agree the MDISK is R/W to the Linux guest, so it is something happening
in Linux when the device is brought online.  Can you check your UDEV rules
and see if there is one that would be associated with this device that
includes-- ATTR{readonly}="1" ?

Regards, Fred
_

   Fred Bader, Washington Systems Ctr (WSC) IBM Z Applied Technologies
   IBM Corp, 470 Springpark Pl, Suite 950/1000, Herndon, VA 20170-5253
   E-mail: fba...@us.ibm.com, Phone: 720-395-, Tieline: 676-

   IBM Z - "The cloud you want with the privacy and security you need"
 http://www.ibm.com/systems/z/ - http://www.ibm.com/z15





From:   "Vandale, Mark D" 
To: LINUX-390@VM.MARIST.EDU
Date:   01/29/2020 10:38 AM
Subject:[EXTERNAL] Re: configuring a new disk comes up ro ?
Sent by:Linux on 390 Port 



Just like all the other mdisks...  I'm pretty sure the problem is in Linux
somewhere

vmcp q v 12c
DASD 012C 3390 P00380 R/W  32759 CYL ON DASD  5A14 SUBCHANNEL = 0033

vmcp q v 12b
DASD 012B 3390 P00387 R/W  32759 CYL ON DASD  5A1B SUBCHANNEL = 0032



Mark Vandale
Sr. System Engineer Lead

T +1. 860.705.1657
M +1.860.705.1657
Txt 8607051...@txt.att.net


100 Winnenden Road
Norwich, CT 06360


dxc.technology / Twitter / Facebook / LinkedIn


-Original Message-
From: Linux on 390 Port  On Behalf Of Fred Bader
Sent: Wednesday, January 29, 2020 10:28 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: configuring a new disk comes up ro ?


How is MDISK 012C defined in that Linux guest's directory entry?  Can you
please include the output from "vmcp q v 12c"?

Thanks, Fred
_

   Fred Bader, Washington Systems Ctr (WSC) IBM Z Applied Technologies
   IBM Corp, 470 Springpark Pl, Suite 950/1000, Herndon, VA 20170-5253
   E-mail: fba...@us.ibm.com, Phone: 720-395-, Tieline: 676-

   IBM Z - "The cloud you want with the privacy and security you need"
 http://www.ibm.com/systems/z/ - http://www.ibm.com/z15





From:"Vandale, Mark D" 
To:  LINUX-390@VM.MARIST.EDU
Date:01/29/2020 10:19 AM
Subject: [EXTERNAL] configuring a new disk comes up ro ?
Sent by: Linux on 390 Port 



When I configure device address 12c online it comes up ro.  Why is this
occurring and how do I fix it ?  I've deleted and recreated disk 12c
several times.

dasd_configure 0.0.012c 1
lsdasd
Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==


0.0.012a   n/f dasdam94:152   ECKD
0.0.012b   n/f dasdan94:156   ECKD
0.0.012c   active(ro)  dasdao94:160   ECKD  4096   23033MB   5896620

vmcp q sys 12c
HCPQSY1008E Device 12C is not a DASD
Error: non-zero CP response for command 'Q SYS 12C': #1008


Mark Vandale
Sr. System Engineer Lead
T +1. 860.705.1657
M +1.860.705.1657
Txt 8607051...@txt.att.net

[Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: cid:image001.png@01D2A23D.5BCFB750]
100 Winnenden Road
Norwich, CT 06360


dxc.technology<
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dxc.technology_=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=NDb6JAokvZ4j4NXrlZCqVR9n7G77aj-G5tSt1q3XgAM=zsvq0IyOe7iXH-QvLuT4TKQzS4WrykDkM9XIKq93P94=eFKEm3PPecaG69CsWFYAEtm5PG0_IPI-ti_Q6PVmzBM=

 > / Twitter<
https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_dxctechnology=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=NDb6JAokvZ4j4NXrlZCqVR9n7G77aj-G5tSt1q3XgAM=zsvq0IyOe7iXH-QvLuT4TKQzS4WrykDkM9XIKq93P94=d47ZZM-vauOsWyBqzou_Ja5_rtaLU7LY6vULfUDqnFg=

 > / Facebook<
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_DXCTechnology_=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=NDb6JAokvZ4j4NXrlZCqVR9n7G77aj-G5tSt1q3XgAM=zsvq0IyOe7iXH-QvLuT4TKQzS4WrykDkM9XIKq93P94=pO3iXFFMQwdi1KYGsc6a7QpDOwfekM0zhyVXpZD6D1Q=

 > / LinkedIn<

Re: Dynamically turning on memory

[Marcy Cortes]

You're welcome!
All the z specific commands are in the Device Drivers books 
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaaf/lnz_r_dd.html

There's a chapter on Managing hotplug memory 



-Original Message-
From: Linux on 390 Port  On Behalf Of Martha McConaghy
Sent: Thursday, January 23, 2020 8:32 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Dynamically turning on memory

Oh, Doh!  That is just what I need.  Thanks so much, Marcy.  Guess my googling 
skills are on the fritz today.  Nothing I found mentioned either of those 
commands.

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Vice President

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Marcy Cortes 

Sent: Thursday, January 23, 2020 11:02 AM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Dynamically turning on memory

I've never done it in an LPAR, but it should be the same.

Use chmem-e 256G

Use lsmem to check


Sent with BlackBerry Work
(www.blackberry.com<http://www.blackberry.com>)


From: Martha McConaghy 
mailto:martha.mccona...@marist.edu>>
Date: Thursday, Jan 23, 2020, 7:57 AM
To: LINUX-390@VM.MARIST.EDU 
mailto:LINUX-390@VM.MARIST.EDU>>
Subject: [LINUX-390] Dynamically turning on memory

I have a feeling that this is a "dumb user" question, but googling around has 
not provided an answer that fits our environment.  Since I'm messing with a 
production system, I don't want to screw around and do something wrong.

I have an LPAR on a z15 that is running Ubuntu 18.04 native.  It has 768G of 
memory with 256G in reserve.  I need to turn on some of that 256G and have the 
Ubuntu system use it.  Under z/VM, its one command and you are done..   In 
this environment, I have no idea how to:

  1.  Get some of the 256G released from reserve
  2.  Get Ubuntu to use it

I'm sure that this is something that many of you have done before, so, please, 
help. Point me to a doc or something that describes the process.  The system is 
running KVM and openstack, and there are nearly 100 servers running on it.  So, 
I can't afford to reboot to turn on the memory.

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Vice President

Marist College IT

Poughkeepsie, NY 12601

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

--
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: Dynamically turning on memory

[Marcy Cortes]

I’ve never done it in an LPAR, but it should be the same.

Use chmem-e 256G

Use lsmem to check


Sent with BlackBerry Work
(www.blackberry.com)


From: Martha McConaghy 
mailto:martha.mccona...@marist.edu>>
Date: Thursday, Jan 23, 2020, 7:57 AM
To: LINUX-390@VM.MARIST.EDU 
mailto:LINUX-390@VM.MARIST.EDU>>
Subject: [LINUX-390] Dynamically turning on memory

I have a feeling that this is a "dumb user" question, but googling around has 
not provided an answer that fits our environment.  Since I'm messing with a 
production system, I don't want to screw around and do something wrong.

I have an LPAR on a z15 that is running Ubuntu 18.04 native.  It has 768G of 
memory with 256G in reserve.  I need to turn on some of that 256G and have the 
Ubuntu system use it.  Under z/VM, its one command and you are done..   In 
this environment, I have no idea how to:

  1.  Get some of the 256G released from reserve
  2.  Get Ubuntu to use it

I'm sure that this is something that many of you have done before, so, please, 
help. Point me to a doc or something that describes the process.  The system is 
running KVM and openstack, and there are nearly 100 servers running on it.  So, 
I can't afford to reboot to turn on the memory.

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Vice President

Marist College IT

Poughkeepsie, NY 12601

--
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: Pervasive disk encryption questions

[Marcy Cortes]

This brings up another set of questions from me :)

Under the assumption that hardware eventually fails and I could lose a card... 

If there's two on a guest I assume things seamlessly continue on if one card 
fails?  Do I get messages on Linux, VM, or the HW if that should happen? 

If there's only one and that card fails, does the file system get unmounted 
and/or throw errors?  Or does it continue on and just have issues at next 
reboot? 

Is there any way to test card failure? 

Yes, we have plenty of HA in many forms (tsamp, db2 hadr, external load 
balancers, multiple cecs, multiple servers, multiple data centers, gpfs, etc) 
and they are complex with different recovery times and data loss as you 
mention.   

I'm still in exploration phase so I can't answer the how many are needed.  I'm 
trying to tell mgmt. what we can do with what we have, what it will mean to 
grow it, and what value it provides.   I'm afraid that there is some belief 
that we can "just do all of it".   And what real value is there when the only 
group this buys protection from is our z storage admins (we already have hw 
level to protect devices that leave the datacenter).Slick marketing 
presentations abound  :) 

From page 6 of this redpiece here 
http://www.redbooks.ibm.com/redpapers/pdfs/redp5464.pdf
"IBM Z makes it possible, for the first time, for organizations to pervasively 
encrypt data associated with an entire application, cloud service, or database 
in flight or at rest with one click. "

Still looking for that one click button!
Marcy

-Original Message-
From: Linux on 390 Port  On Behalf Of Reinhard Buendgen
Sent: Tuesday, January 21, 2020 12:55 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Pervasive disk encryption questions

Tim,

I fully agree. Yet the Z platform is designed for RAS where 
the"R"eliabiity translates to redundancy of the available resources 
either within the system for built-in resources or as an configuration 
option for external resources. The number 680 just reflects the 
recommendation to achieve crypto redundancy per configuration (once 
configured properly the Linux kernel will do the rest).

Whether that form of redundancy is the best form in an specific customer 
environment is up to the customer.

As for the level of redundancy (device redundancy, HA cluster, or DR 
cluster), it is  the customers choice to decide the kind of penalty (ms, 
secs , mins) he or she is willing to accept in case of a the failure of 
a single resource. Also note that for certain workloads (workloads 
managing a shared state,  e.g. R/W data bases), HA clusters may be 
pretty complex and impact performance.

-Reinhard

On 21.01.20 08:59, Timothy Sipples wrote:
> I'd like to comment on the 680 number for a moment. I don't think 680 is
> the correct number of Linux guests that can use protected key
> dm-crypt/LUKS2 encrypted volumes. I'd like to argue the case for why the
> current maximum number is 1,360 guests per machine that can use this
> particular feature. (It's a security feature that doesn't exist on any
> other platform, we should note, so it's either 680 or 1,360 more Linux
> guests than any other machine.)
>
> The number 680 is derived by taking the current maximum number of physical
> Crypto Express features per machine (16), configuring them all in CCA mode,
> multiplying by the current maximum number of domains per feature (85)(*),
> then dividing in half, with the idea being that each Linux guest would
> benefit from the services of two CCA domains spread across two physical
> Crypto Express features.
>
> I think this last assumption is fairly arbitrary. A single Linux guest is
> one kernel running within only one instance of the hypervisor (which may or
> may not be nested). It's a singleton, inherently. In a production
> environment you'd presumably have something more than singleton Linux
> guests running particular workloads, at least if they're important
> workloads. You pick up redundancy there. If a particular Linux guest is
> offline for whatever reason, there's another handling the workload (or
> ready to handle it), with its own Crypto Express domain.
>
> You certainly could decide to add Crypto Express redundancy on a per guest
> basis in addition to whole Linux guest redundancy, but if you're going to
> measure the outer bound maximum number I don't think you ought to assume
> "redundancy squared." It seems rather arbitrary to me that that's where you
> draw that particular line.
>
> There is no intrinsic limit to the number of Linux guests using
> dm-crypt/LUKS2 encrypted volumes with clear keys.
>
> You can also decide on a guest-by-guest basis whether to double up on
> Crypto Express CCA domains or not, which would mean a current upper bound
> limit somewhere between 680 and 1,360 Linux guests using CCA domains.
> And/or you can decide how many Crypto Express features you want to
> configure in another mode, notably EP11. If for example you configure two
> 

Re: Pervasive disk encryption questions

[Marcy Cortes]

I was talking about the CCA rpm package needed on Linux


Sent with BlackBerry Work
(www.blackberry.com)


From: Alan Altmark mailto:alan_altm...@us.ibm.com>>
Date: Saturday, Jan 18, 2020, 2:01 AM
To: LINUX-390@VM.MARIST.EDU 
mailto:LINUX-390@VM.MARIST.EDU>>
Subject: Re: [LINUX-390] Pervasive disk encryption questions


To be clear, a CCA is a crypto in Coprocessor mode. It is the only mode
that allows Linux or z/OS to load master keys without TKE, so keeping it
out of the picture isn’t going to work if you want to use ICSF to load
keys.

A (crypto, domain) pair can be online to only one LPAR at a time, but in
any case you cannot relocate a guest with APDED domains.

Regards,
Alan Altmark
IBM

> On Jan 17, 2020, at 8:00 PM, Marcy Cortes 
wrote:
>
> 
> One more question I have and its probably more VM orientated.
>
> Say we decide z/OS ICSF loads all the master keys for us (keeping CCA out
of the pic) .  Can a guest on VM1 use the same card/domain as a guest on
VM2 in another lpar provided they user the same MK?  Trying to figure out
HW requirements for fitting this into a GDPS 4 site where a guest can be
instantiated in lots of places (8 different lpars currently).
>
> And those in the same cluster I'd still like to be able to LGR them.
>
> PS.  Has IBM considered that maybe this data at rest encryption is better
handled at the VM layer?Current HW basically limits you to 760 guests
using it on z15 if you give 2 devices to each guest for redundancy, right?
(85 * 16 = 1360 / 2 ).
>
> Marcy
>
>
>
> --
> 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=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=YJ0apmefTqTIb9A_tsjLg_jZLBDQ7z30plCLJhj2AdA=jgDJvvKIlIt8nomhJ9ERSkPwWQVqjmaoeffEhIhwMSM=

>

--
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: Pervasive disk encryption questions

[Marcy Cortes]

680 guests I mean - can't type!


-Original Message-
From: Linux on 390 Port  On Behalf Of Marcy Cortes
Sent: Friday, January 17, 2020 5:00 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Pervasive disk encryption questions


One more question I have and its probably more VM orientated. 

Say we decide z/OS ICSF loads all the master keys for us (keeping CCA out of 
the pic) .  Can a guest on VM1 use the same card/domain as a guest on VM2 in 
another lpar provided they user the same MK?  Trying to figure out HW 
requirements for fitting this into a GDPS 4 site where a guest can be 
instantiated in lots of places (8 different lpars currently).  

And those in the same cluster I'd still like to be able to LGR them.

PS.  Has IBM considered that maybe this data at rest encryption is better 
handled at the VM layer?Current HW basically limits you to 760 guests using 
it on z15 if you give 2 devices to each guest for redundancy, right?  (85 * 16 
= 1360 / 2 ).   

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

--
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: Pervasive disk encryption questions

[Marcy Cortes]

One more question I have and its probably more VM orientated. 

Say we decide z/OS ICSF loads all the master keys for us (keeping CCA out of 
the pic) .  Can a guest on VM1 use the same card/domain as a guest on VM2 in 
another lpar provided they user the same MK?  Trying to figure out HW 
requirements for fitting this into a GDPS 4 site where a guest can be 
instantiated in lots of places (8 different lpars currently).  

And those in the same cluster I'd still like to be able to LGR them.

PS.  Has IBM considered that maybe this data at rest encryption is better 
handled at the VM layer?Current HW basically limits you to 760 guests using 
it on z15 if you give 2 devices to each guest for redundancy, right?  (85 * 16 
= 1360 / 2 ).   

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

Re: Interesting presentation

[Marcy Cortes]

Good stuff.  Except the security redbook from 2013.   that's ancient :)


-Original Message-
From: Linux on 390 Port  On Behalf Of Neale Ferguson
Sent: Thursday, January 16, 2020 4:52 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Interesting presentation

From LinuxConf AU by Elizabeth Joseph of IBM: 
https://princessleia.com/presentations/2020/Linux_in_the_cloud_on_prem_or_on_a_mainframe_-_january_15_2020.pdf


Neale Ferguson


--
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: Pervasive disk encryption questions

[Marcy Cortes]

Hi Ingo.   Looking at this page... If its 85, why 00-5d in hex?   Isn't 5d = 93 
?

Marcy

On 1/13/20, 8:52 AM, "Linux on 390 Port on behalf of Ingo Adlung" 
 wrote:

Hey Marcy,
I'm not the crypto expert (Reinhard please jump in) but aren't we talking
about crypto domain dedication? I.e. not dedicating complete cards ...
don't know about z14/z15 but with z13 we supported up to 85 domains per
LPAR per single adapter like described here:


https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_c_crypto_virtual.html

Best regards
Ingo

Linux on 390 Port  wrote on 13/01/2020 17:34:43:

    > From: Marcy Cortes 
> To: LINUX-390@VM.MARIST.EDU
> Date: 13/01/2020 17:35
> Subject: [EXTERNAL] Re: [LINUX-390] Pervasive disk encryption questions
> Sent by: Linux on 390 Port 
>
> Thanks!  Was hoping you'd respond.
>
> So essentially to do the disk encryption stuff documented here
> https://www.ibm.com/support/knowledgecenter/en/linuxonibm/
> com.ibm.linux.z.lxdc/lxdc_linuxonz.html
> one has to dedicate to the guest.
>
> If I can put 16 cards on a z15, I'm essentially limited to 8 guests
> per LPAR with the ability to do this.
> (need redundancy so two per guest).Correct ?There's not a
> way to dedicate, put master key on, then make it apvirt after that,
correct?
>
> Marcy
>
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of
> Reinhard Buendgen
> Sent: Monday, January 13, 2020 7:19 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: [LINUX-390] Pervasive disk encryption questions
>
> Hi,
>
> crypto adapter domains defined for z/VM guests with APVIRT are
> restricted to perform clear key crypto operations (possibly including
> random number generations). Regard less whether the backing adapters are
> in accelerator mode or in CCA mode (AP-virt does not support adapters in
> EP11 mode).
> And if there are multiple backing adapters of different modes z/VM gives
> priority to accelerator mode when choosing the type of the shared
> virtual adapter.
>
> When you want to use secure key crypto you must define your crypto
> adapter domain in the guest as dedicated adapter (APDED for z/VM guests,
> for KVM guests currently only dedicated adapter domains are supported).
> Dedicated adapter domains can be of any type: accelerator, CCA or EP11.
> Only the CCA and EP11 types provide support for clear key crypto.
>
> To set/manage the master key of a dedicated CCA adapter domain assigned
> to a guest there are multiple options
> — connect the TKE to the catcher.exe daemon (part of the CCA host
> package)  running on the Linux system and use the TKE to mange the
> master key of the adapter domain belonging to the Linux guest (option
> recommended for production use)
> — use the panel.exe tool (part of the CCA host package) on the Linux
> guest to set/manage the master key of the adapter domain belonging to
> the Linux guest (this option is not recommended for production use, due
> to some security limitations -- I like this option )
> — use a z/OS System on the same CEC (or other Linux System) that has an
> appropriate control domain setting. Using the z/OS system can go via
> ICSF functions (which I guess are similar in function and security to
> what the panel.exe tool provides) or a TKE connected to the z/OS system.
> — use another Linux system on the same CEC that has an appropriate
> control domain setting and do the management either vie panel.exe or TKE
> (again TKE being recommended for production use).
> There is no need for a special system to set master keys. Each system
> can manage its own master keys. But if you choose to do so, say because
> you want to use ICSF or panel.exe from a particularly secured system
> then all you need is a system that has an arbitrary usage domain and
> control domains configured to the domains you want to manage.
> Unfortunately control domains cannot be freely configured for z/VM
> guests. (z/VM sets the control domain to be equal to the usage domain).
> So this option works only for LPARs and KVM guests. For z/VM guests you
> may have to switch the adapter domains form the key mangement guest to
> the actual working guests.
>
>
> Reinhard
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with t

Re: Pervasive disk encryption questions

[Marcy Cortes]

Thanks!  Was hoping you'd respond.  

So essentially to do the disk encryption stuff documented here 
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lxdc/lxdc_linuxonz.html
one has to dedicate to the guest.

If I can put 16 cards on a z15, I'm essentially limited to 8 guests per LPAR 
with the ability to do this.
(need redundancy so two per guest).Correct ?There's not a way to 
dedicate, put master key on, then make it apvirt after that, correct?

Marcy


-Original Message-
From: Linux on 390 Port  On Behalf Of Reinhard Buendgen
Sent: Monday, January 13, 2020 7:19 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Pervasive disk encryption questions

Hi,

crypto adapter domains defined for z/VM guests with APVIRT are 
restricted to perform clear key crypto operations (possibly including 
random number generations). Regard less whether the backing adapters are 
in accelerator mode or in CCA mode (AP-virt does not support adapters in 
EP11 mode).
And if there are multiple backing adapters of different modes z/VM gives 
priority to accelerator mode when choosing the type of the shared 
virtual adapter.

When you want to use secure key crypto you must define your crypto 
adapter domain in the guest as dedicated adapter (APDED for z/VM guests, 
for KVM guests currently only dedicated adapter domains are supported).
Dedicated adapter domains can be of any type: accelerator, CCA or EP11. 
Only the CCA and EP11 types provide support for clear key crypto.

To set/manage the master key of a dedicated CCA adapter domain assigned 
to a guest there are multiple options
— connect the TKE to the catcher.exe daemon (part of the CCA host 
package)  running on the Linux system and use the TKE to mange the 
master key of the adapter domain belonging to the Linux guest (option 
recommended for production use)
— use the panel.exe tool (part of the CCA host package) on the Linux 
guest to set/manage the master key of the adapter domain belonging to 
the Linux guest (this option is not recommended for production use, due 
to some security limitations -- I like this option )
— use a z/OS System on the same CEC (or other Linux System) that has an 
appropriate control domain setting. Using the z/OS system can go via 
ICSF functions (which I guess are similar in function and security to 
what the panel.exe tool provides) or a TKE connected to the z/OS system.
— use another Linux system on the same CEC that has an appropriate 
control domain setting and do the management either vie panel.exe or TKE 
(again TKE being recommended for production use).
There is no need for a special system to set master keys. Each system 
can manage its own master keys. But if you choose to do so, say because 
you want to use ICSF or panel.exe from a particularly secured system 
then all you need is a system that has an arbitrary usage domain and 
control domains configured to the domains you want to manage. 
Unfortunately control domains cannot be freely configured for z/VM 
guests. (z/VM sets the control domain to be equal to the usage domain). 
So this option works only for LPARs and KVM guests. For z/VM guests you 
may have to switch the adapter domains form the key mangement guest to 
the actual working guests.


Reinhard

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

Pervasive disk encryption questions

[marcy cortes]

Cross posted to Linux-390 and IBMVM


First, my understand of virtualizing crypto is that if any of the cards are
defined as accelerators then CRYPTO APVIRT in the directory will give linux
an accelerator.   If you want linux to have a coprocessor, you’d have to
dedicate one.If you want a lot of servers to have coprocessors (more
than the HW cards to dedicate), you’d get rid of the accelerators and make
them all coprocessors.  Is my understanding correct?

 And to do the AES master key load, it has generally been done from z/OS
here.   It looks like for my z/vm only boxes TKE is required, but I could
use the CCA package to generate some for a test only scenario.

If I do want to try that CCA key load on a non prod box, I’m thinking I
would have to dedicate all of the coprocessors to a Linux guest and create
them there.  Then undedicate and then any guest with an APVIRT would find
valid master keys and would then be able to “zkey generate” a secure key
for use in each disk.

Am I on the right track?

Marcy

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

Re: OpenShift 4.2 for Linux on Z now available as a tech preview.

[Marcy Cortes]

Is it true that it will be z15 only?


-Original Message-
From: Linux on 390 Port  On Behalf Of Michel Beaulieu
Sent: Wednesday, November 27, 2019 6:11 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] OpenShift 4.2 for Linux on Z now available as a tech 
preview.

OpenShift 4.2 for Linux on Z now available as a tech preview.

the link:
https://try.openshift.com/


Michel Beaulieu
IBM Services (Canada)

--
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: backup product

[Marcy Cortes]

According to the Veritas website, Netbackup on SLES 15 system Z is supported if 
8.2 client.

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

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

[Marcy Cortes]

Just went through all this a while ago!

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

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

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



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

Hello,

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

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

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

FYI, the last error messages:
devtmpfs: error mounting -2
Freeing unused kernel memory: 396k freed
Kernel panic - not syncing: No init found.  Try passing init= option to
kernel.
See Linux Documentation/init.txt for guidance.
CPU: 0 Not tainted 3.0.101-108.87.1.tux4vm-default #1
Process swapper (pid: 1, task: 07d82038, ksp: 07d87700)
 07d87d68 0002 
   07d87e08 07d87d80 07d87d80 0062a032
   0011   
   000d  07d87dd0 000e
   0063a978 00100ac4 07d87d68 07d87db0
Call Trace:
([<001009ca>] show_trace+0xe6/0x138)
 [<00629d80>] panic+0xcc/0x288
 [<00100300>] init_post+0x104/0x16c
 [<0096b34c>] kernel_init+0x1fc/0x248
 [<0062dfde>] kernel_thread_starter+0x6/0xc
 [<0062dfd8>] kernel_thread_starter+0x0/0xc
HCPGIR450W CP entered; disabled wait PSW 00020001 8000 
001130E4



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

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

--
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: Defined minidisks RHEL 6.0 on z/VM to grow / FS, forgot to Persistently Setting DASDs Online with /etc/zipl.conf and zipl.

[Marcy Cortes]

Alan wrote:
>I've been thinking for some time that we might want to consider revisiting 
>that for the VINPUT command.  It's a command specifically designed to 
>deliver data to a guest, not CP and not someone else's console.  As such, 
>it should be left to the guest to do the translation if it wants to.

That sounds like a great idea.   RFE anyone?  Or add to the z/VM council site?

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

Re: Issues trying to install RHEL 8

[Marcy Cortes]

I should also add that once you are in the dreaded dracut shell, put it on your 
USB stick!

Haha.  Just kidding.  Use cat and capture it to your console


Sent with BlackBerry Work
(www.blackberry.com)

From: Cohen, Sam mailto:sam.co...@lrs.com>>
Date: Tuesday, Jul 30, 2019, 10:49 PM
To: LINUX-390@VM.MARIST.EDU 
mailto:LINUX-390@VM.MARIST.EDU>>
Subject: Re: [LINUX-390] Issues trying to install RHEL 8

Martha,

It's been a while, but i may have seen this and was stumped.  I think i bumped 
up the virtual machine to 4G and got passed it.

Sam

Sam Cohen
(217) 862-9227


From: Linux on 390 Port  on behalf of Martha McConaghy 

Sent: Tuesday, July 30, 2019 9:52:04 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Issues trying to install RHEL 8

Has anyone run into problems getting RHEL 8 to install on Z? I've run
into a weird problem.  Two different experienced Linux guys have looked
at it, and we are all stumped.

Background:

The install is being done in a 3G virtual machine on z/VM 6.4 on a
LinuxOne (z13 generation).  We have lots of different versions of Linux
running on the same system, including RHEL 7, CentOS, Ubuntu 18 and SLES
15.  So, I don't think its a kernel/cpu type problem.

Problem:

When I run the REDHAT exec to bring up the install kernel, it starts
booting and things look like they will be OK.  Until it gets to the
point where "dracut initqueue" starts.  There is a message "7 urandom
warnings(s) missed due to ratelimiting".  It then pauses for a couple of
minutes, followed by a series of messages, "dracut-initqueue timeout -
starting timeout scripts". Eventually, it ends up in dracut in emergency
mode.  The install process never starts.  I've changed numerous
parameters, even changed what type of disk I'm using for the install.
It doesn't matter, its exactly the same problem each time.

Really scratching my head on this one.

Martha

Ý"Ý0;32m  OK  "Ý0m+ Reached target Local File Systems.""
  Starting Create Volatile Files and Directories...""
  Starting Open-iSCSI...""
Ý"Ý0;32m  OK  "Ý0m+ Started Open-iSCSI.""
Ý"Ý0;32m  OK  "Ý0m+ Started Create Volatile Files and Directories.""
Ý"Ý0;32m  OK  "Ý0m+ Reached target System Initialization.""
Ý"Ý0;32m  OK  "Ý0m+ Reached target Basic System.""
  Starting dracut initqueue hook...""
Ý6.306800+ dracut-initqueueÝ929+: RTNETLINK answers: File exists""
Ý   84.168981+ random: crng init done
Ý   84.168992+ random: 7 urandom warning(s) missed due to ratelimiting
Ý  142.340863+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""
Ý  142.931884+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""
Ý  143.490965+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""
Ý  144.080845+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""

  209.140407+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout -
starting timeout scripts""
Ý  209.700768+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""
Ý  210.270398+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""
Ý  210.270531+ dracut-initqueueÝ929+: Warning: Could not boot.""
  Starting Setup Virtual Console...""
Ý"Ý0;32m  OK  "Ý0m+ Started Setup Virtual Console.""
  Starting Dracut Emergency Shell...""
Warning: /dev/root does not exist

Generating "/run/initramfs/rdsosreport.txt"

--
Martha McConaghy
Marist: System Architect/Technical Lead
SHARE Association: Vice President
Marist College IT
Poughkeepsie, NY 12601

--
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%7Cd1be4eee62ae4fdb954608d7156269e8%7C62af9ccc42164ae2a1d306614c59c315%7C0%7C0%7C637001384749448763sdata=x38wr4pyDSisBJ03LsaArE848qIi5q%2FGF1kh4OdXGu0%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

--
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: Issues trying to install RHEL 8

[Marcy Cortes]

Is there LVM in that disk selection?


Sent with BlackBerry Work
(www.blackberry.com)

From: Martha McConaghy 
mailto:martha.mccona...@marist.edu>>
Date: Tuesday, Jul 30, 2019, 7:52 PM
To: LINUX-390@VM.MARIST.EDU 
mailto:LINUX-390@VM.MARIST.EDU>>
Subject: [LINUX-390] Issues trying to install RHEL 8

Has anyone run into problems getting RHEL 8 to install on Z? I've run
into a weird problem.  Two different experienced Linux guys have looked
at it, and we are all stumped.

Background:

The install is being done in a 3G virtual machine on z/VM 6.4 on a
LinuxOne (z13 generation).  We have lots of different versions of Linux
running on the same system, including RHEL 7, CentOS, Ubuntu 18 and SLES
15.  So, I don't think its a kernel/cpu type problem.

Problem:

When I run the REDHAT exec to bring up the install kernel, it starts
booting and things look like they will be OK.  Until it gets to the
point where "dracut initqueue" starts.  There is a message "7 urandom
warnings(s) missed due to ratelimiting".  It then pauses for a couple of
minutes, followed by a series of messages, "dracut-initqueue timeout -
starting timeout scripts". Eventually, it ends up in dracut in emergency
mode.  The install process never starts.  I've changed numerous
parameters, even changed what type of disk I'm using for the install.
It doesn't matter, its exactly the same problem each time.

Really scratching my head on this one.

Martha

Ý"Ý0;32m  OK  "Ý0m+ Reached target Local File Systems.""
  Starting Create Volatile Files and Directories...""
  Starting Open-iSCSI...""
Ý"Ý0;32m  OK  "Ý0m+ Started Open-iSCSI.""
Ý"Ý0;32m  OK  "Ý0m+ Started Create Volatile Files and Directories.""
Ý"Ý0;32m  OK  "Ý0m+ Reached target System Initialization.""
Ý"Ý0;32m  OK  "Ý0m+ Reached target Basic System.""
  Starting dracut initqueue hook...""
Ý6.306800+ dracut-initqueueÝ929+: RTNETLINK answers: File exists""
Ý   84.168981+ random: crng init done
Ý   84.168992+ random: 7 urandom warning(s) missed due to ratelimiting
Ý  142.340863+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""
Ý  142.931884+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""
Ý  143.490965+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""
Ý  144.080845+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""

  209.140407+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout -
starting timeout scripts""
Ý  209.700768+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""
Ý  210.270398+ dracut-initqueueÝ929+: Warning: dracut-initqueue timeout
- starting timeout scripts""
Ý  210.270531+ dracut-initqueueÝ929+: Warning: Could not boot.""
  Starting Setup Virtual Console...""
Ý"Ý0;32m  OK  "Ý0m+ Started Setup Virtual Console.""
  Starting Dracut Emergency Shell...""
Warning: /dev/root does not exist

Generating "/run/initramfs/rdsosreport.txt"

--
Martha McConaghy
Marist: System Architect/Technical Lead
SHARE Association: Vice President
Marist College IT
Poughkeepsie, NY 12601

--
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: Dracut fix is available now from SUSE for problem with SP4 dasd disks

[Marcy Cortes]

Well, some significant progress!   I think there are two problems.  This dracut 
fix is definitely needed because udev rules are named differently once you 
start adding disk under SP4.

But I still had the problem last night on a dozen servers that hadn't received 
any new disks.
The /run/initramfs/rdsosreport.txt showed me that the disks were indeed visible 
but LVM didn't find 3 of 6 of them.

It seems to be related to LVM. 

I discovered in Dracut emergency shell that it forces you into, I could simply 
run 3 things
rm /etc/lvm/lvm.conf
lvm vgscan
#cp ipl 101 clear 

And server happily proceeds on its merry way to boot grub and the rest of linux.

Yes, the lvm.conf on disk is still the same and was not removed, but apparently 
the vgscan makes LVM happy again.   

Whatever this is about will probably come back..  Unless...

Coincidentally, we have another ticket open with SUSE about LVM in SP4.  The 
vgextend command wouldn't take /dev/disk/by-path/ccw-0.0.-part1 names.
They said that was a filtering problem and so produced a PTF that doesn't take 
them for the other vg* commands as well (not the direction I wanted).Well, 
I took and applied that to five that looked just like these twelve that hadn't 
been patched yet and voila!  No dracut timeout problem!





-Original Message-
From: Linux on 390 Port  On Behalf Of Juha Vuori
Sent: Friday, July 26, 2019 2:48 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Dracut fix is available now from SUSE for problem with 
SP4 dasd disks

Not here, sorry.

We've had the incident only on one south pole bird, whose life cycle is 
characterized by:
- / on ckd mdisk, /opt /var /home on LVs of a VG (ckd PVs)
- migration from sles11sp4 to sles12sp4; boots correctly at this stage
- another PV added to the VG
- /usr migrated to a new LV (due to space shortage in /)
-> next boot hangs in the beginning, dracut warning about "/dev/system/usr does 
not exist"

Udev rule for the new ckd was named "51-dasd-0.0.0206.rules".
Still, SUSE workaroud fix was to edit parm of inst_rules_wildcard in 
module-setup.sh:
41-s390x-dasd-*.rules -> 41-dasd-*.rules.
And that corrected the problem.
Now we've applied the public patch on top, and everything is still fine.

Honestly, I don't understand how the workaround could fix the problem, and I 
have no idea if the
public patch really now prevents it.
And I am not sure which preconditions caused the problem to pop up in the first 
place, but probably
some of the above..
For us that's not too relevant because all out other servers have their system 
disk space on EDEV
mdisks so that's why we haven't tried to investigate more..

--
Best regards,
Juha Vuori

On 26.7.2019 21.41, Ted Rodriguez-Bell wrote:
> Has anyone been able to make this problem happen on a system of their choice? 
>  We've seen it pop up in in our dev environment, but neither Marcy nor I has 
> been able to cause the problem when we've tried.  Without that it's hard to 
> have complete confidence that this has the fix for our problem.
>
> 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 
> Sent: Thursday, July 25, 2019 8:58 AM
> Subject: Dracut fix is available now from SUSE for problem with SP4 dasd disks
>
> Bug Fix Advisory - SUSE-12-SP4-2019-1969
>
> --
>
> Summary:
>
> Recommended update for dracut
>
>
>
>This update for dracut fixes the following issues:
>
>
>
> - 95dasd-rules 95zfcp-rules: was not correctly looking for rule names 
> (bsc#1137784)
>
> - Ensure early microcode gets added from files with .early postfix
>
>(bsc#1098915, bsc#1125393)
>
> - Ensure GPIO modules get included on ARM (bsc#1133819)
>
> - Fix Routes are not properly added due to spelling error (bsc#1134347)
>
> - Decouple iscsi from sysinit.target (bsc#1134472)
>
> - dracut-lib.sh:dev_unit_name() guard against $dev beginning with "-" 
> (bsc#1132448)
>
> - 95iscsi: avoid error messages when building initrd, multipath timeouts
>
>(bsc#1130114, bsc#1130107, bsc#1121238)
>
>
> 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 

Dracut fix is available now from SUSE for problem with SP4 dasd disks

[Marcy Cortes]

Bug Fix Advisory - SUSE-12-SP4-2019-1969

--

Summary:

Recommended update for dracut



  This update for dracut fixes the following issues:



- 95dasd-rules 95zfcp-rules: was not correctly looking for rule names 
(bsc#1137784)

- Ensure early microcode gets added from files with .early postfix

  (bsc#1098915, bsc#1125393)

- Ensure GPIO modules get included on ARM (bsc#1133819)

- Fix Routes are not properly added due to spelling error (bsc#1134347)

- Decouple iscsi from sysinit.target (bsc#1134472)

- dracut-lib.sh:dev_unit_name() guard against $dev beginning with "-" 
(bsc#1132448)

- 95iscsi: avoid error messages when building initrd, multipath timeouts

  (bsc#1130114, bsc#1130107, bsc#1121238)


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: Server don't boot after patch

[Marcy Cortes]

Seems to happen if disk were added after the SP4 upgrade and then on subsequent 
boot it can't find it.  I've not been able to recreate though.

Fix is to dracut and has this comment:
* Fri Jun 28 2019 lidong.zh...@suse.com
- 95dasd_rules: find correct udev rules(bsc#1137784)

And yes, it would be specific to s390x since "dasd"

Call them and reference 1137784


-Original Message-
From: Linux on 390 Port  On Behalf Of Juha Vuori
Sent: Sunday, July 14, 2019 5:04 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Server don't boot after patch

Hi,

Thanks for reporting this here, we are probably hit by the same:

... ...

dracut-initqueue[338]: Warning: dracut-initqueue timeout - starting timeout 
scripts

dracut-initqueue[338]: Warning: Could not boot.

  Starting Dracut Emergency Shell...

Warning: /dev/mapper/system-usr does not exist

Warning: /dev/system/usr does not exist

Generating "/run/initramfs/rdsosreport.txt"
... ...


No btrfs, only extN on and off LVM.
This one was sles12sp4 migrated from sles11sp4 a few months ago, but now boot 
(after z/VM 6.4 -> 
7.1) fails for the 1st time.
So I'm not 100% sure yet what's causing what..

Wonderings popping into mind:
- if the bug is specific to s390x
- if the bug is related to specific kernel version, or dracut/grub version
- if the bug is specific to ckd/fba/scsi PVs

I guess the problem report is not available in public from SUSE?

-- 
Best regards,
Juha Vuori

On 14.7.2019 1.08, Marcy Cortes wrote:
> Exactly what happened to us.   I posted here last month when it happenend.
>
> SUSE has given us a temp PTF that we've just started testing
>
> What you need to do to recover is to boot a rescue system and bring on all 
> your devices with chzdev.
> Then run mkinitrd and grub2-install and cross your fingers.
>
> Marcy
>
> On 7/13/19, 6:11 AM, "Linux on 390 Port on behalf of Victor Echavarry" 
>  wrote:
>
>  Hi:
>  
>  Yesterday  after perform an update in one of our test servers (SLES12 
> SP4) and after updating & rebooting, now the server won't boot. This are the 
> messages
>  
>  Booting default (grub2)
>  dracut-initqueue[403]: Warning: dracut-initqueue timeout - starting 
> timeout scri
>  pts
>  dracut-initqueue[403]: Warning: dracut-initqueue timeout - starting 
> timeout scr
>  
>  dracut-initqueue[403]: Warning: dracut-initqueue timeout - starting 
> timeout scri
>  pts
>  dracut-initqueue[403]: Warning: Could not boot.
>   Starting Dracut Emergency Shell...
>  Warning: /dev/mapper/sys-user does not exist
>  Warning: /dev/sys/user 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
>  
>  Please note, this server has the following filesystem layout:
>  
>  
>1.  DASD device (non-LVM) --- (root filesystem)
>  (5) DASD devices for "sys" volume group for the rest of filesystem: 
> /var, /usr etc..
>  
>  We can mount / filesystem on another zLinux system and have access to 
> /boot and  /etc and trying to rebuild grub and is unsussceful.
>  
>  Any help?
>  
>  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
>  
>
> --
> For L

Re: Server don't boot after patch

[Marcy Cortes]

In my case no.  I decided it wasn’t ready given the amount of things in the 
change logs.


Sent with BlackBerry Work
(www.blackberry.com)

From: Martha McConaghy 
mailto:martha.mccona...@marist.edu>>
Date: Saturday, Jul 13, 2019, 8:17 PM
To: LINUX-390@VM.MARIST.EDU 
mailto:LINUX-390@VM.MARIST.EDU>>
Subject: Re: [LINUX-390] Server don't boot after patch

Was this with BTRFS or another filesystem?  We have had huge problems
with BTRFS and now have had to convert all of our SLES 12 servers to
ext4 to avoid it.  The problems all hit when we moved to SP4 from
earlier levels of SLES 12.  One by one, even the stable servers failed.

Martha

On 7/13/2019 6:08 PM, Marcy Cortes wrote:
> Exactly what happened to us.   I posted here last month when it happenend.
>
> SUSE has given us a temp PTF that we've just started testing
>
> What you need to do to recover is to boot a rescue system and bring on all 
> your devices with chzdev.
> Then run mkinitrd and grub2-install and cross your fingers.
>
> Marcy
>
> On 7/13/19, 6:11 AM, "Linux on 390 Port on behalf of Victor Echavarry" 
>  wrote:
>
>  Hi:
>
>  Yesterday  after perform an update in one of our test servers (SLES12 
> SP4) and after updating & rebooting, now the server won't boot. This are the 
> messages
>
>  Booting default (grub2)
>  dracut-initqueue[403]: Warning: dracut-initqueue timeout - starting 
> timeout scri
>  pts
>  dracut-initqueue[403]: Warning: dracut-initqueue timeout - starting 
> timeout scr
>
>  dracut-initqueue[403]: Warning: dracut-initqueue timeout - starting 
> timeout scri
>  pts
>  dracut-initqueue[403]: Warning: Could not boot.
>   Starting Dracut Emergency Shell...
>  Warning: /dev/mapper/sys-user does not exist
>  Warning: /dev/sys/user 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
>
>  Please note, this server has the following filesystem layout:
>
>
>1.  DASD device (non-LVM) --- (root filesystem)
>  (5) DASD devices for "sys" volume group for the rest of filesystem: 
> /var, /usr etc..
>
>  We can mount / filesystem on another zLinux system and have access to 
> /boot and  /etc and trying to rebuild grub and is unsussceful.
>
>  Any help?
>
>  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
>
>
> --
> 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

--
Martha McConaghy
Marist: System Architect/Technical Lead
SHARE Association: Vice President
Marist College IT
Poughkeepsie, NY 12601

--
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: Server don't boot after patch

[Marcy Cortes]

Exactly what happened to us.   I posted here last month when it happenend.

SUSE has given us a temp PTF that we've just started testing

What you need to do to recover is to boot a rescue system and bring on all your 
devices with chzdev. 
Then run mkinitrd and grub2-install and cross your fingers. 

Marcy

On 7/13/19, 6:11 AM, "Linux on 390 Port on behalf of Victor Echavarry" 
 wrote:

Hi:

Yesterday  after perform an update in one of our test servers (SLES12 SP4) 
and after updating & rebooting, now the server won't boot. This are the messages

Booting default (grub2)
dracut-initqueue[403]: Warning: dracut-initqueue timeout - starting timeout 
scri
pts
dracut-initqueue[403]: Warning: dracut-initqueue timeout - starting timeout 
scr

dracut-initqueue[403]: Warning: dracut-initqueue timeout - starting timeout 
scri
pts
dracut-initqueue[403]: Warning: Could not boot.
 Starting Dracut Emergency Shell...
Warning: /dev/mapper/sys-user does not exist
Warning: /dev/sys/user 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

Please note, this server has the following filesystem layout:


  1.  DASD device (non-LVM) --- (root filesystem)
(5) DASD devices for "sys" volume group for the rest of filesystem: /var, 
/usr etc..

We can mount / filesystem on another zLinux system and have access to /boot 
and  /etc and trying to rebuild grub and is unsussceful.

Any help?

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


--
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: fsck failed during reboot

[Marcy Cortes]

Did you get any of these messages?
dracut-initqueue[327]: Warning: dracut-initqueue timeout - starting timeout 
scripts
And then the LVM got confused and I had to vgscan in rescure mode to repair it.

Sounds a lot like what I reported here about 3 weeks ago, but it was SP4, so 
maybe not the same thing.   SUSE has created a PTF.


-Original Message-
From: Linux on 390 Port  On Behalf Of van Sleeuwen, 
Berry
Sent: Tuesday, July 2, 2019 3:49 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] fsck failed during reboot

Hi Marcy,

It's SLES12 SP3 and no disks were added. So it should have booted normally.

As far as I could tell, all disks that were needed were available. But maybe I 
should have looked at more closely before we rebooted without the file system 
check.

Anyway, I have re-enabled the filesystem check for the LVM and rebooted. The 
reboot was executed without any problems. So we can't reproduce the error at 
this time. Looks like this was just an unlucky incident. We will monitor the 
next time we reboot, should it happen again we can collect some more data to 
investigate.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven


--
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: fsck failed during reboot

[Marcy Cortes]

Is this SP4?  Did you add disks lately?
Do you see all your disks needed if you run these two commands?
lsinitrd
lsinitrd /boot/zipl/initrd

Marcy

-Original Message-
From: Linux on 390 Port  On Behalf Of van Sleeuwen, 
Berry
Sent: Tuesday, July 2, 2019 12:49 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] fsck failed during reboot

Hi Mark,

Oops. It turns out the rdsosreport.txt isn't saved properly. So after the 
reboot we lost this.

I ran journalctl and watched for an eyecatcher. I noticed the LVM2_member 
missing message and not checking dasdl1. I can't remember any obvious message 
prior to that.

Unfortunately the regular console log doesn't provide more information on that 
either. In fact, it's even more confusing as this has no apparent problem with 
dasdl1. Below the console, copied from the PROP log, but the last message 
before "Generating.." is lost.

dasdm:(nonl) dasdm1  OK
Found device /dev/dasdl1.  OK
Started dracut initqueue hook.
Starting File System Check on /dev/dasdl1...  OK
Reached target Remote File Systems (Pre). OK
Reached target Remote File Systems.  OK
Started File System Che

Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode.

I have re-enabled the file system check for the LVM disk, let's see if this 
will once again introduce the error.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven

-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Monday, July 01, 2019 11:19 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: fsck failed during reboot

On 7/1/19 11:05 AM,  van Sleeuwen, Berry  wrote:
> Hi All,
>
> Today we have restarted an SLES12 guest. It fails the filesystem check, it 
> looks like on an LVM disk. I have disabled the filesystem check for the LVM 
> disk and then a new boot is successful.
>
> During reboot I get the error:
> systemd[1]: Reached target Remote File Systems.
> systemd-fsck[482]: fsck.LVM2_member doesn't exist, not checking file system 
> on /dev/dasdl1.
> systemd[1]: Started File System Check on /dev/dasdl1.
> systemd[1]: Mounting /sysroot...
> mount[485]: mount: you must specify the filesystem type
> systemd[1]: sysroot.mount: Mount process exited, code=exited status=1
> systemd[1]: Failed to mount /sysroot.
>
> The /dev/dasdl1 is the root disk and is not part of any LVM.
>
> What can cause this failure?

I'm not sure. The messages prior to these may provide a clue.


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://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390data=02%7C01%7CBerry.vanSleeuwen%40atos.net%7Cf78fac326ec44166c6c008d6fe6a8b9b%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C636976130910985464sdata=WAb2xQEs3VFJgQTMnnLGn7O3q4XIGdSV4YjoRoZlILI%3Dreserved=0
This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

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

[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

[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

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

[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

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: Questions About Accessing the Forum

[Marcy Cortes]

That's what I was going to tell him, but it throws up a page doesn't exist 
message

-Original Message-
From: Linux on 390 Port  On Behalf Of Rich Smrcina
Sent: Thursday, May 2, 2019 5:38 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Questions About Accessing the Forum

Subscription information is appended to the end of each message from this forum.

Rich Smrcina
Sr. Systems Engineer

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


> On May 2, 2019, at 7:34 PM, Kyle Stewart  
> wrote:
> 
> I don't have the url for this forum, only the email address.  I would like to 
> register and view and post to the forum like on the z/VM forum.  How do I go 
> about doing that?
> 
> Thanks,
> 
> Kyle Stewart | Systems Engineer
> e: mailto:kyle.stew...@zionsbancorp.com
> 
> ==
> THIS ELECTRONIC MESSAGE, INCLUDING ANY ACCOMPANYING DOCUMENTS, IS 
> CONFIDENTIAL and may contain information that is privileged and exempt from 
> disclosure under applicable law. If you are neither the intended recipient 
> nor responsible for delivering the message to the intended recipient, please 
> note that any dissemination, distribution, copying or the taking of any 
> action in reliance upon the message is strictly prohibited. If you have 
> received this communication in error, please notify the sender immediately.  
> Thank you.
> 
> --
> 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 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 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: Horizontal vs. Vertical on guest on z/VM

[Marcy Cortes]

OK, thanks!  Just making sure I'm not crazy!   Thanks for answering so late at 
night!


-Original Message-
From: Linux on 390 Port  On Behalf Of Alan Altmark
Sent: Wednesday, March 20, 2019 10:19 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Horizontal vs. Vertical on guest on z/VM

There is no virtualization of the topology, so horizontal it must be.


Regards,
Alan Altmark
IBM

> On Mar 21, 2019, at 12:45 AM, Marcy Cortes
 wrote:
>
> So knowing z/VM is running vertical, should I be concerned that linux is
horizontal?
>
> This is sles12 sp3
>
> # lscpu
> Architecture:  s390x
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Big Endian
> CPU(s):6
> On-line CPU(s) list:   0-5
> Thread(s) per core:1
> Core(s) per socket:1
> Socket(s) per book:1
> Book(s) per drawer:1
> Drawer(s): 6
> NUMA node(s):  1
> Vendor ID: IBM/S390
> Machine type:  2964
> BogoMIPS:  3033.00
> Hypervisor:z/VM 6.4.0
> Hypervisor vendor: IBM
> Virtualization type:   full
> Dispatching mode:  horizontal
> L1d cache: 128K
> L1i cache: 96K
> L2d cache: 2048K
> L2i cache: 2048K
> L3 cache:  65536K
> L4 cache:  491520K
> NUMA node0 CPU(s): 0-63
> Flags: esan3 zarch stfle msa ldisp eimm dfp edat etf3eh
highgprs te vx sie
>
> 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
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M=jCSqMmF2fN4kdgZICrdDt0HXcWLVGmLlUx9ArFiRM3g=pp_c_T0QanZFoJfk6raMEo-oAp2iiYYbyeKronwfx-k=

>

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

Horizontal vs. Vertical on guest on z/VM

[Marcy Cortes]

So knowing z/VM is running vertical, should I be concerned that linux is 
horizontal?

This is sles12 sp3

# lscpu
Architecture:  s390x
CPU op-mode(s):32-bit, 64-bit
Byte Order:Big Endian
CPU(s):6
On-line CPU(s) list:   0-5
Thread(s) per core:1
Core(s) per socket:1
Socket(s) per book:1
Book(s) per drawer:1
Drawer(s): 6
NUMA node(s):  1
Vendor ID: IBM/S390
Machine type:  2964
BogoMIPS:  3033.00
Hypervisor:z/VM 6.4.0
Hypervisor vendor: IBM
Virtualization type:   full
Dispatching mode:  horizontal
L1d cache: 128K
L1i cache: 96K
L2d cache: 2048K
L2i cache: 2048K
L3 cache:  65536K
L4 cache:  491520K
NUMA node0 CPU(s): 0-63
Flags: esan3 zarch stfle msa ldisp eimm dfp edat etf3eh 
highgprs te vx sie

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

Re: Upgrade sles 12sp4 - sles 15

[Marcy Cortes]

What does “zypper pd” show?


From: Mark Post mailto:mp...@suse.com>>
Date: Friday, Mar 15, 2019, 8:30 AM
To: LINUX-390@VM.MARIST.EDU 
mailto:LINUX-390@VM.MARIST.EDU>>
Subject: Re: [LINUX-390] Upgrade sles 12sp4 - sles 15

On 3/15/19 9:50 AM, Mark Pace wrote:
> Has anyone done a successful upgrade from sles12 sp4 to sles 15 via
> Upgrade=1
>
> Doing upgrade via VNC -
>
> Everything looks pretty normal at the beginning. But once I select the
> partition to be upgraded I receive a pop-up - Error No migration product
> found.

This is the first I've heard of it. One of our customers does a lot of
testing of just this scenario during the beta testing, so I'm a little
surprised to hear of problems doing that.

The logs under /var/log/YaST2/ would provide some insight into what YaST
is trying to do before it gives up and displays that dialog box.


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 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: Persistent change to use layer2 in SLES 11 SP4

[Marcy Cortes]

/etc/udev/rules.d/  file for the device

Here's what one looks like

ACTION=="add", SUBSYSTEM=="drivers", KERNEL=="qeth", IMPORT{program}="collect 
0.0.3000 %k 0.0.3000 0.0.3001 0.0.3002 qeth"
ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.3000", RUN+="/sbin/modprobe 
--quiet qeth"
ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.3000", IMPORT{program}="collect 
0.0.3000 %k 0.0.3000 0.0.3001 0.0.3002 qeth"
ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.3001", RUN+="/sbin/modprobe 
--quiet qeth"
ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.3001", IMPORT{program}="collect 
0.0.3000 %k 0.0.3000 0.0.3001 0.0.3002 qeth"
ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.3002", RUN+="/sbin/modprobe 
--quiet qeth"
ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.3002", IMPORT{program}="collect 
0.0.3000 %k 0.0.3000 0.0.3001 0.0.3002 qeth"
TEST=="[ccwgroup/0.0.3000]", GOTO="qeth-0.0.3000_end"
ACTION=="add", SUBSYSTEM=="ccw", ENV{COLLECT_0.0.3000}=="0", 
ATTR{[drivers/ccwgroup:qeth]group}="0.0.3000,0.0.3001,0.0.3002"
ACTION=="add", SUBSYSTEM=="drivers", KERNEL=="qeth", 
ENV{COLLECT_0.0.3000}=="0", 
ATTR{[drivers/ccwgroup:qeth]group}="0.0.3000,0.0.3001,0.0.3002"
LABEL="qeth-0.0.3000_end"
# Enable Layer2 Support
ACTION=="add", SUBSYSTEM=="ccwgroup", KERNEL=="0.0.3000", ATTR{layer2}="1"
ACTION=="add", SUBSYSTEM=="ccwgroup", KERNEL=="0.0.3000", ATTR{online}="1"





-Original Message-
From: Linux on 390 Port  On Behalf Of Alan Altmark
Sent: Friday, March 1, 2019 8:45 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Persistent change to use layer2 in SLES 11 SP4

Help!   I have a dead network connection at a client and need to get it 
switched to layer2.   What file do I have to change?  I'd use yast, but I 
have no network connection with which to do so.  Just the virtual machine 
console.  I can see it trying to register layer 3 discipline, but this is 
(now) an ETHERNET mode VSWITCH.

Thanks!
Alan 
Alan Altmark
Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
Phone: 607-429-3323 | Mobile: 607-321-7556
E-mail: altma...@us.ibm.com   
Endicott, NY  USA


--
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 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: order of eth0/eth1 and udev rules vs kernel discovery

[Marcy Cortes]

SUSE does this in /etc/udev/rules.d/

cat 70-persistent-net.rules
# This file was automatically generated by the /usr/lib/udev/write_net_rules
# program,run by the persistent-net-generator.rules rules file.
#
# You can modify it,as long as you keep each rule on a single
# line,and change only the value of the NAME= key.
# S/390 qeth device at 0.0.3000
# S/390 qeth device at 0.0.4000
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", ATTR{dev_id}=="0x0", 
KERNELS=="0.0.3000", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", ATTR{dev_id}=="0x0", 
KERNELS=="0.0.4000", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

FWIW.  



-Original Message-
From: Linux on 390 Port  On Behalf Of Grzegorz 
Powiedziuk
Sent: Tuesday, January 15, 2019 1:03 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] order of eth0/eth1 and udev rules vs kernel discovery

> But if I want device 2000 to become eth0 and it happened to be eth0 then
> it will fail because 3000 is using already eth0 name ...
>
> Sorry, I had a typo which turned above into a complete nonsense
I meant of course that it it happened to be eth1 after kernel discovery and
I want it to be renamed to eth0 it will fail (because eth0 is used by 3000)
thanks
Gregory

--
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 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: Linux systemd affected by memory corruption vulnerabilities, no patches yet

[Marcy Cortes]

There are many indeed. 
I should make a list some day.

Kinda cool that SLES 15 is immune because of compiling.   Maybe there's hope 
that our future includes less patching!

Marcy

-Original Message-
From: Linux on 390 Port  On Behalf Of Dave Jones
Sent: Friday, January 11, 2019 6:56 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Linux systemd affected by memory corruption 
vulnerabilities, no patches yet

Yet another reason to dislike systemd
https://www.bleepingcomputer.com/news/security/linux-systemd-affected-by-memory-corruption-vulnerabilities-no-patches-yet/

Don't know yet if this effects Linux on z.
DJ

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

INFORMATION TECHNOLOGY COMPANY

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

zLinux in the news

[Marcy Cortes]

https://www.zdnet.com/article/irs-linux-move-delayed-by-lingering-oracle-solaris-systems/


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://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Expanding root VG issue

[Marcy Cortes]

We use /dev/disk/by-path/ccw-0.0.-part1 /   in /etc/fstab for the root file 
system

Not sure what distro you are on, but dasd_configure will create the appropriate 
udev rules for new disks as well.



-Original Message-
From: Linux on 390 Port  On Behalf Of Neal Scheffler
Sent: Wednesday, December 12, 2018 8:40 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Expanding root VG issue

The Linux group expanded the root vg to a second physical dasd volume.
Doing a pvdisplay shows the PV Name of /dev/dasdm1
zipl.conf was updated to include the parm "rd.dasd=0.0.010a" since
this is part of the root file system.

After reboot, dasd 010a is now /dev/dasdb1 so the server reboot failed.

What is the best way to handle this?
Should they be using /dev/disk/by-path/ccw-0.0.010a-part1 to reference
the new dasd?

Thanks,
Neal

--
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: issue with Grub under z/Linux

[Marcy Cortes]

Looks like you might have a resume= in your kernel command line?
cat /proc/cmdline and check

You can remove with Yast2, system, Boot Loader, Kernel Parms


-Original Message-
From: Linux on 390 Port  On Behalf Of Victor Echavarry
Sent: Tuesday, July 31, 2018 1:54 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] issue with Grub under z/Linux

We made an upgrade from SLES 11 to SLES 12. When boot the system using GRUB we 
saw the following.


LOGON L222P
 ICH70001I L222PLAST ACCESS AT 16:19:27 ON TUESDAY, JULY 31, 2018
NIC 0360 is created; devices 0360-0362 defined NIC 0380 is created; devices 
0380-0382 defined z/VM Version 6 Release 4.0, Service Level 1601 (64-bit), 
built on IBM Virtualization Technology There is no logmsg data
FILES:   NO RDR, 0010 PRT,   NO PUN
LOGON AT 16:29:32 AST TUESDAY 07/31/18
00: CPU 01 defined
z/VM V6.4.02017-11-11 23:41
DMSACP723I A (191) R/O
00: RPIMGR032E YOU ARE NOT AUTHORIZED TO SPOOL TO MAINT630
00: HCPSPL007E Invalid userid - MAINT630 DMSACP113S D(19F) not attached or 
invalid device address DIAG swap disk defined at virtual address 160 (126934 4K 
pages of swap space) Enter a non-blank character and ENTER (or two ENTERs) 
within 10  seconds to interrupt Linux IPL.
DMSCYW2246I 16:29:32 WAKEUP in (10 sec).
00: DASD 0190 DETACHED
00: DASD 0191 DETACHED
00: DASD 019E DETACHED
00: HCPDTV040E Device 019F does not exist
00: Booting default (grub2)
01: HCPGSP2627I The virtual machine is placed in CP mode due to a SIGP initial 
C PU reset from CPU 00.
[* ] A start job is running for dev-dasdp1.device (7s / 1min 30s)  [K[**
] A start job is running for dev-dasdp1.device (8s / 1min 30s)  [K[***   ] A sta
rt job is running for dev-dasdp1.device (8s / 1min 30s)  [K[ ***  ] A start job 
is running for dev-dasdp1.device (9s / 1min 30s)  [K[  *** ] A start job is runn
ing for dev-dasdp1.device (10s / 1min 30s)  [K[   ***] A start job is running fo
r dev-dasdp1.device (10s / 1min 30s)  [K[**] A start job is running for dev-
dasdp1.device (11s / 1min 30s)  [K[ *] A start job is running for dev-dasdp1
.device (11s / 1min 30s)  [K[**] A start job is running for dev-dasdp1.devic
e (12s / 1min 30s)  [K[   ***] A start job is running for dev-dasdp1.device (13s
/ 1min 30s)  [K[  *** ] A start job is running for dev-dasdp1.device (13s / 1mi 
n 30s)  [K[ ***  ] A start job is running for dev-dasdp1.device (14s / 1min 30s)
  [K[***   ] A start job is running for dev-dasdp1.device (14s / 1min 30s)  [K[*
*] A start job is running for dev-dasdp1.device (15s / 1min 30s)  [K[* ]
A start job is running for dev-dasdp1.device (15s / 1min 30s)  [K[**] A sta
rt job is running for dev-dasdp1.device (16s / 1min 30s)
  [K[***   ] A start job is running for dev-dasdp1.device (17s / 1min 30s)  [K[
***  ] A start job is running for dev-dasdp1.device (17s / 1min 30s)  [K[  *** ]
A start job is running for dev-dasdp1.device (18s / 1min 30s)  [K[   ***] A sta
rt job is running for dev-dasdp1.device (18s / 1min 30s)  [K[**] A start job
is running for dev-dasdp1.device (19s / 1min 30s)  [K[ *] A start job is ru
nning for dev-dasdp1.device (20s / 1min 30s)  [K[**] A start job is running
for dev-dasdp1.device (20s / 1min 30s)  [K[   ***] A start job is running for de
v-dasdp1.device (21s / 1min 30s)  [K[  *** ] A start job is running for 
dev-dasd p1.device (21s / 1min 30s)  [K[ ***  ] A start job is running for 
dev-dasdp1.dev
ice (22s / 1min 30s)  [K[***   ] A start job is running for dev-dasdp1.device (2
2s / 1min 30s)  [K[**] A start job is running for dev-dasdp1.device (23s / 1
min 30s)  [K[* ] A start job is running for dev-dasdp1.device (24s / 1min 30
s)  [K[**] A start job is running for dev-dasdp1.device (24s / 1min 30s)  [K
[***   ] A start job is running for dev-dasdp1.device (25s / 1min 30s)  [K[ ***
 ] A start job is running for dev-dasdp1.device (25s / 1min 30s)  [K[  *** ] A s
tart job is running for dev-dasdp1.device (26s / 1min 30s)  [K[   ***] A start j
ob is running for dev-dasdp1.device (27s / 1min 30s)  [K[**] A start job is
running for dev-dasdp1.device (27s / 1min 30s)  [K[ *] A start job is runnin
g for dev-dasdp1.device (28s / 1min 30s)  [K[**] A start job is running for
dev-dasdp1.device (28s / 1min 30s)  [K[   ***] A start job is running for dev-da
sdp1.device (29s / 1min 30s)  [K[  *** ] A start job is running for 
dev-dasdp1.d evice (29s / 1min 30s)
  [K[ ***  ] A start job is running for dev-dasdp1.device (30s / 1min 30s)  [K[*
**   ] A start job is running for dev-dasdp1.device (31s / 1min 30s)  [K[**]
A start job is running for dev-dasdp1.device (31s / 1min 30s)  [K[* ] A sta
rt job is running for dev-dasdp1.device (32s / 1min 30s)  [K[**] A start job
is running for dev-dasdp1.device (32s / 1min 30s)  [K[***   ] A start job is ru
nning for dev-dasdp1.device (33s / 1min 30s)  [K[ ***  ] A start job is running 
for dev-dasdp1.device (34s / 1min 30s)  [K[  *** ] A start job is running for de

z14 software warnings for GSKIT things

[marcy cortes]

If you are putting in a z14 and are running Connect:Direct under Linux you
need to get a yet unreleased fixpack or all of your secure+ will fail.


Spectrum Scale also requires 4.2.3.6 and WAS IHS requires 8.5.5.13.

Anything that uses GSKIT needs examination.  MQ and DB2 also use it.  We
haven’t seen problems there but we also are very current on all software
these days.


-- 
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://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Connect:Direct on z14?

[Marcy Cortes]

Is anyone successfully running IBM Connect:Direct for Linux on a z14 using TLS 
1.2?


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/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Marcy Cortes]

That is what we did and Ted found it on the first try, which is good because 
most of our servers don't have xfs.

We did have an issue with the kernel that came with SLES 11 SP4 initially.
It was a very intermittent problem with NFS client that only seemed to happen 
to us in production.   We never could recreate in a test environment.   And 
when it struck, the only way out was a reboot.  It didn't rear its head 
immediately but over a few weeks and then oddly got more frequent.
So Just Saying, you need to be able to back out only the broken pieces...   
Luckily the SUSE stuff with multiversion kernels makes it easy ( I have no idea 
if RH or other distros do that.



-Original Message-
From: Linux on 390 Port <LINUX-390@VM.MARIST.EDU> On Behalf Of Mike Walter
Sent: Thursday, May 24, 2018 11:00 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Bug with XFS and SLES 12SP3 
kernel-default-4.4.131-94.29-default

I'm just supposing here, that you put and it's on a test bed server first, at 
which point you would have found the problem with the xfs file system and been 
able to back it out. Only after maintenance has been thoroughly vetted on the 
test bed server wood shove it down the throats of the other servers.

But, I never was responsible for Linux on Z systems servers, so I may have 
missed out on all the fun.

Mike Walter
-Retired-

From: Linux on 390 Port <LINUX-390@VM.MARIST.EDU> on behalf of Marcy Cortes 
<marcy.d.cor...@wellsfargo.com>
Sent: Thursday, May 24, 2018 11:00:12 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

Nice idea, but when you have a thousand servers, that isn't very practical.  
And one your server has been up a few minutes its data has changed and 
regressing it that way may be a problem.   The multi kernel support works well 
for things like backing out the kernel.




-Original Message-
From: Linux on 390 Port <LINUX-390@VM.MARIST.EDU> On Behalf Of John McKown
Sent: Thursday, May 24, 2018 7:51 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Bug with XFS and SLES 12SP3 
kernel-default-4.4.131-94.29-default

On Thu, May 24, 2018 at 9:29 AM Mike Walter <walterthepennyl...@hotmail.com>
wrote:

> When I was a young man learning the art of systems programming sooo 
> long ago, I was taught that the first step of applying maintenance is 
> to make a physical backup of the target volumes.  That way you have a 
> validated source with which to return if/when the maintenance fails.  Just 
> sayin'.
> :-)
>

​Total agreement. I'm having a problem with a sandox system right now with some 
maintenance (but it's z/OS, not Linux). But that's what I did -- physical back 
of all the volumes before doing _anything_. I do the same sort of thing when I 
install a never version of a product. I do a "tar"
backup of the various files (it they're in /etc or /var or ...) & filesystems.​



--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390=02%7C01%7C%7C74815a2d96a04a6abef508d5c18fc160%7C84df9e7fe9f640afb435%7C1%7C0%7C636627745517533603=T6se4MfGCrQKhEoLAl1GSZdahtAXs2ZZd4gZiuAwgjU%3D=0
--
For more information on Linux on System z, visit
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%2F=02%7C01%7C%7C74815a2d96a04a6abef508d5c18fc160%7C84df9e7fe9f640afb435%7C1%7C0%7C636627745517533603=84ePrZlYwZTFJpCrEaMBxk9u2g%2FiN1kja9rARzKuHl0%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: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Marcy Cortes]

Nice idea, but when you have a thousand servers, that isn't very practical.  
And one your server has been up a few minutes its data has changed and 
regressing it that way may be a problem.   The multi kernel support works well 
for things like backing out the kernel.


 

-Original Message-
From: Linux on 390 Port  On Behalf Of John McKown
Sent: Thursday, May 24, 2018 7:51 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Bug with XFS and SLES 12SP3 
kernel-default-4.4.131-94.29-default

On Thu, May 24, 2018 at 9:29 AM Mike Walter 
wrote:

> When I was a young man learning the art of systems programming sooo 
> long ago, I was taught that the first step of applying maintenance is 
> to make a physical backup of the target volumes.  That way you have a 
> validated source with which to return if/when the maintenance fails.  Just 
> sayin'.
> :-)
>

​Total agreement. I'm having a problem with a sandox system right now with some 
maintenance (but it's z/OS, not Linux). But that's what I did -- physical back 
of all the volumes before doing _anything_. I do the same sort of thing when I 
install a never version of a product. I do a "tar"
backup of the various files (it they're in /etc or /var or ...) & filesystems.​



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