zKVM on zpdt

[Tito Garrido]

Hi Folks,

  I have already asked this question on z1090 mail list but it may be
interesting for other people here that would like to try zKVM and also you
may know the answer :)


I am trying to install zKVM on zpdt but it is not able to run dasdfmt
during the installation:


2015-10-02 02:13:15,704 - program - INFO - Running... /sbin/dasdfmt -y -d
cdl -b 4096 /dev/dasda
2015-10-02 02:13:15,734 - program - INFO - /sbin/dasdfmt: (invalidate first
track) IOCTL BIODASDFMT failed. (Input/output error)

Any clue?

I have already tried to run CPFMTXA on a z/VM instance and run the
installation again but no success...



Regards,
Tito

-- 

Linux User #387870
.
 _/_õ|__|
..º[ .-.___.-._| . . . .
.__( o)__( o).:___

--
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: Getting kernel.img and initrd.img for RHEl 7.1

[Chu, Raymond]

Paul,

Yes  I found it.

Thanks,

Ray

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Paul 
Dembry
Sent: Wednesday, September 30, 2015 8:44 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Getting kernel.img and initrd.img for RHEl 7.1

Email sent from outside of PSEG. Use caution before using links/attachments.


Should be under the images directory of the ISO file.
Paul


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Chu, 
Raymond
Sent: Wednesday, September 30, 2015 5:28 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Getting kernel.img and initrd.img for RHEl 7.1

Hi,

I am planning to install Red Hat 7.1 on z/VM 6.3. Would like to know site or 
link to get kernel.img and initrd.img for Red Hat 7.1.


Thanks,

Ray

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/


-
The information contained in this e-mail, including any attachment(s), is 
intended solely for use by the named addressee(s).  If you are not the intended 
recipient, or a person designated as responsible for delivering such messages 
to the intended recipient, you are not authorized to disclose, copy, distribute 
or retain this message, in whole or in part, without written authorization from 
PSEG.  This e-mail may contain proprietary, confidential or privileged 
information. If you have received this message in error, please notify the 
sender immediately. This notice is included in all e-mail messages leaving 
PSEG.  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: Getting kernel.img and initrd.img for RHEl 7.1 - bootstrap version

[Chu, Raymond]

Let me correct myself. 

What I found was a full version of kernel.img and initrd.img for Red Hat 7.1. 
What I am looking for is a bootstrap version of kernel.img and initrd.img for 
Red Hat 7.1. Therefore, they are small enough to be uploaded to LNXMAINT.192. 



-Original Message-
From: Chu, Raymond 
Sent: Friday, October 02, 2015 7:58 AM
To: LINUX-390@VM.MARIST.EDU
Subject: RE: Getting kernel.img and initrd.img for RHEl 7.1

Paul,

Yes  I found it.

Thanks,

Ray

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Paul 
Dembry
Sent: Wednesday, September 30, 2015 8:44 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Getting kernel.img and initrd.img for RHEl 7.1

Email sent from outside of PSEG. Use caution before using links/attachments.


Should be under the images directory of the ISO file.
Paul


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Chu, 
Raymond
Sent: Wednesday, September 30, 2015 5:28 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Getting kernel.img and initrd.img for RHEl 7.1

Hi,

I am planning to install Red Hat 7.1 on z/VM 6.3. Would like to know site or 
link to get kernel.img and initrd.img for Red Hat 7.1.


Thanks,

Ray

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/


-
The information contained in this e-mail, including any attachment(s), is 
intended solely for use by the named addressee(s).  If you are not the intended 
recipient, or a person designated as responsible for delivering such messages 
to the intended recipient, you are not authorized to disclose, copy, distribute 
or retain this message, in whole or in part, without written authorization from 
PSEG.  This e-mail may contain proprietary, confidential or privileged 
information. If you have received this message in error, please notify the 
sender immediately. This notice is included in all e-mail messages leaving 
PSEG.  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: zKVM on zpdt

[Tito Garrido]

FYI: To make it work I had to format the dasds on an older Linux like RHEL6.

On Fri, Oct 2, 2015 at 10:47 AM, Tito Garrido  wrote:

> Hi Folks,
>
>   I have already asked this question on z1090 mail list but it may be
> interesting for other people here that would like to try zKVM and also you
> may know the answer :)
>
>
> I am trying to install zKVM on zpdt but it is not able to run dasdfmt
> during the installation:
>
>
> 2015-10-02 02:13:15,704 - program - INFO - Running... /sbin/dasdfmt -y -d
> cdl -b 4096 /dev/dasda
> 2015-10-02 02:13:15,734 - program - INFO - /sbin/dasdfmt: (invalidate
> first track) IOCTL BIODASDFMT failed. (Input/output error)
>
> Any clue?
>
> I have already tried to run CPFMTXA on a z/VM instance and run the
> installation again but no success...
>
>
>
> Regards,
> Tito
>
> --
>
> Linux User #387870
> .
>  _/_õ|__|
> ..º[ .-.___.-._| . . . .
> .__( o)__( o).:___
>



-- 

Linux User #387870
.
 _/_õ|__|
..º[ .-.___.-._| . . . .
.__( o)__( o).:___

--
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: Getting kernel.img and initrd.img for RHEl 7.1 - bootstrap version

[Rick Troth]

On 10/02/2015 12:28 PM, Chu, Raymond wrote:
> What I found was a full version of kernel.img and initrd.img
> for Red Hat 7.1. What I am looking for is a bootstrap version of
> kernel.img and initrd.img for Red Hat 7.1. Therefore, they are
> small enough to be uploaded to LNXMAINT.192.

I cobbled-up an EXEC to pull the kernel and INITRD from the web.
Have used this to bootstrap Debian and Fedora and NORD (home grown).
Based on the disk constraints you mention, it might help.

Rationale: I got tired of having to stage these files to minidisk
(or SFS) and then punch them as a separate step. Since they are
commonly available on the web, and would be using a URL anyway,
it seemed to make sense to cut to the chase and go URL to spool.
Works.

You'll need the following ...

   http://ltroth1.casita.net/nord/curl.rexx
   http://ltroth1.casita.net/nord/nordauto.exec
   http://ltroth1.casita.net/nord/sample.nordauto

Tailor the last one, rename it to match your VM ID.

The downside is that some of the hosting sites are s-l-o-w.
(So I might should add an option "hold a copy for re-use".)
But today it's just URL-to-punch.

-- R; <><

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Getting kernel.img and initrd.img for RHEl 7.1 - bootstrap version

[Mark Post]

>>> On 10/2/2015 at 12:28 PM, "Chu, Raymond"  wrote: 
> Let me correct myself. 
> 
> What I found was a full version of kernel.img and initrd.img for Red Hat 
> 7.1. What I am looking for is a bootstrap version of kernel.img and 
> initrd.img for Red Hat 7.1. Therefore, they are small enough to be uploaded 
> to LNXMAINT.192. 

initrd.img at 26347136 bytes and kernel.img at 3749376 bytes are the ones you 
want.  26M and 3.6M, respectively.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Getting kernel.img and initrd.img for RHEl 7.1 - bootstrap version

[Chu, Raymond]

Mark, 

No they are no big at all.  My LNXMAINT.192 is sized for 350 MB and has plenty 
of space left.

When I ftped the first time, I got the errors like

ftp> put RH71.initrd.img  RH71.INITRD
200 Port request OK.
150 Storing file 'RH71.INITRD'
451 Data transfer aborted: record too long


That was the reason that I generated the email thread. 

After your response. I did another ftping and this time worked

ftp> QUOTE SITE FIX 80
200 Site command was accepted.
200 Representation type is IMAGE.
ftp> put RH71.initrd.img RH71.INITRD
200 Port request OK.
150 Storing file 'RH71.INITRD'
250 Transfer completed successfully.
ftp: 26347136 bytes sent in Seconds .xKbytes/sec.
ftp> put RH71.kernel.img RH71.KERNEL
200 Port request OK.
150 Storing file 'RH71.KERNEL'
250 Transfer completed successfully.
ftp: 3749376 bytes sent in x.xxSeconds .xKbytes/sec.
ftp> QUIT

I further checked the LNXMAINT.192 and they are there as expected.

RH71 KERNEL   D1 F 80  46868900 
RH71 INITRD   D1 F 80 329340   6433
RHEL65   KERNEL   D1 F 80 113594   1752
RHEL65   INITRD   D1 F 80 234521   4581

I believe I am alrght now. Thanks for all you assistance.

Ray



-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Friday, October 02, 2015 12:51 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Getting kernel.img and initrd.img for RHEl 7.1 - bootstrap version

Email sent from outside of PSEG. Use caution before using links/attachments.

>>> On 10/2/2015 at 12:28 PM, "Chu, Raymond"  wrote: 
> Let me correct myself. 
> 
> What I found was a full version of kernel.img and initrd.img for Red 
> Hat 7.1. What I am looking for is a bootstrap version of kernel.img 
> and initrd.img for Red Hat 7.1. Therefore, they are small enough to be 
> uploaded to LNXMAINT.192.

initrd.img at 26347136 bytes and kernel.img at 3749376 bytes are the ones you 
want.  26M and 3.6M, respectively.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/


-
The information contained in this e-mail, including any attachment(s), is 
intended solely for use by the named addressee(s).  If you are not the intended 
recipient, or a person designated as responsible for delivering such messages 
to the intended recipient, you are not authorized to disclose, copy, distribute 
or retain this message, in whole or in part, without written authorization from 
PSEG.  This e-mail may contain proprietary, confidential or privileged 
information. If you have received this message in error, please notify the 
sender immediately. This notice is included in all e-mail messages leaving 
PSEG.  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: zKVM on zpdt

[Mark Post]

>>> On 10/2/2015 at 12:29 PM, Tito Garrido  wrote: 
> FYI: To make it work I had to format the dasds on an older Linux like RHEL6.

Sounds like you may have found a bug in the zPDT code which should be reported 
to IBM.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES12 + EDEV + bug

[Mark Post]

>>> On 9/30/2015 at 10:59 PM, Grzegorz Powiedziuk  
>>> wrote: 
> I think I might have found a small bug in latest update for SLES12  so this 
> is just a FYI for everyone who made the same mistake I did. 
-snip- 
> Everything was working fine, until I did an update. Something has changed in 
> the way LVM recognizes physical  devices and it totally brakes the whole 
> system. It breaks all the parts where LVM is being called which includes the 
> little initrd which is loaded by  zipl during the first stage of boot. 

I was able to reproduce this situation.  I did an install, with /home on a PV 
using /dev/dasdb (an EDEV) and not /dev/dasdb1.  After updating to the current 
maintenance level, pvscan doesn't show any PVs out there.  There were a total 
of 259 updates that got applied.  I did the kernel first, since that's an easy 
one to isolate.  It didn't cause the problem.  So, not sure just yet what did.

> I did some debugging and I found that with latest update of SLES (I don*t 
> know why because the LVM seems to be in the same version) lvm doesn*t like 
> having metadata on *dasda* (fba) anymore. It likes it  only if its on dasda1 
> When pvscan scans the disk it ends up with:
>   /dev/dasda: Skipping: Partition table signature found 
> so it does not find the label and it fails to bring online the pv and volume 
> group. 

I haven't see that message at all.  I just get nothing back.

-snip-
> So the lesson is to make sure that SLES is being installed on dasda1 (fba) 
> not dasda   (only if you have edevices - with standard ECKDs  it*s probably 
> ok to do that) 

Oh no, absolutely not.  For anything named /dev/dasd? use the partition(s), 
rather than try to remember what the exceptions are that might work.

> If you already have it on dasda  (FBA) - don*t update it without 
> preparations. 
> 
> Perhaps SLES shouldn*t allow to install a system this way at all?

You wouldn't believe how complex it is to try and figure out what block devices 
are what, which to use, what ones have the "fake" partition tables the DASD 
driver creates, what's virtual (VDISKs look just like 9336 devices also), what 
not, etc.  Totally stinks.  Looking back, it would have been much better in the 
long wrong for those imaginary partition tables to never have been used, but 
here we are.

As Rick suggested, if you don't have a support request open with your support 
provider, do so as soon as possible.  It's clear that something changed between 
SLES12 GA and now, and we clearly don't have an automated QA test for this 
situation, or whatever update caused it would never have made it out the door.  
Even if we wind up sticking with the current behavior, that's something that 
will have to be managed carefully so that other customers don't encounter 
problems.

Finally, thank you for the work you've done already.  Nice job on behalf of the 
rest of the community, to say the least.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES12 + EDEV + bug

[Grzegorz Powiedziuk]

> On Oct 2, 2015, at 8:15 PM, Mark Post  wrote:
> 
 On 9/30/2015 at 10:59 PM, Grzegorz Powiedziuk  
 wrote: 
>> I think I might have found a small bug in latest update for SLES12  so this 
>> is just a FYI for everyone who made the same mistake I did. 
> -snip- 
>> Everything was working fine, until I did an update. Something has changed in 
>> the way LVM recognizes physical  devices and it totally brakes the whole 
>> system. It breaks all the parts where LVM is being called which includes the 
>> little initrd which is loaded by  zipl during the first stage of boot. 
> 
> I was able to reproduce this situation.  I did an install, with /home on a PV 
> using /dev/dasdb (an EDEV) and not /dev/dasdb1.  After updating to the 
> current maintenance level, pvscan doesn't show any PVs out there.  There were 
> a total of 259 updates that got applied.  I did the kernel first, since 
> that's an easy one to isolate.  It didn't cause the problem.  So, not sure 
> just yet what did.
> 
>> I did some debugging and I found that with latest update of SLES (I don*t 
>> know why because the LVM seems to be in the same version) lvm doesn*t like 
>> having metadata on *dasda* (fba) anymore. It likes it  only if its on dasda1 
>> When pvscan scans the disk it ends up with:
>>  /dev/dasda: Skipping: Partition table signature found 
>> so it does not find the label and it fails to bring online the pv and volume 
>> group. 
> 
> I haven't see that message at all.  I just get nothing back.

Mark, that message shows up only if you use pvscan or pvck with verbose. Which 
of course does not happen if you are just booting. To dig out that message I’ve 
linked that disk to another working updated version of SLES (installed on 
dasda1) and run the pvscan -vvv over there. 

But if you wait long enough during the boot, it should bring up dracut rescue 
console eventually (few minutes). And I believe that over there,  you can run 
“lvm pvscan /dev/dasda -vvv” over there and you should get that message as 
well. And that’s why it fails to boot. Dracut  (with lvm pvscan command) scans 
all devices so it cat put together volume group and it just skips this disk so 
it ends up with nothing. No root volume. 

> 
> You wouldn't believe how complex it is to try and figure out what block 
> devices are what, which to use, what ones have the "fake" partition tables 
> the DASD driver creates, what's virtual (VDISKs look just like 9336 devices 
> also), what not, etc.  Totally stinks.  Looking back, it would have been much 
> better in the long wrong for those imaginary partition tables to never have 
> been used, but here we are.
> 

> As Rick suggested, if you don't have a support request open with your support 
> provider, do so as soon as possible.  It's clear that something changed 
> between SLES12 GA and now, and we clearly don't have an automated QA test for 
> this situation, or whatever update caused it would never have made it out the 
> door.  Even if we wind up sticking with the current behavior, that's 
> something that will have to be managed carefully so that other customers 
> don't encounter problems.
> 

I will see if I can do it. I don’t have the SLES12 license - I’ve just 
downloaded the 60 days trial. So I am not sure If I even have option to open 
support requests. 

> Finally, thank you for the work you've done already.  Nice job on behalf of 
> the rest of the community, to say the least.
> 

Ahh no problem. I enjoy doing that kind of stuff. That’s not work for me ;) 

Gregory Powiedziuk
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES12 + EDEV + bug

[Grzegorz Powiedziuk]

> On Oct 2, 2015, at 10:38 PM, Grzegorz Powiedziuk  
> wrote:
> 
>> 
>> On Oct 2, 2015, at 8:15 PM, Mark Post  wrote:
>> 
> On 9/30/2015 at 10:59 PM, Grzegorz Powiedziuk  
> wrote: 
>>> I think I might have found a small bug in latest update for SLES12  so this 
>>> is just a FYI for everyone who made the same mistake I did. 
>> -snip- 
>>> Everything was working fine, until I did an update. Something has changed 
>>> in 
>>> the way LVM recognizes physical  devices and it totally brakes the whole 
>>> system. It breaks all the parts where LVM is being called which includes 
>>> the 
>>> little initrd which is loaded by  zipl during the first stage of boot. 
>> 
>> I was able to reproduce this situation.  I did an install, with /home on a 
>> PV using /dev/dasdb (an EDEV) and not /dev/dasdb1. After updating to the 
>> current maintenance level, pvscan doesn't show any PVs out there.  There 
>> were a total of 259 updates that got applied.  I did the kernel first, since 
>> that's an easy one to isolate.  It didn't cause the problem.  So, not sure 
>> just yet what did.

I did more playing around and I found out that that LVM source I’ve downloaded 
is working fine out from box. These changes I made to the source code were not 
necessary. 
SLES version of LVM has to have some changes. 


So I’ve checked what was installed with latest update for LVM and here it is (I 
guess I should have done it on the first place) :

patch: SUSE-SLE-SERVER-12-2015-314
- LVM2 does not support unpartitioned DASD device which has special 

   │
 │  format in the first 2 tracks and will silently discard LVM2 label   

 │
 │  information written to it by pvcreate. Mark this type of device as  

 │
 │  unsupported. (bsc#894202)

and from suse.com
Skip unpartitioned DASD devices, they are not supported. (bsc#894202)

I guess that’s it. They wanted to fix things If I understand this correctly but 
this might put in danger some users with older versions. 

Thanks
Gregory Powiedziuk







--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES12 + EDEV + bug

[Grzegorz Powiedziuk]

> I did more playing around and I found out that that LVM source I’ve 
> downloaded is working fine out from box. These changes I made to the source 
> code were not necessary. 
> SLES version of LVM has to have some changes. 
> 
> 
> So I’ve checked what was installed with latest update for LVM and here it is 
> (I guess I should have done it on the first place) :
> 
> patch: SUSE-SLE-SERVER-12-2015-314
> - LVM2 does not support unpartitioned DASD device which has special   
>   
>│
>  │  format in the first 2 tracks and will silently discard LVM2 label 
>   
>  │
>  │  information written to it by pvcreate. Mark this type of device as
>   
>  │
>  │  unsupported. (bsc#894202)
> 
> and from suse.com 
> Skip unpartitioned DASD devices, they are not supported. (bsc#894202)
> 
> I guess that’s it. They wanted to fix things If I understand this correctly 
> but this might put in danger some users with older versions. 
> 
> Thanks
> Gregory Powiedziuk

They probably  wanted to change it only for pvcreate so it would be possible to 
create lvms only on partitioned disks. But doing this change in a shared 
function, they crippled also pvscan so using lvms already existing on a not 
partitioned devices became impossible. 

Gregory Powiedziuk



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