Re: RHEL 7.8 -> 8 - LEAPP PREUPGRADE - The processor is not supported by the target system
Dan, I eliminated everything that would *INHIBIT* the upgrade that was reported by ... leap preupgrade ... except the "The processor is not supported by the target system": <<< snip >>> UPGRADE INHIBITED Upgrade has been inhibited due to the following problems: 1. Inhibitor: The processor is not supported by the target system. Consult the pre-upgrade report for details and possible remediation. UPGRADE INHIBITED <<< snip >>> Unfortunately, when you run ... leap upgrade ... it redoes all of the same checks, reports the same problem, and aborts the upgrade. Do you or anyone else out there know of a workaround for this? JR (Steven) Imler Sr. Software Engineer | Mainframe Division Broadcom office: +1 571.401.8685 2291 Wood Oak Drive | Herndon, Virginia 20171 steven.im...@broadcom.com | broadcom.com -Original Message- From: Linux on 390 Port On Behalf Of Dan Horák Sent: Wednesday, July 22, 2020 09:06 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: RHEL 7.8 -> 8 - LEAPP PREUPGRADE - The processor is not supported by the target system On Wed, 22 Jul 2020 08:54:50 -0400 Steven Imler wrote: > The root of the issue, which I did not realize was a problem, is that > I am running on a z15 processor. The zLinux is a z/VM virtual machine > (guest). > > > > In preparation for the RHEL 8 update-in-place, I first had to update > RHEL 7.6 o 7.8 that all went fine and of course this zLinux system has > been running on a z15 for months (although it was initially installed > on a z14). > > > > So, with all the pieces in place, I ran LEAPP PREUPGRADE that reports > this show-stopper: > > > > <<< snip >>> > > > > Risk Factor: high (inhibitor) > > Title: The processor is not supported by the target system. > > Summary: The system is not possible to upgrade because of unsupported > type of the processor. Based on the official documentation, z13 and > z14 processors are supported on the Red Hat Enterprise Linux 8 system > for the IBM Z architecture. The supported processors have machine > types 2964, 2965, 3906, 3907. The detected machine type of the CPU is > '8561'. > > > > <<< snip >>> > > > > I couldn’t find fix for this, other than 8.2 supports z15. Does anyone > know of a workaround? If I ignore the report and run the upgrade, will > it run anyway? I believe it will be harmless when you ignore the warning, clearly sounds like a bug in the tool. RHEL 8 runs on z15 just fine. And report it to Red Hat, please. Dan -- 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: z/15 and SLES 11SP4
We are running about 2700 SLES11 servers at kernel levels, 3.0.101-108.108-default, 3.0.101-108.111-default , on z15's, no issues so far. Regards, Phil Tully Chief Architect-z/VM & z/Linux phil.tu...@adp.com cell: 973-202-7427 1-800 377-0237,,5252697# On 7/22/20, 2:04 AM, "Linux on 390 Port on behalf of Mark Post" wrote: WARNING: Do not click links or open attachments unless you recognize the source of the email and know the contents are safe. ** On 7/21/20 5:40 PM, Victor Echavarry wrote: > Does anybody has an IBM z/15 running z/Linux SLES 11 SP4 kernel-default-3.0.101-108.87.1? we are in a middle of migration from SLES 11 to 12 that supposed to finish at the end of year. Our company buy a z/15 and we want to know is the SLES 11 runs on the z/15 to finish the migration. SUSE does not have a z15, so we are not able to test that combination. Personally, I wouldn't risk trying 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwICaQ=xu_5lAfKHjInGFR3ndoZrw=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU=9fSOn-3E4doksQBrL3CyzchPqzkU_a75xRTSOEQHTtM=lvJPfvyWpHyzcnWK3hbAv7pX7RQTRibGQHgUeGuB9Hs= -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: VM system name
On 7/22/20 4:44 PM, Alan Ackerman wrote: > As far as I know they are running Red Hat. > > Why does that matter? Because I work for SUSE, and any tools I write would be distributed by SUSE in the s390-tools package. I doubt very much Red Hat would pick it up for their distribution. But, you never know, I suppose. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: VM system name
As far as I know they are running Red Hat. Why does that matter? Alan Ackerman alan.ackerma...@gmail.com On Jul 20, 2020, at 12:16 PM, Mark Post wrote: 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
On 7/22/20 4:37 PM, Alan Ackerman wrote: > Humpf! I think my opinion still counts. I may never use it, but I think Bank > of America probably will. Are they running SUSE Linux Enterprise Server? Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: VM system name
Humpf! I think my opinion still counts. I may never use it, but I think Bank of America probably will. Alan Ackerman alan.ackerma...@gmail.com On Jul 20, 2020, at 12:16 PM, Mark Post wrote: 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: Unsubscribe
Click on this link http://www2.marist.edu/htbin/wlvindex?LINUX-390 and go to the bottom of the page. -Original Message- From: Linux on 390 Port On Behalf Of Brown, Duncan Sent: Wednesday, July 22, 2020 12:02 PM To: LINUX-390@VM.MARIST.EDU Subject: Unsubscribe Ok - how do I Unsubscribe from this list? I've sent this a few times now... Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website. -- 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
On 7/22/20 9:28 AM, Stefan Raspl wrote: > qclib, which was linked to earlier in the thread, offers all the info. Indeed, which is what I would have based anything I wrote on. -snip- > It seems like there's a use for most of the data provided by qc_test, > everybody > seems to find interest in some data. So I'm contemplating externalization of > qc_test output in some shape or form - but is that really consumable? Not as is, today. > However, externalizing it is easier said than done, since some of the fields > require a lot of explanation, especially in virtualized environments. > So: Would the output below help, or should we rather have a separate tool > with a > more comprehensible format? The latter. Please let me know if you're going to proceed with this. If so, I won't start working on the limited command I already talked about. Thanks, 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
RHEL 7.8 -> 8 - LEAPP PREUPGRADE - The processor is not supported by the target system
The root of the issue, which I did not realize was a problem, is that I am running on a z15 processor. The zLinux is a z/VM virtual machine (guest). In preparation for the RHEL 8 update-in-place, I first had to update RHEL 7.6 o 7.8 that all went fine and of course this zLinux system has been running on a z15 for months (although it was initially installed on a z14). So, with all the pieces in place, I ran LEAPP PREUPGRADE that reports this show-stopper: <<< snip >>> Risk Factor: high (inhibitor) Title: The processor is not supported by the target system. Summary: The system is not possible to upgrade because of unsupported type of the processor. Based on the official documentation, z13 and z14 processors are supported on the Red Hat Enterprise Linux 8 system for the IBM Z architecture. The supported processors have machine types 2964, 2965, 3906, 3907. The detected machine type of the CPU is '8561'. <<< snip >>> I couldn’t find fix for this, other than 8.2 supports z15. Does anyone know of a workaround? If I ignore the report and run the upgrade, will it run anyway? *JR (Steven) Imler* Sr. Software Engineer | Mainframe Division *Broadcom* *office:* +1 571.401.8685 2291 Wood Oak Drive | Herndon, Virginia 20171 steven.im...@broadcom.com | broadcom.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
Re: [EXTERNAL] Unsubscribe
Hi Duncan, Send SIGNOFF LINUX-390 to lists...@vm.marist.edu Peter Webb Technical Analyst Server Technology Information Technology Services T: 416-393-3549 Toronto Transit Commission McBrien Building, 1900 Yonge Street Toronto, ON M4S 1Z2 -Original Message- From: Linux on 390 Port On Behalf Of Brown, Duncan Sent: Wednesday, July 22, 2020 12:02 PM To: LINUX-390@VM.MARIST.EDU Subject: [EXTERNAL] Unsubscribe Email from outside TTC, proceed with caution Ok - how do I Unsubscribe from this list? I've sent this a few times now... Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website. -- 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 transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner. -- 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: lx-390] Unsubscribe
On Wed, 22 Jul 2020, Brown, Duncan wrote: > Ok - how do I Unsubscribe from this list? I've sent this a few times now... your mail reader may be hiding the footer: 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 -- Russ herrold -- 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
Unsubscribe
Ok - how do I Unsubscribe from this list? I've sent this a few times now... Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website. -- 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
On 2020-07-18 22:12, Alan Ackerman wrote:
> Yes! I spent a fair amount of time writing EXECs to figure these things out
> when I worked for Bank of America. I put the results on a web page that
> listed all our VM systems. I’m retired so I don’t need it any more.
>
> Sent from my iPhone
>
> On Jul 18, 2020, at 11:59 AM, Mark Post wrote:
>
> On 7/17/20 12:18 PM, Marcy Cortes wrote:
>> 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.
>
> Would people find it helpful if a command is introduced to the
> s390-tools package that will return one or more of the following data
> points:
> 1. z/VM or KVM Guest name
> 2. z/VM Host name
> 3. KVM Host name
> 4. LPAR name
> 5. CEC name
qclib, which was linked to earlier in the thread, offers all the info. As the
name implies, it is a library, but it comes with a sample program called qc_test
that is intended for debugging purposes. I did some work to provide a standalone
program based to provide the most commonly used data - at least the one *I*
figured might be popular - and which, of course, does not reflect any of the
fields requested above LOL
It seems like there's a use for most of the data provided by qc_test, everybody
seems to find interest in some data. So I'm contemplating externalization of
qc_test output in some shape or form - but is that really consumable?
However, externalizing it is easier said than done, since some of the fields
require a lot of explanation, especially in virtualized environments.
So: Would the output below help, or should we rather have a separate tool with a
more comprehensible format?
Here's some sample output from a Linux guest running under z/VM on top of a z/VM
resource pool (qc_layer_name is the attribute that would reflect the values 1-5
above):
[raspl@jungle qclib]$ ./qc_test
We are running 5 layer(s)
= Layer 0: CEC =
qc_layer_type [n/a]: CEC
qc_layer_category [n/a]: HOST
qc_layer_type_num [n/a]: 1
qc_layer_category_num [n/a]: 2
qc_layer_name [F V]: X35
qc_manufacturer [S V]: IBM
qc_type [S V]: 2827
qc_type_name [S ]: IBM zEnterprise EC12
qc_type_family [S ]: 0
qc_model_capacity [S ]: 703
qc_model [S ]: H66
qc_sequence_code [S V]: 00089F25
qc_lic_identifier [S ]:
qc_plant [S V]: 02
qc_num_core_total [S ]: 68
qc_num_core_configured [S ]: 3
qc_num_core_standby [S ]: 0
qc_num_core_reserved [S ]: 65
qc_num_core_dedicated [ hV]: 2
qc_num_core_shared [ hV]: 61
qc_num_cp_total [ HV]: 3
qc_num_cp_dedicated [ hV]: 0
qc_num_cp_shared [ hV]: 3
qc_num_ifl_total [ HV]: 60
qc_num_ifl_dedicated [ hV]: 2
qc_num_ifl_shared [ hV]: 58
qc_num_ziip_total [ HV]:
qc_num_ziip_dedicated [ hV]:
qc_num_ziip_shared [ hV]:
qc_num_cp_threads [S ]:
qc_num_ifl_threads [S ]:
qc_num_ziip_threads [S ]:
qc_capability [S ]: 552.00
qc_secondary_capability [S ]: 552.00
qc_capacity_adjustment_indication [S ]: 100
qc_capacity_change_reason [S ]: 0
= Layer 1: LPAR =
qc_layer_type [n/a]: LPAR
qc_layer_category [n/a]: GUEST
qc_layer_type_num [n/a]: 2
qc_layer_category_num [n/a]: 1
qc_layer_name [S V]: MYLPAR2
qc_layer_extended_name [S ]:
qc_layer_uuid [S ]:
qc_partition_number [S V]: 47
qc_partition_char [S ]: Shared
qc_partition_char_num [S ]: 2
qc_adjustment [S ]: 333
qc_has_secure [F ]:
qc_secure [F ]:
qc_num_core_total [S ]: 1
qc_num_core_configured [S ]: 1
qc_num_core_standby [S ]: 0
qc_num_core_reserved [S ]: 0
qc_num_core_dedicated [S ]: 0
qc_num_core_shared [S ]: 1
Re: 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 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 Bill Bitner Sent: Wednesday, July 22, 2020 7:55 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: z15 on-board compression Thanks Andreas, The problem is there is a bug in WAS when DFLTCC is used - Assessment by Java Development is that Wells Fargo's symptoms line up to be the same issue as experienced by another client several days earlier. In the first client's case, they were provided with an WAS Ifix (APAR PH27505) which prevents the endless looping that occurs when the JVM API does not report that the compressed data stream has reached the end. The client tested the WAS iFix and confirmed that it does prevent the endless looping during decompression. The current recommendation is for z15 zLinux clients running JAVA8 SR6 is to apply WAS APAR PH27505 and run with HW compression disabled (DFLTCC=0). Wells Fargo has 2000 Linux guests they would have to patch to fix and were looking for an easy way to just disable. Regards, Bill ___ Bill Bitner - z/VM Client Focus and Care - 607-429-3286 bitn...@us.ibm.com "Making systems practical and profitable for customers through virtualization and its exploitation." - z/VM From: Andreas Krebbel To: LINUX-390@VM.MARIST.EDU Date: 07/22/2020 07:49 AM Subject:[EXTERNAL] Re: z15 on-board compression Sent by:Linux on 390 Port Hi, I wrote a post about how to build and test zlib also for distros currently not supported: https://urldefense.proofpoint.com/v2/url?u=http-3A__linux-2Don-2Dz.blogspot.com_2019_10_howto-2Dexploiting-2Dhardware-2Dcompression.html=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=5MoiGnRMsqjUxHq7C7RX4kthfAKqf40IRGxojgucrwA=x1vmZzvvtIGmEi8_Y7og3XDpzRz1wa5VLMnZ-0HDnMA=uQF9dwXC8luEMIVM-xxLnLikZ8q2yREoz_7unCt3O30= You will find a quick one-liner test at the end of the post which can be used to verify whether hardware compression works in your installation. Andreas On 10.06.20 01:36, Michael MacIsaac wrote: > Hello list, > > I heard about the new DFLTCC instruction on the z15, aka on board > compression. I tried a quick experiment to see the difference from a z14. > Disclaimer: I am not a performance expert.> > Here are three commands to create, compress and decompress a 1G file on a > z14: > > # grep Type: /proc/sysinfo > Type: 3906 > > # time dd if=/dev/zero of=1G.file bs=1G count=1 > 1+0 records in > 1+0 records out > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 21.93 s, 49.0 MB/s > > real0m22.047s > user0m0.001s > sys 0m3.669s > > # time cat 1G.file | gzip -c > 1G.compressed.file > > real0m7.603s > user0m5.362s > sys 0m0.789s > > # time cat 1G.compressed.file | gzip -d > 1G.file > > real0m24.833s > user0m4.103s > sys 0m1.845s > > Here's the same commands on z15: > > # grep Type: /proc/sysinfo > Type: 8561 > > # time dd if=/dev/zero of=1G.file bs=1G count=1 > 1+0 records in > 1+0 records out > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.59126 s, 675 MB/s > > real0m1.621s > user0m0.000s > sys 0m1.216s > > # time cat 1G.file | gzip -c > 1G.compressed.file > > real0m5.722s > user0m4.946s > sys 0m0.510s > # time cat 1G.compressed.file | gzip -d > 1G.file > > real0m6.150s > user0m3.922s > sys 0m1.290s > > Wow more than 10x faster on dd - was not expecting that as I didn't think > it uses compression. But the compress with gzip -c, was only 25% faster on > the z15 while the decompress was about 4x. > > Are these results expected? > > Thanks. > > > -- > -Mike MacIsaac > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > https://urldefense.proofpoint.com/v2/url?u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=5MoiGnRMsqjUxHq7C7RX4kthfAKqf40IRGxojgucrwA=x1vmZzvvtIGmEi8_Y7og3XDpzRz1wa5VLMnZ-0HDnMA=FQsLX2gZ60YhLotQ1szspOspNp8arGQloNna6pa4DhI= > -- 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=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=5MoiGnRMsqjUxHq7C7RX4kthfAKqf40IRGxojgucrwA=x1vmZzvvtIGmEi8_Y7og3XDpzRz1wa5VLMnZ-0HDnMA=FQsLX2gZ60YhLotQ1szspOspNp8arGQloNna6pa4DhI= -- For
Re: RHEL 7.8 -> 8 - LEAPP PREUPGRADE - The processor is not supported by the target system
On Wed, 22 Jul 2020 08:54:50 -0400 Steven Imler wrote: > The root of the issue, which I did not realize was a problem, is that > I am running on a z15 processor. The zLinux is a z/VM virtual machine > (guest). > > > > In preparation for the RHEL 8 update-in-place, I first had to update > RHEL 7.6 o 7.8 that all went fine and of course this zLinux system > has been running on a z15 for months (although it was initially > installed on a z14). > > > > So, with all the pieces in place, I ran LEAPP PREUPGRADE that reports > this show-stopper: > > > > <<< snip >>> > > > > Risk Factor: high (inhibitor) > > Title: The processor is not supported by the target system. > > Summary: The system is not possible to upgrade because of unsupported > type of the processor. Based on the official documentation, z13 and > z14 processors are supported on the Red Hat Enterprise Linux 8 system > for the IBM Z architecture. The supported processors have machine > types 2964, 2965, 3906, 3907. The detected machine type of the CPU is > '8561'. > > > > <<< snip >>> > > > > I couldn’t find fix for this, other than 8.2 supports z15. Does > anyone know of a workaround? If I ignore the report and run the > upgrade, will it run anyway? I believe it will be harmless when you ignore the warning, clearly sounds like a bug in the tool. RHEL 8 runs on z15 just fine. And report it to Red Hat, please. Dan -- 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: z/15 and SLES 11SP4
On 22.07.20 14:24, Christian Borntraeger wrote: > On 22.07.20 13:07, Christian Borntraeger wrote: >> On 21.07.20 23:40, Victor Echavarry wrote: >>> Does anybody has an IBM z/15 running z/Linux SLES 11 SP4 >>> kernel-default-3.0.101-108.87.1? we are in a middle of migration from SLES >>> 11 to 12 that supposed to finish at the end of year. Our company buy a z/15 >>> and we want to know is the SLES 11 runs on the z/15 to finish the migration. >> >> The combination of distros and hardware that was tested by IBM and/or the >> distribution parter can be found here >> https://www.ibm.com/it-infrastructure/z/os/linux-tested-platforms. >> As you can see SLES11 was not tested with z15. Reason was that SLES11 was >> already end of life (march 2019) when z15 went GA (see >> https://www.suse.com/lifecycle/) and only extended support contracts are >> available. >> FWIW, if the planned software already supports SLES15, I would encourage you >> to switch to SLES15SP2 instead of SLES12. EOL for SLES12 is 2024 and EOL for >> SLES15 is 2028. But you need to double check that all dependencies are >> available for SLES15. > > Let me correct myself. We do not have a certification, but the combination > was tested inside IBM. > So tested but not certified. > > See > https://www.ibm.com/support/pages/node/6191619 Which also means that you should update your kernel to the version mentioned here or newer. -- 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: z/15 and SLES 11SP4
On 22.07.20 13:07, Christian Borntraeger wrote: > On 21.07.20 23:40, Victor Echavarry wrote: >> Does anybody has an IBM z/15 running z/Linux SLES 11 SP4 >> kernel-default-3.0.101-108.87.1? we are in a middle of migration from SLES >> 11 to 12 that supposed to finish at the end of year. Our company buy a z/15 >> and we want to know is the SLES 11 runs on the z/15 to finish the migration. > > The combination of distros and hardware that was tested by IBM and/or the > distribution parter can be found here > https://www.ibm.com/it-infrastructure/z/os/linux-tested-platforms. > As you can see SLES11 was not tested with z15. Reason was that SLES11 was > already end of life (march 2019) when z15 went GA (see > https://www.suse.com/lifecycle/) and only extended support contracts are > available. > FWIW, if the planned software already supports SLES15, I would encourage you > to switch to SLES15SP2 instead of SLES12. EOL for SLES12 is 2024 and EOL for > SLES15 is 2028. But you need to double check that all dependencies are > available for SLES15. Let me correct myself. We do not have a certification, but the combination was tested inside IBM. So tested but not certified. See https://www.ibm.com/support/pages/node/6191619 -- 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
Oops ___ Bill Bitner - z/VM Client Focus and Care - 607-429-3286 bitn...@us.ibm.com "Making systems practical and profitable for customers through virtualization and its exploitation." - z/VM -- 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: RHEL 8 32 bit libraries
Hi, RHEL 8 and Sles 15 do not provide 32 bit libs for S/390 anymore. For which software do you need 32 bit support on S/390? Andreas On 22.07.20 03:09, Bhemidhi, Ashwin wrote: > Hello, > > I am looking to install 32 bit libraries (c libraries) on RHEL 8.2 and I > could not find the rpms in the installation DVD iso. Yum queries only shows > .s390x. RHEL 6.9 came with both *.s390.rpm (32 bit ) and *.s390x.rpm (64 bit) > rpms on the disk. As per RedHat 32 bit applications are supported in RHEL 7 > and 8. I have opened a ticket with RedHat to get this information. I would > like to know if anyone on the list already figured it out. > > > Thank you, > Ashwin Bhemidhi > > > -- > 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
Thanks Andreas, The problem is there is a bug in WAS when DFLTCC is used - Assessment by Java Development is that Wells Fargo's symptoms line up to be the same issue as experienced by another client several days earlier. In the first client's case, they were provided with an WAS Ifix (APAR PH27505) which prevents the endless looping that occurs when the JVM API does not report that the compressed data stream has reached the end. The client tested the WAS iFix and confirmed that it does prevent the endless looping during decompression. The current recommendation is for z15 zLinux clients running JAVA8 SR6 is to apply WAS APAR PH27505 and run with HW compression disabled (DFLTCC=0). Wells Fargo has 2000 Linux guests they would have to patch to fix and were looking for an easy way to just disable. Regards, Bill ___ Bill Bitner - z/VM Client Focus and Care - 607-429-3286 bitn...@us.ibm.com "Making systems practical and profitable for customers through virtualization and its exploitation." - z/VM From: Andreas Krebbel To: LINUX-390@VM.MARIST.EDU Date: 07/22/2020 07:49 AM Subject:[EXTERNAL] Re: z15 on-board compression Sent by:Linux on 390 Port Hi, I wrote a post about how to build and test zlib also for distros currently not supported: https://urldefense.proofpoint.com/v2/url?u=http-3A__linux-2Don-2Dz.blogspot.com_2019_10_howto-2Dexploiting-2Dhardware-2Dcompression.html=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=5MoiGnRMsqjUxHq7C7RX4kthfAKqf40IRGxojgucrwA=x1vmZzvvtIGmEi8_Y7og3XDpzRz1wa5VLMnZ-0HDnMA=uQF9dwXC8luEMIVM-xxLnLikZ8q2yREoz_7unCt3O30= You will find a quick one-liner test at the end of the post which can be used to verify whether hardware compression works in your installation. Andreas On 10.06.20 01:36, Michael MacIsaac wrote: > Hello list, > > I heard about the new DFLTCC instruction on the z15, aka on board > compression. I tried a quick experiment to see the difference from a z14. > Disclaimer: I am not a performance expert.> > Here are three commands to create, compress and decompress a 1G file on a > z14: > > # grep Type: /proc/sysinfo > Type: 3906 > > # time dd if=/dev/zero of=1G.file bs=1G count=1 > 1+0 records in > 1+0 records out > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 21.93 s, 49.0 MB/s > > real0m22.047s > user0m0.001s > sys 0m3.669s > > # time cat 1G.file | gzip -c > 1G.compressed.file > > real0m7.603s > user0m5.362s > sys 0m0.789s > > # time cat 1G.compressed.file | gzip -d > 1G.file > > real0m24.833s > user0m4.103s > sys 0m1.845s > > Here's the same commands on z15: > > # grep Type: /proc/sysinfo > Type: 8561 > > # time dd if=/dev/zero of=1G.file bs=1G count=1 > 1+0 records in > 1+0 records out > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.59126 s, 675 MB/s > > real0m1.621s > user0m0.000s > sys 0m1.216s > > # time cat 1G.file | gzip -c > 1G.compressed.file > > real0m5.722s > user0m4.946s > sys 0m0.510s > # time cat 1G.compressed.file | gzip -d > 1G.file > > real0m6.150s > user0m3.922s > sys 0m1.290s > > Wow more than 10x faster on dd - was not expecting that as I didn't think > it uses compression. But the compress with gzip -c, was only 25% faster on > the z15 while the decompress was about 4x. > > Are these results expected? > > Thanks. > > > -- > -Mike MacIsaac > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > https://urldefense.proofpoint.com/v2/url?u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=5MoiGnRMsqjUxHq7C7RX4kthfAKqf40IRGxojgucrwA=x1vmZzvvtIGmEi8_Y7og3XDpzRz1wa5VLMnZ-0HDnMA=FQsLX2gZ60YhLotQ1szspOspNp8arGQloNna6pa4DhI= > -- 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=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=5MoiGnRMsqjUxHq7C7RX4kthfAKqf40IRGxojgucrwA=x1vmZzvvtIGmEi8_Y7og3XDpzRz1wa5VLMnZ-0HDnMA=FQsLX2gZ60YhLotQ1szspOspNp8arGQloNna6pa4DhI= -- 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
Hi, I wrote a post about how to build and test zlib also for distros currently not supported: http://linux-on-z.blogspot.com/2019/10/howto-exploiting-hardware-compression.html You will find a quick one-liner test at the end of the post which can be used to verify whether hardware compression works in your installation. Andreas On 10.06.20 01:36, Michael MacIsaac wrote: > Hello list, > > I heard about the new DFLTCC instruction on the z15, aka on board > compression. I tried a quick experiment to see the difference from a z14. > Disclaimer: I am not a performance expert.> > Here are three commands to create, compress and decompress a 1G file on a > z14: > > # grep Type: /proc/sysinfo > Type: 3906 > > # time dd if=/dev/zero of=1G.file bs=1G count=1 > 1+0 records in > 1+0 records out > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 21.93 s, 49.0 MB/s > > real0m22.047s > user0m0.001s > sys 0m3.669s > > # time cat 1G.file | gzip -c > 1G.compressed.file > > real0m7.603s > user0m5.362s > sys 0m0.789s > > # time cat 1G.compressed.file | gzip -d > 1G.file > > real0m24.833s > user0m4.103s > sys 0m1.845s > > Here's the same commands on z15: > > # grep Type: /proc/sysinfo > Type: 8561 > > # time dd if=/dev/zero of=1G.file bs=1G count=1 > 1+0 records in > 1+0 records out > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.59126 s, 675 MB/s > > real0m1.621s > user0m0.000s > sys 0m1.216s > > # time cat 1G.file | gzip -c > 1G.compressed.file > > real0m5.722s > user0m4.946s > sys 0m0.510s > # time cat 1G.compressed.file | gzip -d > 1G.file > > real0m6.150s > user0m3.922s > sys 0m1.290s > > Wow more than 10x faster on dd - was not expecting that as I didn't think > it uses compression. But the compress with gzip -c, was only 25% faster on > the z15 while the decompress was about 4x. > > Are these results expected? > > Thanks. > > > -- > -Mike MacIsaac > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www2.marist.edu/htbin/wlvindex?LINUX-390 > -- 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: z/15 and SLES 11SP4
On 21.07.20 23:40, Victor Echavarry wrote: > Does anybody has an IBM z/15 running z/Linux SLES 11 SP4 > kernel-default-3.0.101-108.87.1? we are in a middle of migration from SLES 11 > to 12 that supposed to finish at the end of year. Our company buy a z/15 and > we want to know is the SLES 11 runs on the z/15 to finish the migration. The combination of distros and hardware that was tested by IBM and/or the distribution parter can be found here https://www.ibm.com/it-infrastructure/z/os/linux-tested-platforms. As you can see SLES11 was not tested with z15. Reason was that SLES11 was already end of life (march 2019) when z15 went GA (see https://www.suse.com/lifecycle/) and only extended support contracts are available. FWIW, if the planned software already supports SLES15, I would encourage you to switch to SLES15SP2 instead of SLES12. EOL for SLES12 is 2024 and EOL for SLES15 is 2028. But you need to double check that all dependencies are available for SLES15. -- 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: z/15 and SLES 11SP4
On 7/21/20 5:40 PM, Victor Echavarry wrote: > Does anybody has an IBM z/15 running z/Linux SLES 11 SP4 > kernel-default-3.0.101-108.87.1? we are in a middle of migration from SLES 11 > to 12 that supposed to finish at the end of year. Our company buy a z/15 and > we want to know is the SLES 11 runs on the z/15 to finish the migration. SUSE does not have a z15, so we are not able to test that combination. Personally, I wouldn't risk trying 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
