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

[Aria Bamdad]

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

Re: Warning if upgrading SLES12 to SLES15 SP3

[Aria Bamdad]

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 /etc/udev/rules.d, e.g.

  /etc/udev/rules.d/99-dasd-link-prio.rules

How this rule works:

1. ACTION=="add|change"
   If a new device was registered, or an existing one was modified
2. KERNEL=="dasd*"
   and the device node name starts with "dasd"
3. ENV{DEVTYPE}=="partition"
   and the device type is a partition
4. ENV{ID_PATH}=="ccw-0.0.2000"
   and the device ID path that includes the device number matches
   the specified value "ccw-0.0.2000"
5. OPTIONS="link_priority=-1"
   then assign a link-priority value of -1 which is lower than the
   default value of 0

In our example setup, the rule will match the udev change events
generated when modifying the label for the file system on device dasdc1
(device number 2000), and assign a 

Re: Warning if upgrading SLES12 to SLES15 SP3

[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 /etc/udev/rules.d, e.g.

  /etc/udev/rules.d/99-dasd-link-prio.rules

How this rule works:

1. ACTION=="add|change"
   If a new device was registered, or an existing one was modified
2. KERNEL=="dasd*"
   and the device node name starts with "dasd"
3. ENV{DEVTYPE}=="partition"
   and the device type is a partition
4. ENV{ID_PATH}=="ccw-0.0.2000"
   and the device ID path that includes the device number matches
   the specified value "ccw-0.0.2000"
5. OPTIONS="link_priority=-1"
   then assign a link-priority value of -1 which is lower than the
   default value of 0

In our example setup, the rule will match the udev change events
generated when modifying the label for the file system on device dasdc1
(device number 2000), and assign a lower-than-default priority of -1 to
it. As a result if you repeat the sequence from before, you'll find that
the symlink for dasdb1 is no longer overwritten:

$ e2label /dev/dasdb1 test2
$ readlink /dev/disk/by-label/test2
../../dasdb1
$ e2label /dev/dasdc1 test2
$ readlink /dev/disk/by-label/test2
../../dasdb1

The consumability of writing udev rules is of course limited, but the
flexibility of the concept might allow to work around the issues you
mentioned in specific setups.

> Interestingly, at boot time, if you have two devices that have the
> same UUID (as in above) only the first 

Re: Warning if upgrading SLES12 to SLES15 SP3

[Mark Post]

On 10/8/21 2:10 PM, Alan Altmark wrote:

The UUID only needs to be unique within a virtual server.  I think the
trick here is to use a cloning guest that links to the disk you want to
clone so that the UUID is never duplicated within the owning guest.  The
cloning guest will have two copies, but it will never use those disks
itself.

This avoids having to assign new UUIDs.


Perhaps, but it's still a good idea to make each clone unique. If you 
ever need to link to another guest's disks, then duplicate UUIDs are 
going to cause problems. And really, adding:


tune2fs -U $(uuidgen) /dev/dasd??

to your cloning script is pretty straightforward.

I would also recommend not using chzdev when cloning disks and 
manipulating them. Instead, use chccwdev, which doesn't cause any udev 
rules to be written to deleted. The chzdev and lszdev commands are 
really nice commands, but they are also more capable, and hence complex, 
than what is needed during cloning. Use chzdev/lszdev for "normal" 
system administration tasks where you actually want those udev rules to 
be written/deleted.



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

[Cohen, Sam]

Why not just change references from /dev/disk/by-uuid to /dev/disk/by-path, 
such as in /etc/fstab and /boot/zipl/config  ?  Wouldn't that be easier in the 
long run?

Thanks,

Sam

-Original Message-
From: Linux on 390 Port  On Behalf Of Aria Bamdad
Sent: Friday, October 8, 2021 12:09
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Warning if upgrading SLES12 to SLES15 SP3

Quoting Mark Post :

> On 10/8/21 2:10 PM, Alan Altmark wrote:
>> The UUID only needs to be unique within a virtual server.  I think 
>> the trick here is to use a cloning guest that links to the disk you 
>> want to clone so that the UUID is never duplicated within the owning 
>> guest.  The cloning guest will have two copies, but it will never use 
>> those disks itself.
>>
>> This avoids having to assign new UUIDs.
>
> Perhaps, but it's still a good idea to make each clone unique. If you 
> ever need to link to another guest's disks, then duplicate UUIDs are 
> going to cause problems. And really, adding:
>
> tune2fs -U $(uuidgen) /dev/dasd??
>
> to your cloning script is pretty straightforward.
>


I clone my disks using falashcopy so outside of linux.  This would mean that 
after flashcopy, I would need to mount the disks on a utility linux server and 
change the UUID of each disk using tune2fs.
That's fine and can be done.



> I would also recommend not using chzdev when cloning disks and 
> manipulating them. Instead, use chccwdev, which doesn't cause any udev 
> rules to be written to deleted. The chzdev and lszdev commands are 
> really nice commands, but they are also more capable, and hence 
> complex, than what is needed during cloning. Use chzdev/lszdev for "normal"
> system administration tasks where you actually want those udev rules 
> to be written/deleted.
>
>

Yes, that would likely avoid all of the problems.  However, in my case, I was 
in Yast and figured I will just activate a DASD using Yast menu.  SLES12 Yast 
would call chccwdev but later versions and SLES15 now call chzdev.  Had chzdev 
issued a message that the disk I am trying to activate has a UUID that 
conflicts with an existing disk that is currently activated, the entire problem 
would have been
avoided.  Instead it allows you to activate the disk.   To make
matters worse, while you are in Yast still, you no longer can deactivate the 
disk you just activated a second ago.  Why?  Because chzdev complains and yast 
will not continue.  If we had the same complaint during activation of the disk, 
problem would have been avoided.

Mark, your suggestion of using chccwdev is the right one.  We can use chccwdev 
to online the device, mount it, fix the uuid and unmount/offline the device.

Thanks,
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://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.
> marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390data=04%7C01%7CSam.Cohen
> %40LRS.COM%7Cc99ab9efc4f144d5ebaa08d98a8f568c%7C62af9ccc42164ae2a1d306
> 614c59c315%7C1%7C0%7C637693170518903788%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> p;sdata=zc6faPNuqKiwmvWNxcGYwydyagoJWC4%2FXerg%2FEhP4FY%3Dreserve
> d=0

--
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=04%7C01%7CSam.Cohen%40LRS.COM%7Cc99ab9efc4f144d5ebaa08d98a8f568c%7C62af9ccc42164ae2a1d306614c59c315%7C1%7C0%7C637693170518903788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=zc6faPNuqKiwmvWNxcGYwydyagoJWC4%2FXerg%2FEhP4FY%3Dreserved=0

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

Re: Warning if upgrading SLES12 to SLES15 SP3

[Aria Bamdad]

Quoting Mark Post :


On 10/8/21 2:10 PM, Alan Altmark wrote:

The UUID only needs to be unique within a virtual server.  I think the
trick here is to use a cloning guest that links to the disk you want to
clone so that the UUID is never duplicated within the owning guest.  The
cloning guest will have two copies, but it will never use those disks
itself.

This avoids having to assign new UUIDs.


Perhaps, but it's still a good idea to make each clone unique. If you
ever need to link to another guest's disks, then duplicate UUIDs are
going to cause problems. And really, adding:

tune2fs -U $(uuidgen) /dev/dasd??

to your cloning script is pretty straightforward.




I clone my disks using falashcopy so outside of linux.  This would
mean that after flashcopy, I would need to mount the disks on a
utility linux server and change the UUID of each disk using tune2fs.
That's fine and can be done.




I would also recommend not using chzdev when cloning disks and
manipulating them. Instead, use chccwdev, which doesn't cause any udev
rules to be written to deleted. The chzdev and lszdev commands are
really nice commands, but they are also more capable, and hence complex,
than what is needed during cloning. Use chzdev/lszdev for "normal"
system administration tasks where you actually want those udev rules to
be written/deleted.




Yes, that would likely avoid all of the problems.  However, in my
case, I was in Yast and figured I will just activate a DASD using Yast
menu.  SLES12 Yast would call chccwdev but later versions and SLES15
now call chzdev.  Had chzdev issued a message that the disk I am
trying to activate has a UUID that conflicts with an existing disk
that is currently activated, the entire problem would have been
avoided.  Instead it allows you to activate the disk.   To make
matters worse, while you are in Yast still, you no longer can
deactivate the disk you just activated a second ago.  Why?  Because
chzdev complains and yast will not continue.  If we had the same
complaint during activation of the disk, problem would have been
avoided.

Mark, your suggestion of using chccwdev is the right one.  We can use
chccwdev to online the device, mount it, fix the uuid and
unmount/offline the device.

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

[Alan Altmark]

On Friday, 10/08/2021 at 04:08 GMT, "Aria Bamdad"  
wrote:
> I think moving forward, I will implement a procedure to change the
> disk UUIDs after cloning.  I don't see this mentioned in any of the
> past cookbooks but feel it is a prudent thing to do.

The UUID only needs to be unique within a virtual server.  I think the 
trick here is to use a cloning guest that links to the disk you want to 
clone so that the UUID is never duplicated within the owning guest.  The 
cloning guest will have two copies, but it will never use those disks 
itself.

This avoids having to assign new UUIDs.

Alan Altmark

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


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

Re: Warning if upgrading SLES12 to SLES15 SP3

[Aria Bamdad]

Quoting Peter Oberparleiter :

Peter, thank you for your excellent analysis and clarification of how
this works. It now makes perfect sense to me.  Based on your comments,
I have a few questions/comments:




The moment that you enable the cloned disk in Linux, the system is in an
inconsistent state. You will find that persistent block device links in
/dev/disk/by-id, by-uuid and potentially by-label immediately point to
the cloned device. Any operation that relies on a correct association of
these persistent block device links will not perform correctly. This
includes a rebuild of the initial RAM-disk via dracut.



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

Interestingly, at boot time, if you have two devices that have the
same UUID (as in above) only the first device will end up having a
by-uuid link created.  Apparently, at boot, when the second device is
created, it does not cause the by-uuid link of the first device to get
replaced.  This is assuming they second device is not created first
and then the first but I don't know how I can tell.




dracut tries to determine the device number and persistent ID of the
block device that provides the root file system and stores the result
inside the initial RAM-disk. Since the persistent links are incorrect,
the wrong data is used during boot, even if the cloned disk is removed.



This makes perfect sense now.  I somehow think it is unlikely we can
get dracut developers to change this behavior or at least check for
it.  Since on z/VM we do a lot of cloning of disks/severs, I think we
may have a lot of disks lurking around with matching UUIDs.  That's
why I thought a message or change in behavior for chzdev would be
helpful.  Or by not creating the by-uuid links, we can still allow
access to the device but not create confusion for dracut and other
utilities that reference disks by uuid.



The evaluation of file system UUIDs by chzdev was specifically added to
support correct handling of multi-disk btrfs file systems. Also given
that a file system UUID is supposed to uniquely identify a file system,
I don't consider the current behavior a problem in chzdev.



I think moving forward, I will implement a procedure to change the
disk UUIDs after cloning.  I don't see this mentioned in any of the
past cookbooks but feel it is a prudent thing to do.

Thank you again for your input.

Aria




Regards,
  Peter

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

Re: Warning if upgrading SLES12 to SLES15 SP3

[Peter Oberparleiter]

On 01.10.2021 22:20, Aria Bamdad wrote:
> Consider the following situation.  You have a Linux guest
> with root file system on device 150, usr on 151, var on 152.  Then you make
> a copy of these disk (DDR/flashcopy/Etc.), say you are cloning the guest.
> The copied disks are now called F50, F51 and F52 respectively.  Now consider
> that you boot from your normal 15x disks while you have the F5x disks linked
> and defined to the virtual machine.  Then you use chzdev command to enable
> any of the cloned disks, say F50 (clone of root). You can do this either
> using commands like chzdev or via Yast DASD tool to activate.  So far so
> good.  But if you then try to disable the same disk (F50) using chzdev (or
> Yast DASD), chzdev complains with:
>
> Warning: ECKD DASD 0.0.0f50 is in use!
>  The following resources may be affected:
>   - Mount point /
> Continue with operation? (yes/no)
>
> Well, it's neither in use (not mounted anywhere, just enabled), nor is it
> the root mount point.  The same will be true for F51 and F52.  Chzdev states
> that these are in use and mount points /usr and /var.  This does not happen
> when the disk is not a clone.
>
> Apparently, chzdev detects the partition UUID for each disk.  Since the F5x
> disks are clones of the 15x disks in active use, their UUID matches and
> apparently this confuses things.  If you simply change the UUID for the
> cloned disk, then this will not happen.

chzdev does indeed use the UUID of filesystems to detect the list of
mount points affected by a deconfigure operation. chzdev considers any
device with the same file system UUID to be affected, even if that
device is not directly mounted. This logic is required to handle btrfs
file systems located on multiple devices.

You can specify the --force option to the chzdev command to suppress
this kind of checking.

> Either the above problem, or something related or similar causes the grub2
> tools and/or Dracut to somehow get confused.

The moment that you enable the cloned disk in Linux, the system is in an
inconsistent state. You will find that persistent block device links in
/dev/disk/by-id, by-uuid and potentially by-label immediately point to
the cloned device. Any operation that relies on a correct association of
these persistent block device links will not perform correctly. This
includes a rebuild of the initial RAM-disk via dracut.

> So, if you happen to
> activate/enable a DASD that has the same UUID as one of your root file
> system disks, then by chance you were to run
> Dracut/grub2-mkconfig/grub2-install on your live system, then your system
> will fail to boot at the next reboot because it is trying to find one of the
> devices needed for boot (150,151) even though they are there.  The F5x
> device with identical UUID causes this failure.  It also doesn't matter if
> the F5x disk is present at the next boot or not.

dracut tries to determine the device number and persistent ID of the
block device that provides the root file system and stores the result
inside the initial RAM-disk. Since the persistent links are incorrect,
the wrong data is used during boot, even if the cloned disk is removed.

> I am hoping someone can shed some light on this.  I am not getting anywhere
> with SUSE and I feel that it is not unreasonable for the z/VM community to
> have cloned disks that have identical UUIDs on different servers. Grant it
> what I described above is not too likely of a scenario but still possible
> and it did happen to me.  I also don't every change the UUID of disks that I
> copy/clone.  Perhaps I should?

As mentioned above, activating multiple block devices with identical
file system UUIDs puts the system in an inconsistent state. This also
applies to duplicate file system labels and DASD volume labels as all of
these are expected to be unique. The problem will not become apparent
until the association of block devices with these IDs is evaluated, e.g.
by running dracut.

My suggestion would be to ensure that the time where multiple devices
with the same IDs are online is minimized. Care must be taken that the
inconsistent information is not evaluated. When running chzdev,
specifying the --no-root-update option can be used to suppress
rebuilding the initial RAM-disk.

The only alternative I see would be to change these IDs as part of the
cloning process, though this could require changes to a number of files
such as /etc/fstab and the kernel command line and will potentially
require rebuilding the initial RAM-disk in an isolated environment (chroot).

> Also, hopefully someone from IBM is listening here and can say whether the
> chzdev behavior is valid or not.  Note that you can take any disk, even an
> empty disk and as long as you change the UUID of the empty disk to match one
> of your active system disks UUID, you will have the same problems both with
> chzdev and boot issue.

The evaluation of file system UUIDs by chzdev was specifically added to
support correct 

Re: Warning if upgrading SLES12 to SLES15 SP3

[Aria Bamdad]

Thanks Rick.  Yes, I think chzdev should not be concerned about the UUIDs but 
it is possible that it needs to.  I can't say.

However, the problem with chzdev is something that can be dealt with easily.  
What is most concerning is that chzdev will at times prompt you to allow it to 
call mkinitrd and dracut if it senses you have changes something to do with the 
root device.  This is where the bigger problem exists.  If you allow chzdev to 
rebuild the initrd, then you have a serious problem because the system will 
fail to boot at the next boot because it is looking for devices that don't 
exist.  This is not a chzdev problem but a bug that has to do with dracut or 
mkinitrd itself I think.  

Here is how you can recreate the problem:


1-Define server 150 as root, 151 as /usr and 152 as /var  (anything will work 
but this is my setup)
2-Define temp disk as 159 (example 50 cyl tdisk or anything)
3-boot system
4-chccwdev --online 0.0.0159
5-lsdasd (to see which disk is the temp disk 159, dasdf for me)
6-dasdfmt -b 4096 /dev/dasdf
7-fdasd -a /dev/dasdf(auto-create a single partition on the test disk)
8-mkfs.ext4 /dev/dasdf1
9-blkid  (list current devices and UUIDs associated with them, then copy UUID 
for root device 150 for me)
10-tune2fs -U "f4aeb050-c56a-4d15-87af-99a64fdd7f1d" /dev/dasdf1   (set the 
temp disk UUID the same as the root device UUID)
11-blkid  (confirm the root and temp disk UUIDs are the same)
12-chzdev dasd 0159 --enable --persistent(make device persistent, then 
respond yes to update initrd)

ECKD DASD 0.0.0159 configured
Note: The initial RAM-disk must be updated for these changes to take effect:
   - ECKD DASD 0.0.0159
Update initial RAM-disk now? (yes/no) yes


13-Now reboot.  The system reboots and gets stuck at:

[  OK  ] Reached target Initrd Root Device.  

It's looking for a missing device now.  After about 2 minutes of nothing (low 
CPU utilization), you start seeing messages like this:

dracut-initqueue320Ù: Warning: dracut-initqueue timeout - starting timeout 
scripts

And then you are in emergency mode.  Here you can enter Dracut emergency shell 
or boot into a rescue system, mount the partitions, chroot, then 
mkinitrd/grub2-mkconfig/grub2-install to fix the boot problem but if you leave 
things as is, the next time you rebuild initrd on the system you will have the 
problem return.

Also, in the above steps, starting with step 12, I used chzdev to activate the 
disk. You can just as easily go into Yast, DASD, activate the disk (yast will 
call chzdev), then go into Yast, Bootloader and make a simple change (like the 
boot timeout delay) to force a new initrd to be created. Reboot and you  have a 
problem.

I think these two problems are unrelated.  I have not been able to get anyone 
at SUSE to listen.  I am hoping someone here will have more clout.

Thanks,
Aria


-Original Message-
From: Linux on 390 Port  On Behalf Of Rick Troth
Sent: Sunday, October 3, 2021 6:37 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Warning if upgrading SLES12 to SLES15 SP3

Aria has found a bug where 'chzdev' appears to be tripping over matching
UUIDs.
The closest relation to z/VM would be matching volsers, which can
certainly be confusing for z/VM when the CP Dir defines minidisks by
volser, but not so much when CP Dir defines minidisks by DEVNO.
Attaching to SYSTEM can still be konfoozing.
 
In this case, Linux should be following the I/O subsystems (subchannels,
paths, and devnos), not the UUIDs.
 
Logical Volume Manager can get confused when different (unrelated) PVs
claim to be part of the same volume group. Like when you copy a full set
of PVs. Suddenly you've got two strings representing, say, "sysvg1". How
does the system know *which* set of PVs to actually bring active when
you bring up volume group "sysvg1"?
 
I found that in a 'chroot' you can get away with it. (You can have, for
example, "sysvg1" active in the host *and* in the 'chroot', even though
they're backed by different PV sets. Scary, but works.)
 
The "mounted" flag is just another bit stamped on the media (or not).
Agreed, it's mo betta to copy when filesystems are not mounted. But the
flag itself could be false.
 
-- R; <><
 
 
On 10/3/21 11:10 AM, Aria Bamdad wrote:
> Thanks Alan.  In all cases, the cloning is done with server down so this is
> not caused because of that.  Also, note that I said all you have to do is
> format a test empty disk and then simply set the UUID of the disk to one of
> the existing OS disks, even when not mounted, it is seen as 'in use' by
> chzdev.
>
> I am not too concerned about the chzdev behavior but more concerned with the
> fact that having a disk around with identical UUID could cause boot problems
> if you were to make changes to boot options.
>
> Thanks,
> Aria
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Alan Altmark
> Sent

Re: Warning if upgrading SLES12 to SLES15 SP3

[Rick Troth]

Aria has found a bug where 'chzdev' appears to be tripping over matching
UUIDs.
The closest relation to z/VM would be matching volsers, which can
certainly be confusing for z/VM when the CP Dir defines minidisks by
volser, but not so much when CP Dir defines minidisks by DEVNO.
Attaching to SYSTEM can still be konfoozing.

In this case, Linux should be following the I/O subsystems (subchannels,
paths, and devnos), not the UUIDs.

Logical Volume Manager can get confused when different (unrelated) PVs
claim to be part of the same volume group. Like when you copy a full set
of PVs. Suddenly you've got two strings representing, say, "sysvg1". How
does the system know *which* set of PVs to actually bring active when
you bring up volume group "sysvg1"?

I found that in a 'chroot' you can get away with it. (You can have, for
example, "sysvg1" active in the host *and* in the 'chroot', even though
they're backed by different PV sets. Scary, but works.)

The "mounted" flag is just another bit stamped on the media (or not).
Agreed, it's mo betta to copy when filesystems are not mounted. But the
flag itself could be false.

-- R; <><


On 10/3/21 11:10 AM, Aria Bamdad wrote:
> Thanks Alan.  In all cases, the cloning is done with server down so this is
> not caused because of that.  Also, note that I said all you have to do is
> format a test empty disk and then simply set the UUID of the disk to one of
> the existing OS disks, even when not mounted, it is seen as 'in use' by
> chzdev.
>
> I am not too concerned about the chzdev behavior but more concerned with the
> fact that having a disk around with identical UUID could cause boot problems
> if you were to make changes to boot options.
>
> Thanks,
> Aria
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Alan Altmark
> Sent: Sunday, October 3, 2021 11:00 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Warning if upgrading SLES12 to SLES15 SP3
>
> On Friday, 10/01/2021 at 08:20 GMT, "Aria Bamdad" 
> wrote:
>> It seems that there may be a problem with the new s390-tools chzdev
> command
>> at the least.  Consider the following situation.  You have a Linux guest
>> with root file system on device 150, usr on 151, var on 152.  Then you
> make
>> a copy of these disk (DDR/flashcopy/Etc.), say you are cloning the
> guest.
>> The copied disks are now called F50, F51 and F52 respectively.  Now
> consider
>> that you boot from your normal 15x disks while you have the F5x disks
> linked
>> and defined to the virtual machine.  Then you use chzdev command to
> enable
>> any of the cloned disks, say F50 (clone of root). You can do this either
>> using commands like chzdev or via Yast DASD tool to activate.  So far so
>> good.  But if you then try to disable the same disk (F50) using chzdev
> (or
>> Yast DASD), chzdev complains with:
>>
>> Warning: ECKD DASD 0.0.0f50 is in use!
>> The following resources may be affected:
>> - Mount point /
>> Continue with operation? (yes/no)
>>
>> Well, it's neither in use (not mounted anywhere, just enabled), nor is
> it
>> the root mount point.  The same will be true for F51 and F52.  Chzdev
> states
>> that these are in use and mount points /usr and /var.  This does not
> happen
>> when the disk is not a clone.
> Traditionally the file systems mark the disks as 'in use' when they are
> mounted so that that message can be issued, among other things.
> Consequently, if you clone it while it's mounted, the clone will have the
> same marking and appear to be in use.  IMO, cloning should be done with
> the file system unmounted.
>
> Once the disk is cloned, it's no longer the same disk in terms of content,
> but if memory serves, the logical volume manager remembers UUIDs so that
> it can automatically form the logical volume.  If it were to see a desired
> UUID on a different disk, it could grab the wrong disk, resulting in a
> corrupted file system.  Timing is everything.
>
> If you're cloning and immediately giving it to a different server, then it
> wouldn't make any difference since the "universe" of UUIDs is limited to
> what the server has access to.
>
> 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

Re: Warning if upgrading SLES12 to SLES15 SP3

[Aria Bamdad]

Thanks Alan.  In all cases, the cloning is done with server down so this is
not caused because of that.  Also, note that I said all you have to do is
format a test empty disk and then simply set the UUID of the disk to one of
the existing OS disks, even when not mounted, it is seen as 'in use' by
chzdev.

I am not too concerned about the chzdev behavior but more concerned with the
fact that having a disk around with identical UUID could cause boot problems
if you were to make changes to boot options.

Thanks,
Aria

-Original Message-
From: Linux on 390 Port  On Behalf Of Alan Altmark
Sent: Sunday, October 3, 2021 11:00 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Warning if upgrading SLES12 to SLES15 SP3

On Friday, 10/01/2021 at 08:20 GMT, "Aria Bamdad" 
wrote:
> It seems that there may be a problem with the new s390-tools chzdev
command
> at the least.  Consider the following situation.  You have a Linux guest
> with root file system on device 150, usr on 151, var on 152.  Then you
make
> a copy of these disk (DDR/flashcopy/Etc.), say you are cloning the
guest.
> The copied disks are now called F50, F51 and F52 respectively.  Now
consider
> that you boot from your normal 15x disks while you have the F5x disks
linked
> and defined to the virtual machine.  Then you use chzdev command to
enable
> any of the cloned disks, say F50 (clone of root). You can do this either
> using commands like chzdev or via Yast DASD tool to activate.  So far so
> good.  But if you then try to disable the same disk (F50) using chzdev
(or
> Yast DASD), chzdev complains with:
>
> Warning: ECKD DASD 0.0.0f50 is in use!
> The following resources may be affected:
> - Mount point /
> Continue with operation? (yes/no)
>
> Well, it's neither in use (not mounted anywhere, just enabled), nor is
it
> the root mount point.  The same will be true for F51 and F52.  Chzdev
states
> that these are in use and mount points /usr and /var.  This does not
happen
> when the disk is not a clone.

Traditionally the file systems mark the disks as 'in use' when they are
mounted so that that message can be issued, among other things.
Consequently, if you clone it while it's mounted, the clone will have the
same marking and appear to be in use.  IMO, cloning should be done with
the file system unmounted.

Once the disk is cloned, it's no longer the same disk in terms of content,
but if memory serves, the logical volume manager remembers UUIDs so that
it can automatically form the logical volume.  If it were to see a desired
UUID on a different disk, it could grab the wrong disk, resulting in a
corrupted file system.  Timing is everything.

If you're cloning and immediately giving it to a different server, then it
wouldn't make any difference since the "universe" of UUIDs is limited to
what the server has access to.

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

[Alan Altmark]

On Friday, 10/01/2021 at 08:20 GMT, "Aria Bamdad"  
wrote:
> It seems that there may be a problem with the new s390-tools chzdev 
command
> at the least.  Consider the following situation.  You have a Linux guest
> with root file system on device 150, usr on 151, var on 152.  Then you 
make
> a copy of these disk (DDR/flashcopy/Etc.), say you are cloning the 
guest.
> The copied disks are now called F50, F51 and F52 respectively.  Now 
consider
> that you boot from your normal 15x disks while you have the F5x disks 
linked
> and defined to the virtual machine.  Then you use chzdev command to 
enable
> any of the cloned disks, say F50 (clone of root). You can do this either
> using commands like chzdev or via Yast DASD tool to activate.  So far so
> good.  But if you then try to disable the same disk (F50) using chzdev 
(or
> Yast DASD), chzdev complains with:
>
> Warning: ECKD DASD 0.0.0f50 is in use!
> The following resources may be affected:
> - Mount point /
> Continue with operation? (yes/no)
>
> Well, it's neither in use (not mounted anywhere, just enabled), nor is 
it
> the root mount point.  The same will be true for F51 and F52.  Chzdev 
states
> that these are in use and mount points /usr and /var.  This does not 
happen
> when the disk is not a clone.

Traditionally the file systems mark the disks as 'in use' when they are 
mounted so that that message can be issued, among other things. 
Consequently, if you clone it while it's mounted, the clone will have the 
same marking and appear to be in use.  IMO, cloning should be done with 
the file system unmounted.

Once the disk is cloned, it's no longer the same disk in terms of content, 
but if memory serves, the logical volume manager remembers UUIDs so that 
it can automatically form the logical volume.  If it were to see a desired 
UUID on a different disk, it could grab the wrong disk, resulting in a 
corrupted file system.  Timing is everything.

If you're cloning and immediately giving it to a different server, then it 
wouldn't make any difference since the "universe" of UUIDs is limited to 
what the server has access to.

Alan Altmark

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


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

Re: Warning if upgrading SLES12 to SLES15 SP3

[Aria Bamdad]

Yes, thank you Rick.  That's exactly how I confirmed it is the UUID.  In fact, 
I took an empty disk, formatted it as EXT4, then set it's UUID to the same as 
one of my primary file system's UUID and magically the problem reappeared!  
Didn't try with an XFS file system but you can also set the UUID in the same 
manner there so I think it will happen regardless of the filesystem type.

Aria


-Original Message-
From: Linux on 390 Port  On Behalf Of Rick Troth
Sent: Friday, October 1, 2021 5:29 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Warning if upgrading SLES12 to SLES15 SP3

What type of filesystem?
If EXT2,3,4 family, 'tune2fs' ellegedly lets you change the UUID.
 
 
 
On Fri, Oct 1, 2021, 16:20 Aria Bamdad  wrote:
 
> Hi all,
>
> Over a month has gone by since I reported this failing to boot issue (read
> below) to SUSE and so far, nothing.  They did say they found a problem with
> Dracut command but didn't say what.  So I decided to look closer and I
> think
> I have found something.  I suspect this is not limited to just upgrading
> from SLES12 to 15 and it affects all systems.
>
> It seems that there may be a problem with the new s390-tools chzdev command
> at the least.  Consider the following situation.  You have a Linux guest
> with root file system on device 150, usr on 151, var on 152.  Then you make
> a copy of these disk (DDR/flashcopy/Etc.), say you are cloning the guest.
> The copied disks are now called F50, F51 and F52 respectively.  Now
> consider
> that you boot from your normal 15x disks while you have the F5x disks
> linked
> and defined to the virtual machine.  Then you use chzdev command to enable
> any of the cloned disks, say F50 (clone of root). You can do this either
> using commands like chzdev or via Yast DASD tool to activate.  So far so
> good.  But if you then try to disable the same disk (F50) using chzdev (or
> Yast DASD), chzdev complains with:
>
> Warning: ECKD DASD 0.0.0f50 is in use!
>  The following resources may be affected:
>   - Mount point /
> Continue with operation? (yes/no)
>
> Well, it's neither in use (not mounted anywhere, just enabled), nor is it
> the root mount point.  The same will be true for F51 and F52.  Chzdev
> states
> that these are in use and mount points /usr and /var.  This does not happen
> when the disk is not a clone.
>
> Apparently, chzdev detects the partition UUID for each disk.  Since the F5x
> disks are clones of the 15x disks in active use, their UUID matches and
> apparently this confuses things.  If you simply change the UUID for the
> cloned disk, then this will not happen.
>
> Either the above problem, or something related or similar causes the grub2
> tools and/or Dracut to somehow get confused.  So, if you happen to
> activate/enable a DASD that has the same UUID as one of your root file
> system disks, then by chance you were to run
> Dracut/grub2-mkconfig/grub2-install on your live system, then your system
> will fail to boot at the next reboot because it is trying to find one of
> the
> devices needed for boot (150,151) even though they are there.  The F5x
> device with identical UUID causes this failure.  It also doesn't matter if
> the F5x disk is present at the next boot or not.
>
> I am hoping someone can shed some light on this.  I am not getting anywhere
> with SUSE and I feel that it is not unreasonable for the z/VM community to
> have cloned disks that have identical UUIDs on different servers. Grant it
> what I described above is not too likely of a scenario but still possible
> and it did happen to me.  I also don't every change the UUID of disks that
> I
> copy/clone.  Perhaps I should?
>
> Also, hopefully someone from IBM is listening here and can say whether the
> chzdev behavior is valid or not.  Note that you can take any disk, even an
> empty disk and as long as you change the UUID of the empty disk to match
> one
> of your active system disks UUID, you will have the same problems both with
> chzdev and boot issue.
>
> Thanks,
> Aria
>
>
>
>
>
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Marcy
> Cortes
> Sent: Thursday, August 19, 2021 6:35 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Warning if upgrading SLES12 to SLES15 SP3
>
> 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,

Re: Warning if upgrading SLES12 to SLES15 SP3

[Rick Troth]

What type of filesystem?
If EXT2,3,4 family, 'tune2fs' ellegedly lets you change the UUID.



On Fri, Oct 1, 2021, 16:20 Aria Bamdad  wrote:

> Hi all,
>
> Over a month has gone by since I reported this failing to boot issue (read
> below) to SUSE and so far, nothing.  They did say they found a problem with
> Dracut command but didn't say what.  So I decided to look closer and I
> think
> I have found something.  I suspect this is not limited to just upgrading
> from SLES12 to 15 and it affects all systems.
>
> It seems that there may be a problem with the new s390-tools chzdev command
> at the least.  Consider the following situation.  You have a Linux guest
> with root file system on device 150, usr on 151, var on 152.  Then you make
> a copy of these disk (DDR/flashcopy/Etc.), say you are cloning the guest.
> The copied disks are now called F50, F51 and F52 respectively.  Now
> consider
> that you boot from your normal 15x disks while you have the F5x disks
> linked
> and defined to the virtual machine.  Then you use chzdev command to enable
> any of the cloned disks, say F50 (clone of root). You can do this either
> using commands like chzdev or via Yast DASD tool to activate.  So far so
> good.  But if you then try to disable the same disk (F50) using chzdev (or
> Yast DASD), chzdev complains with:
>
> Warning: ECKD DASD 0.0.0f50 is in use!
>  The following resources may be affected:
>   - Mount point /
> Continue with operation? (yes/no)
>
> Well, it's neither in use (not mounted anywhere, just enabled), nor is it
> the root mount point.  The same will be true for F51 and F52.  Chzdev
> states
> that these are in use and mount points /usr and /var.  This does not happen
> when the disk is not a clone.
>
> Apparently, chzdev detects the partition UUID for each disk.  Since the F5x
> disks are clones of the 15x disks in active use, their UUID matches and
> apparently this confuses things.  If you simply change the UUID for the
> cloned disk, then this will not happen.
>
> Either the above problem, or something related or similar causes the grub2
> tools and/or Dracut to somehow get confused.  So, if you happen to
> activate/enable a DASD that has the same UUID as one of your root file
> system disks, then by chance you were to run
> Dracut/grub2-mkconfig/grub2-install on your live system, then your system
> will fail to boot at the next reboot because it is trying to find one of
> the
> devices needed for boot (150,151) even though they are there.  The F5x
> device with identical UUID causes this failure.  It also doesn't matter if
> the F5x disk is present at the next boot or not.
>
> I am hoping someone can shed some light on this.  I am not getting anywhere
> with SUSE and I feel that it is not unreasonable for the z/VM community to
> have cloned disks that have identical UUIDs on different servers. Grant it
> what I described above is not too likely of a scenario but still possible
> and it did happen to me.  I also don't every change the UUID of disks that
> I
> copy/clone.  Perhaps I should?
>
> Also, hopefully someone from IBM is listening here and can say whether the
> chzdev behavior is valid or not.  Note that you can take any disk, even an
> empty disk and as long as you change the UUID of the empty disk to match
> one
> of your active system disks UUID, you will have the same problems both with
> chzdev and boot issue.
>
> Thanks,
> Aria
>
>
>
>
>
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Marcy
> Cortes
> Sent: Thursday, August 19, 2021 6:35 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Warning if upgrading SLES12 to SLES15 SP3
>
> 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 up

Re: Warning if upgrading SLES12 to SLES15 SP3

[Aria Bamdad]

Hi all,

Over a month has gone by since I reported this failing to boot issue (read
below) to SUSE and so far, nothing.  They did say they found a problem with
Dracut command but didn't say what.  So I decided to look closer and I think
I have found something.  I suspect this is not limited to just upgrading
from SLES12 to 15 and it affects all systems.

It seems that there may be a problem with the new s390-tools chzdev command
at the least.  Consider the following situation.  You have a Linux guest
with root file system on device 150, usr on 151, var on 152.  Then you make
a copy of these disk (DDR/flashcopy/Etc.), say you are cloning the guest.
The copied disks are now called F50, F51 and F52 respectively.  Now consider
that you boot from your normal 15x disks while you have the F5x disks linked
and defined to the virtual machine.  Then you use chzdev command to enable
any of the cloned disks, say F50 (clone of root). You can do this either
using commands like chzdev or via Yast DASD tool to activate.  So far so
good.  But if you then try to disable the same disk (F50) using chzdev (or
Yast DASD), chzdev complains with:

Warning: ECKD DASD 0.0.0f50 is in use!
 The following resources may be affected:
  - Mount point /
Continue with operation? (yes/no)

Well, it's neither in use (not mounted anywhere, just enabled), nor is it
the root mount point.  The same will be true for F51 and F52.  Chzdev states
that these are in use and mount points /usr and /var.  This does not happen
when the disk is not a clone.

Apparently, chzdev detects the partition UUID for each disk.  Since the F5x
disks are clones of the 15x disks in active use, their UUID matches and
apparently this confuses things.  If you simply change the UUID for the
cloned disk, then this will not happen.

Either the above problem, or something related or similar causes the grub2
tools and/or Dracut to somehow get confused.  So, if you happen to
activate/enable a DASD that has the same UUID as one of your root file
system disks, then by chance you were to run
Dracut/grub2-mkconfig/grub2-install on your live system, then your system
will fail to boot at the next reboot because it is trying to find one of the
devices needed for boot (150,151) even though they are there.  The F5x
device with identical UUID causes this failure.  It also doesn't matter if
the F5x disk is present at the next boot or not.

I am hoping someone can shed some light on this.  I am not getting anywhere
with SUSE and I feel that it is not unreasonable for the z/VM community to
have cloned disks that have identical UUIDs on different servers. Grant it
what I described above is not too likely of a scenario but still possible
and it did happen to me.  I also don't every change the UUID of disks that I
copy/clone.  Perhaps I should?

Also, hopefully someone from IBM is listening here and can say whether the
chzdev behavior is valid or not.  Note that you can take any disk, even an
empty disk and as long as you change the UUID of the empty disk to match one
of your active system disks UUID, you will have the same problems both with
chzdev and boot issue.

Thanks,
Aria






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

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

Re: Warning if upgrading SLES12 to SLES15 SP3

[Mark Post]

On 8/20/21 5:20 PM, Marcy Cortes wrote:

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.


If you decide to go that way, use "chzdev -e -p" to write out the new
udev rules. If you leave the "-p" off, the command will look to see if
the device is already online, and say that it's already configured, and
not write out the rules. Then you can manually delete the 51-* files.


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

[Mark Post]

On 8/20/21 5:09 PM, Aria Bamdad wrote:

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! 


No, it won't help. Have that person call me directly.


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

[Mark Post]

On 8/20/21 5:21 PM, Aria Bamdad wrote:
This is interesting.  On a SLES12-SP5 system I have, there are no 41 
rules and

only 51 rules.  All disks are online and server boots without a
problem.  Yet on
this system, when I issue lszdev command, it lists all of the disks
but ore the persistent
column it lists 'no' for all of them.  Clearly not the case! 


IBM's lszdev command only looks for /etc/udev/rules.d/41-* files to 
report its findings.



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

[van Sleeuwen, Berry]

I have a newly installed SLES15 SP1 and in that machine I indeed noticed the 
udev rules were 41-* instead of 51-*. That includes both dasd-eckd and dasd-fba 
rules.

I don't know what an upgrade process would do with the existing rules. Usually 
we rebuild a machine instead of an upgrade in-place.

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 Aria Bamdad
Sent: Friday, 20 August 2021 23:09
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Warning if upgrading SLES12 to SLES15 SP3

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

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://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.
> marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390data=04%7C01%7CBerry.van
> Sleeuwen%40atos.net%7C7e2bce5c23f94eef2ea408d9641ee507%7C33440fc6b7c74
> 12cbb730e70b0198d5a%7C0%7C0%7C637650906119697612%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1000sdata=M%2FNsEkUC4m3PoK6tC%2BI4Nf3kXKMjay0pCNs87%2FQ1W64%3D&
> amp;reserved=0

--
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=04%7C01%7CBerry.vanSleeuwen%40atos.net%7C7e2bce5c23f94eef2ea408d9641ee507%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637650906119707562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=GvJI92wj3NbbAlv9G1bPyncBPiyoQFGni2PYf4MKEpQ%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

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

[Mark Post]

On 8/19/21 6:34 PM, Marcy Cortes wrote:

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.


Rather than wait for disaster to happen, it may be better to be 
proactive. For each device that is currently active, but there is no 
41-* rule for it, using "chzdev -e -p" will create one. For DASD 
devices, pretty much the only other thing you would need to worry about 
is whether it should be defined with use_diag=1 or not. "lsdasd | grep 
-i diag" will show you all of those.



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

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




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?



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

[Aria Bamdad]

Quoting Mark Post :


On 8/19/21 6:34 PM, Marcy Cortes wrote:

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.


Rather than wait for disaster to happen, it may be better to be
proactive. For each device that is currently active, but there is no
41-* rule for it, using "chzdev -e -p" will create one. For DASD
devices, pretty much the only other thing you would need to worry about
is whether it should be defined with use_diag=1 or not. "lsdasd | grep
-i diag" will show you all of those.




This is interesting.  On a SLES12-SP5 system I have, there are no 41 rules and
only 51 rules.  All disks are online and server boots without a
problem.  Yet on
this system, when I issue lszdev command, it lists all of the disks
but ore the persistent
column it lists 'no' for all of them.  Clearly not the case!

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

[Aria Bamdad]

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

Warning if upgrading SLES12 to SLES15 SP3

[Aria Bamdad]

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

SLES12 SP5 is GA

[Mark Post]

See $SUBJECT. For more information, see
https://www.suse.com/c/suse-linux-enterprise-12-service-pack-5-is-generally-available/


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: Kernel Panic after online migration from SLES12 SP3 to SP4

[Gerald Schaefer]

On Mon, 10 Jun 2019 17:47:20 +
Mark Bullis  wrote:

> We attempted to upgrade 4 SUSE linux  z/VM 6.4 guests this last weekend and 2 
> of them failed with
>
> {FAILED] Failed to start Load Kernel Modules
>
> Many Out of Memory messages
>
> Kernel panic - not syncing:  Out of memory and no killable processes
>
> CPU:  1 PID:250 Comm kworker/u128:2 Not tainted 4.4.131-94.29-default #1
>
> Then CP entered; disable wait.
>
> The upgrade was successful, but got the above after the first boot.
>
> The 2 upgrades that succeeded uses a kernel 4.12.14-95.16-default.  Had to 
> restore the faild systems from backups.
>
> Opened an S.R. with SUSE, and the engineer told be to upgrade again, but 
> before rebooting check grub and make sure it selects the right kernel.
> Has anyone else seen this?  The 2 failed guests are both 20GiB oracle 
> database servers with hugepages turned on.  The 2 that succeeded do not use 
> hugepages and are only 6GiB in size.

This has been reported via LTC bug#175823 and SUSE bug#1127293.

It is because of the special mechanism that is used for grub2 on SLES. The 
first kernel (stage 1) gets booted via zipl and it will present the grub menu 
and load the second kernel (stage 2) via kexec. For historic reasons, the stage 
1 kernel is always booted with mem=1G parameter appended. If you now configure 
hugepages on your system, e.g. via sysctl.conf, that setting will also be 
propagated to the stage 1 kernel initrd, as soon as it is being rebuilt.

Normal kernel maintweb updates do not rebuild the stage 1 kernel and its 
initrd, they only change the stage 2 kernel. However, during SP3 -> SP4 update, 
the stage 1 kernel and intird apparently are rebuilt, resulting in a stage 1 
kernel with restricted 1 GB memory trying to allocate tons of hugepages and 
going out-of-memory before it can do the kexec for the stage 2 kernel.

There are two options to fix it, either remove the hugepages pre-allocation 
setting before the SP3 -> SP4 update, or remove the "mem=1G" parameter for the 
stage 1 kernel in /etc/default/zipl2grub.conf.in. The latter was chosen by SUSE 
to resolve the bugzilla, by providing a grub2 PTF rpm to the customer. If you 
already have a S.R. with SUSE, you could point them to SUSE bug#1127293.

In order to get into the system after the upgrade, you can try to skip the 
normal stage 1/2 mechanism with the (hidden) zipl boot menu in SLES:
- IPL with LOADPARM 2 (=> skip-grub) to side-step 'mem=1G' (this will boot up 
the system with the stage 1 kernel only, but w/o mem=1G),
- after (presumably) successful boot log on as root,
- remove "mem=1G" from '/etc/default/zipl2grub.conf.in'
- run 'grub2-install --force' to establish the new kernel in '/boot/zipl'

Regards,
Gerald Schaefer

--
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: Kernel Panic after online migration from SLES12 SP3 to SP4

[Karl Kingston]

I have seen this.   Just make sure the servers have enough free memory before 
you start.  
If the memory is being taken up by hugepages, you may not have enough for the 
upgrade.  

On Mon, 2019-06-10 at 17:47 +, Mark Bullis wrote:
> We attempted to upgrade 4 SUSE linux  z/VM 6.4 guests this last weekend and 2 
> of them failed with
> 
> {FAILED] Failed to start Load Kernel Modules
> 
> Many Out of Memory messages
> 
> Kernel panic - not syncing:  Out of memory and no killable processes
> 
> CPU:  1 PID:250 Comm kworker/u128:2 Not tainted 4.4.131-94.29-default #1
> 
> Then CP entered; disable wait.
> 
> The upgrade was successful, but got the above after the first boot.
> 
> The 2 upgrades that succeeded uses a kernel 4.12.14-95.16-default.  Had to 
> restore the faild systems from backups.
> 
> Opened an S.R. with SUSE, and the engineer told be to upgrade again, but 
> before rebooting check grub and make sure it selects the right kernel.
> Has anyone else seen this?  The 2 failed guests are both 20GiB oracle 
> database servers with hugepages turned on.  The 2 that succeeded do not use 
> hugepages and are only 6GiB in size.
> 
> 
> CONFIDENTIALITY NOTICE
> The information contained in this transmission may contain privileged and 
> confidential information and is intended only for the use of the person(s) 
> named above. If you are not the intended recipient, or an employee or agent 
> responsible for delivering this message to the intended recipient, any 
> review, dissemination, distribution or duplication of this communication is 
> strictly prohibited. If you are not the intended recipient, please contact 
> the sender immediately by reply e-mail and destroy all copies of the original 
> message. This message may be subject to disclosure under the Open Records Act.
> 
> 
> --
> 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

Kernel Panic after online migration from SLES12 SP3 to SP4

[Mark Bullis]

We attempted to upgrade 4 SUSE linux  z/VM 6.4 guests this last weekend and 2 
of them failed with

{FAILED] Failed to start Load Kernel Modules

Many Out of Memory messages

Kernel panic - not syncing:  Out of memory and no killable processes

CPU:  1 PID:250 Comm kworker/u128:2 Not tainted 4.4.131-94.29-default #1

Then CP entered; disable wait.

The upgrade was successful, but got the above after the first boot.

The 2 upgrades that succeeded uses a kernel 4.12.14-95.16-default.  Had to 
restore the faild systems from backups.

Opened an S.R. with SUSE, and the engineer told be to upgrade again, but before 
rebooting check grub and make sure it selects the right kernel.
Has anyone else seen this?  The 2 failed guests are both 20GiB oracle database 
servers with hugepages turned on.  The 2 that succeeded do not use hugepages 
and are only 6GiB in size.


CONFIDENTIALITY NOTICE
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any review, 
dissemination, distribution or duplication of this communication is strictly 
prohibited. If you are not the intended recipient, please contact the sender 
immediately by reply e-mail and destroy all copies of the original message. 
This message may be subject to disclosure under the Open Records Act.


--
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: SLES12 SP3 Repos

[Alan Haff]

They're both in the SDK repo.

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Neale 
Ferguson
Sent: Wednesday, February 27, 2019 07:25
To: LINUX-390@VM.MARIST.EDU
Subject: SLES12 SP3 Repos

Where would I find libarchive-devel and net-snmp-devel? My zipper conf has 
these in repos.d but it doesn't find these packages:

SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Debuginfo-Pool.repo
SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Debuginfo-Updates.repo
SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Pool.repo
SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Source-Pool.repo
SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Updates.repo

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://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: SLES12 SP3 Repos

[Mark Post]

On 2/27/19 10:24 AM, Neale Ferguson wrote:
> Where would I find libarchive-devel and net-snmp-devel? My zipper conf has 
> these in repos.d but it doesn't find these packages:
>
> SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Debuginfo-Pool.repo
> SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Debuginfo-Updates.repo
> SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Pool.repo
> SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Source-Pool.repo
> SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Updates.repo

Those packages are in the SDK (Software Development Kit).


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

SLES12 SP3 Repos

[Neale Ferguson]

Where would I find libarchive-devel and net-snmp-devel? My zipper conf has 
these in repos.d but it doesn't find these packages:

SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Debuginfo-Pool.repo
SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Debuginfo-Updates.repo
SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Pool.repo
SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Source-Pool.repo
SUSE_Linux_Enterprise_Server_12_SP3_s390x:SLES12-SP3-Updates.repo

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

Re: Messages booting SLES12 SP3

[Neale Ferguson]

Don't have another guest that understands btrfs


 Original message 
From: Mark Post 
Date: 10/24/18 00:14 (GMT+01:00)
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Messages booting SLES12 SP3

>>> On 10/23/2018 at 05:54 PM, Neale Ferguson  wrote:
> Normally I'd boot from reader. I just have to get hold of those files from
> TPTB.

I was thinking more of shutting down the guest, and linking to its disks from 
another guest.


Mark Post

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

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

Re: Messages booting SLES12 SP3

[Mark Post]

>>> On 10/23/2018 at 05:54 PM, Neale Ferguson  wrote: 
> Normally I'd boot from reader. I just have to get hold of those files from 
> TPTB.

I was thinking more of shutting down the guest, and linking to its disks from 
another guest.


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: Messages booting SLES12 SP3

[Neale Ferguson]

Normally I'd boot from reader. I just have to get hold of those files from TPTB.

On 10/23/18, 23:48, "Linux on 390 Port on behalf of Mark Post" 
 wrote:

>>> On 10/23/2018 at 05:38 PM, Neale Ferguson  wrote: 
> I can't get the system up. It just keeps spitting that message after I 
IPL.

You're running z/VM.  I'm pretty sure you know how to get around that, 
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://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Messages booting SLES12 SP3

[Mark Post]

>>> On 10/23/2018 at 05:38 PM, Neale Ferguson  wrote: 
> I can't get the system up. It just keeps spitting that message after I IPL.

You're running z/VM.  I'm pretty sure you know how to get around that, Neale.  
:)


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: Messages booting SLES12 SP3

[Mark Post]

>>> On 10/23/2018 at 05:22 PM, Neale Ferguson  wrote: 
> vmcp link thenI activated via yast2 (it said it rebuilt initrd) and was going 
> to use btrfs replace to replace the other disk but hadn’t done so. I 
> initially did a btrfs add but then quickly btrfs removed without error.
> 
> On 10/23/18, 23:19, "Linux on 390 Port on behalf of Mark Post" 
>  wrote:
> 
> 1. How, exactly, did you add it?
> 2. Did the volume become part of the disks making up the root file 
> system?

Hmm.  Try running "grub2-install" and see if that helps when you reboot.


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: Messages booting SLES12 SP3

[Neale Ferguson]

vmcp link thenI activated via yast2 (it said it rebuilt initrd) and was going 
to use btrfs replace to replace the other disk but hadn’t done so. I initially 
did a btrfs add but then quickly btrfs removed without error.

On 10/23/18, 23:19, "Linux on 390 Port on behalf of Mark Post" 
 wrote:

1. How, exactly, did you add it?
2. Did the volume become part of the disks making up the root file system?
 


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

Re: Messages booting SLES12 SP3

[Mark Post]

>>> On 10/23/2018 at 04:24 PM, Neale Ferguson  wrote: 
> I added a disk to the system and now when I did a shutdown -r now I am seeing 
> this message repeated ad infintum at boot time:
> 
> A start job is running for dev-disk...x2dpart2.device (42s / no limit)  [OK]

1. How, exactly, did you add it?
2. Did the volume become part of the disks making up the root file system?


Mark Post

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

Re: Messages booting SLES12 SP3

[Neale Ferguson]

I did a dasdfmt and fdasd. I hadn't added it to the btrfs configuration yet. I 
was going to try and replace the disk I had reported earlier.

On 10/23/18, 22:53, "Linux on 390 Port on behalf of R P Herrold" 
 wrote:

On Tue, 23 Oct 2018, Neale Ferguson wrote:

Did you explicitly 'dd' off any labels from prior usage ?

Also remember that LVM looks beyond the first sector (and
offset multiples), and needs to be 'scratched' with the tools
in the lvs2 suite.  the LVM is sneaky enough to sniff for and
then to 'see' old layout data, and to try to assemble a
partially broken drive into its coverage
 


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

Messages booting SLES12 SP3

[R P Herrold]

On Tue, 23 Oct 2018, Neale Ferguson wrote:

> I added a disk to the system and now when I did a shutdown -r now I am seeing 
> this message repeated ad infintum at boot time:
>
> A start job is running for dev-disk...x2dpart2.device (42s / no limit)  [OK]
>
> What have I stuffed up?

Did you explicitly 'dd' off any labels from prior usage ?

Also remember that LVM looks beyond the first sector (and
offset multiples), and needs to be 'scratched' with the tools
in the lvs2 suite.  the LVM is sneaky enough to sniff for and
then to 'see' old layout data, and to try to assemble a
partially broken drive into its coverage

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

Messages booting SLES12 SP3

[Neale Ferguson]

I added a disk to the system and now when I did a shutdown -r now I am seeing 
this message repeated ad infintum at boot time:

A start job is running for dev-disk...x2dpart2.device (42s / no limit)  [OK]

What have I stuffed up?

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

Re: Problem upograding to SLES12

[Mark Post]

>>> On 8/10/2018 at 05:44 PM, Victor Echavarry 
wrote: 
> We are upgrading servers from SLES 11 to SLES 12. One of the server doesn't  
> saw the DVD. It stays long time on the following lines
> 
> eth0: network config created
> 8021q: adding VLAN 0 to HW filter on device eth0
> Them send stay a couple of minutes on this line
> random: nonblocking pool is initialized
> 
> them send the following
> 
> Please make sure your installation medium is available.
> 
> Choose the URL to retry.
> 
> 0) <-- Back <--
> 1) http://10.1.38.158/SLES12/s390x/DVD1
> 2) cd:/
> 3) hd:/
> 4) Enter another URL
> 
> This is the parameter file
> 
> TERM=dumb
> hostip=192.168.2.162/24 gateway=192.168.2.60 domain=local
> hostname=l21ct nameserver=10.23.0.238 portno=0
> instnetdev=osa osainterface=qdio layer2=1
> upgrade=1
> OSAHWaddr=02:78:C1:02:1c:00
> readchannel=0.0.0360 writechannel=0.0.0361 datachannel=0.0.0362
> usevnc=1 vncpassword=password
> install=http://10.1.38.158/SLES12/s390x/DVD1
> 
> Does anyone know what happen and how to solve it?

You'll need to check and see if your network actually got configured properly.  
At that prompt, you should be able to enter a lower-case x, and then select 
"start a shell."


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/

Problem upograding to SLES12

[Victor Echavarry]

We are upgrading servers from SLES 11 to SLES 12. One of the server doesn't  
saw the DVD. It stays long time on the following lines

eth0: network config created
8021q: adding VLAN 0 to HW filter on device eth0
Them send stay a couple of minutes on this line
random: nonblocking pool is initialized

them send the following

Please make sure your installation medium is available.

Choose the URL to retry.

0) <-- Back <--
1) http://10.1.38.158/SLES12/s390x/DVD1
2) cd:/
3) hd:/
4) Enter another URL

This is the parameter file

TERM=dumb
hostip=192.168.2.162/24 gateway=192.168.2.60 domain=local
hostname=l21ct nameserver=10.23.0.238 portno=0
instnetdev=osa osainterface=qdio layer2=1
upgrade=1
OSAHWaddr=02:78:C1:02:1c:00
readchannel=0.0.0360 writechannel=0.0.0361 datachannel=0.0.0362
usevnc=1 vncpassword=password
install=http://10.1.38.158/SLES12/s390x/DVD1

Does anyone know what happen and how to solve it?

Regards,

Victor Echavarry

System Programmer

Operating Systems



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

KVM on Z: SLES12 SP3 Updates

[Stefan Raspl]

SLES12SP3, released late last year, received a couple of mostly performance and
security-related updates in support of IBM z14 and LinuxONE through the
maintenance web updates.

See http://kvmonz.blogspot.co.uk/2018/03/sles12-sp3-updates.html for further
details.



Mit freundlichen Grüßen / Kind regards

Stefan Raspl


Linux on Z & Virtualization Development
---
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-2177
E-Mail: stefan.ra...@de.ibm.com
---
IBM Deutschland Research & Development GmbH / Vorsitzende des Aufsichtsrats:
Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB
243294

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

Re: SLES12 SP3 autoyast install

[van Sleeuwen, Berry]

Hi Mark,

I did, I opened a PMR at IBM (FYI 91682,031,724).

Looking a bit further, I think the SuSEfirewall is started in the second stage 
install. But the firewall is not yet configured at that time as this is 
actually part of the second stage. The /etc/sysconfig/SuSEfirewall file at 
login during the second stage is basically empty (or at least missing the 
explicit enable of sshd) while that configuration is present after the second 
stage is finished.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post 
mpost
Sent: Tuesday, December 19, 2017 9:49 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Please be sure to file a bug report for this.

Mark Post"van Sleeuwen, Berry" <berry.vansleeu...@atos.net> wrote:
>>> "van Sleeuwen, Berry" <berry.vansleeu...@atos.net> 12/19/2017 10:25
>>> >>>
Just for fun, I disabled the firewall in the xml file and ran the installation. 
I didn't expect to see a difference. But, surprise, it did. Looks like the 
firewall is incorrectly configured during the initial install.

So, to my surprise, spot on. Thanks.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen


-Original Message-
From: van Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 6:03 PM
To: LINUX-390@VM.MARIST.EDU
Subject: RE: SLES12 SP3 autoyast install

Yes, it does. Just like it does during manual install. The same goes for SLES 
12 SP2. The configuration is included in the xml file. So if anything, the 
firewall should be configured the same in both ways of installing. The sshd is 
indeed allowed for all interfaces.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy 
Cortes
Sent: Tuesday, December 19, 2017 5:53 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Did it maybe start SuSEFirewall?

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van 
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:52 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SLES12 SP3 autoyast install

Marcy,

I don't think that's the problem. I can't connect, not even from a Linux guest 
on the same vswitch/vlan.

The gateway is set in the PARMFILE used during install, both for the manual 
install and the autoyast installation. This should be included in the Linux 
configuration in the same way.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy 
Cortes
Sent: Tuesday, December 19, 2017 5:27 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Did you ping it from some place other than the same subnet it is on?
Perhaps the default gateway isn't set?


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van 
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:23 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SLES12 SP3 autoyast install

Hi All,

I am installing a new SLES 12 SP3 system. So first I run a manual install.
After install is completed the machine is rebooted. So far no problem. After 
reboot the system is accessible as expected. So now I run yast2 clone_system to 
create an autoinst.xml file.

Next I use the autoinst.xml file to run an automatic install. The autoyast 
installer runs through the install. Next the machine is rebooted. The guest 
states sshd is started so I should be able to connect to the machine. The IP 
address is registered in the vswitch and I can ping the machine. But I can’t 
access the system for the second stage install, the ssh session simply times 
out.

I have used various versions of the xml file. Both the base as created by
yast2 and a file that has been rebuild to add options we want to have from 
within the autoyast installation. It looks like the installation is executed 
correctly but no luck accessing the machine after reboot with any of the 
attempts.

I have done the same with SLES 12 SP2 and found no such problems.

What could be the cause of this?



Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen Flight Forum 3000 5657 EW Eindhoven • +31 (0)6 22564276  
[cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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 imcannot be secured on the Internet, Atos’ liability 
cannot be triggered for the message content. Although the sender endeavours to 
maintain

Re: SLES12 SP3 autoyast install

[Mark Post mpost]

Please be sure to file a bug report for this.

Mark Post"van Sleeuwen, Berry" <berry.vansleeu...@atos.net> wrote:
>>> "van Sleeuwen, Berry" <berry.vansleeu...@atos.net> 12/19/2017 10:25 >>>
Just for fun, I disabled the firewall in the xml file and ran the installation. 
I didn't expect to see a difference. But, surprise, it did. Looks like the 
firewall is incorrectly configured during the initial install.

So, to my surprise, spot on. Thanks.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen


-Original Message-
From: van Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 6:03 PM
To: LINUX-390@VM.MARIST.EDU
Subject: RE: SLES12 SP3 autoyast install

Yes, it does. Just like it does during manual install. The same goes for
SLES 12 SP2. The configuration is included in the xml file. So if anything,
the firewall should be configured the same in both ways of installing. The
sshd is indeed allowed for all interfaces.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy
Cortes
Sent: Tuesday, December 19, 2017 5:53 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Did it maybe start SuSEFirewall?

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:52 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SLES12 SP3 autoyast install

Marcy,

I don't think that's the problem. I can't connect, not even from a Linux
guest on the same vswitch/vlan.

The gateway is set in the PARMFILE used during install, both for the manual
install and the autoyast installation. This should be included in the Linux
configuration in the same way.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van
Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy
Cortes
Sent: Tuesday, December 19, 2017 5:27 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Did you ping it from some place other than the same subnet it is on?
Perhaps the default gateway isn't set?


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:23 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SLES12 SP3 autoyast install

Hi All,

I am installing a new SLES 12 SP3 system. So first I run a manual install.
After install is completed the machine is rebooted. So far no problem. After
reboot the system is accessible as expected. So now I run yast2 clone_system
to create an autoinst.xml file.

Next I use the autoinst.xml file to run an automatic install. The autoyast
installer runs through the install. Next the machine is rebooted. The guest
states sshd is started so I should be able to connect to the machine. The IP
address is registered in the vswitch and I can ping the machine. But I can’t
access the system for the second stage install, the ssh session simply times
out.

I have used various versions of the xml file. Both the base as created by
yast2 and a file that has been rebuild to add options we want to have from
within the autoyast installation. It looks like the installation is executed
correctly but no luck accessing the machine after reboot with any of the
attempts.

I have done the same with SLES 12 SP2 and found no such problems.

What could be the cause of this?



Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van
Sleeuwen Flight Forum 3000 5657 EW Eindhoven • +31 (0)6 22564276
 [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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 imcannot 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.
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, 

Re: SLES12 SP3 autoyast install

[van Sleeuwen, Berry]

Just for fun, I disabled the firewall in the xml file and ran the installation. 
I didn't expect to see a difference. But, surprise, it did. Looks like the 
firewall is incorrectly configured during the initial install.

So, to my surprise, spot on. Thanks.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen


-Original Message-
From: van Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 6:03 PM
To: LINUX-390@VM.MARIST.EDU
Subject: RE: SLES12 SP3 autoyast install

Yes, it does. Just like it does during manual install. The same goes for
SLES 12 SP2. The configuration is included in the xml file. So if anything,
the firewall should be configured the same in both ways of installing. The
sshd is indeed allowed for all interfaces.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy
Cortes
Sent: Tuesday, December 19, 2017 5:53 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Did it maybe start SuSEFirewall?

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:52 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SLES12 SP3 autoyast install

Marcy,

I don't think that's the problem. I can't connect, not even from a Linux
guest on the same vswitch/vlan.

The gateway is set in the PARMFILE used during install, both for the manual
install and the autoyast installation. This should be included in the Linux
configuration in the same way.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van
Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy
Cortes
Sent: Tuesday, December 19, 2017 5:27 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Did you ping it from some place other than the same subnet it is on?
Perhaps the default gateway isn't set?


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:23 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SLES12 SP3 autoyast install

Hi All,

I am installing a new SLES 12 SP3 system. So first I run a manual install.
After install is completed the machine is rebooted. So far no problem. After
reboot the system is accessible as expected. So now I run yast2 clone_system
to create an autoinst.xml file.

Next I use the autoinst.xml file to run an automatic install. The autoyast
installer runs through the install. Next the machine is rebooted. The guest
states sshd is started so I should be able to connect to the machine. The IP
address is registered in the vswitch and I can ping the machine. But I can’t
access the system for the second stage install, the ssh session simply times
out.

I have used various versions of the xml file. Both the base as created by
yast2 and a file that has been rebuild to add options we want to have from
within the autoyast installation. It looks like the installation is executed
correctly but no luck accessing the machine after reboot with any of the
attempts.

I have done the same with SLES 12 SP2 and found no such problems.

What could be the cause of this?



Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van
Sleeuwen Flight Forum 3000 5657 EW Eindhoven • +31 (0)6 22564276
 [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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

Re: SLES12 SP3 autoyast install

[van Sleeuwen, Berry]

Yes, it does. Just like it does during manual install. The same goes for
SLES 12 SP2. The configuration is included in the xml file. So if anything,
the firewall should be configured the same in both ways of installing. The
sshd is indeed allowed for all interfaces.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, 
Berry van Sleeuwen


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy
Cortes
Sent: Tuesday, December 19, 2017 5:53 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Did it maybe start SuSEFirewall?

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:52 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SLES12 SP3 autoyast install

Marcy,

I don't think that's the problem. I can't connect, not even from a Linux
guest on the same vswitch/vlan.

The gateway is set in the PARMFILE used during install, both for the manual
install and the autoyast installation. This should be included in the Linux
configuration in the same way.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van
Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy
Cortes
Sent: Tuesday, December 19, 2017 5:27 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Did you ping it from some place other than the same subnet it is on?
Perhaps the default gateway isn't set?


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:23 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SLES12 SP3 autoyast install

Hi All,

I am installing a new SLES 12 SP3 system. So first I run a manual install.
After install is completed the machine is rebooted. So far no problem. After
reboot the system is accessible as expected. So now I run yast2 clone_system
to create an autoinst.xml file.

Next I use the autoinst.xml file to run an automatic install. The autoyast
installer runs through the install. Next the machine is rebooted. The guest
states sshd is started so I should be able to connect to the machine. The IP
address is registered in the vswitch and I can ping the machine. But I can’t
access the system for the second stage install, the ssh session simply times
out.

I have used various versions of the xml file. Both the base as created by
yast2 and a file that has been rebuild to add options we want to have from
within the autoyast installation. It looks like the installation is executed
correctly but no luck accessing the machine after reboot with any of the
attempts.

I have done the same with SLES 12 SP2 and found no such problems.

What could be the cause of this?



Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van
Sleeuwen Flight Forum 3000 5657 EW Eindhoven • +31 (0)6 22564276
 [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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

Re: SLES12 SP3 autoyast install

[Marcy Cortes]

Did it maybe start SuSEFirewall?

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van 
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:52 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SLES12 SP3 autoyast install

Marcy,

I don't think that's the problem. I can't connect, not even from a Linux guest 
on the same vswitch/vlan.

The gateway is set in the PARMFILE used during install, both for the manual 
install and the autoyast installation. This should be included in the Linux 
configuration in the same way.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy 
Cortes
Sent: Tuesday, December 19, 2017 5:27 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Did you ping it from some place other than the same subnet it is on?
Perhaps the default gateway isn't set?


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van 
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:23 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SLES12 SP3 autoyast install

Hi All,

I am installing a new SLES 12 SP3 system. So first I run a manual install. 
After install is completed the machine is rebooted. So far no problem. After 
reboot the system is accessible as expected. So now I run yast2 clone_system to 
create an autoinst.xml file.

Next I use the autoinst.xml file to run an automatic install. The autoyast 
installer runs through the install. Next the machine is rebooted. The guest 
states sshd is started so I should be able to connect to the machine. The IP 
address is registered in the vswitch and I can ping the machine. But I can’t 
access the system for the second stage install, the ssh session simply times 
out.

I have used various versions of the xml file. Both the base as created by yast2 
and a file that has been rebuild to add options we want to have from within the 
autoyast installation. It looks like the installation is executed correctly but 
no luck accessing the machine after reboot with any of the attempts.

I have done the same with SLES 12 SP2 and found no such problems.

What could be the cause of this?



Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen Flight Forum 3000 5657 EW Eindhoven • +31 (0)6 22564276
 [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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

Re: SLES12 SP3 autoyast install

[van Sleeuwen, Berry]

Marcy,

I don't think that's the problem. I can't connect, not even from a Linux guest 
on the same vswitch/vlan.

The gateway is set in the PARMFILE used during install, both for the manual 
install and the autoyast installation. This should be included in the Linux 
configuration in the same way.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy 
Cortes
Sent: Tuesday, December 19, 2017 5:27 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 SP3 autoyast install

Did you ping it from some place other than the same subnet it is on?
Perhaps the default gateway isn't set?


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van 
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:23 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SLES12 SP3 autoyast install

Hi All,

I am installing a new SLES 12 SP3 system. So first I run a manual install. 
After install is completed the machine is rebooted. So far no problem. After 
reboot the system is accessible as expected. So now I run yast2 clone_system to 
create an autoinst.xml file.

Next I use the autoinst.xml file to run an automatic install. The autoyast 
installer runs through the install. Next the machine is rebooted. The guest 
states sshd is started so I should be able to connect to the machine. The IP 
address is registered in the vswitch and I can ping the machine. But I can’t 
access the system for the second stage install, the ssh session simply times 
out.

I have used various versions of the xml file. Both the base as created by yast2 
and a file that has been rebuild to add options we want to have from within the 
autoyast installation. It looks like the installation is executed correctly but 
no luck accessing the machine after reboot with any of the attempts.

I have done the same with SLES 12 SP2 and found no such problems.

What could be the cause of this?



Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen Flight Forum 3000 5657 EW Eindhoven • +31 (0)6 22564276
 [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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

Re: SLES12 SP3 autoyast install

[Marcy Cortes]

Did you ping it from some place other than the same subnet it is on?
Perhaps the default gateway isn't set?


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van 
Sleeuwen, Berry
Sent: Tuesday, December 19, 2017 8:23 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SLES12 SP3 autoyast install

Hi All,

I am installing a new SLES 12 SP3 system. So first I run a manual install. 
After install is completed the machine is rebooted. So far no problem. After 
reboot the system is accessible as expected. So now I run yast2 clone_system to 
create an autoinst.xml file.

Next I use the autoinst.xml file to run an automatic install. The autoyast 
installer runs through the install. Next the machine is rebooted. The guest 
states sshd is started so I should be able to connect to the machine. The IP 
address is registered in the vswitch and I can ping the machine. But I can’t 
access the system for the second stage install, the ssh session simply times 
out.

I have used various versions of the xml file. Both the base as created by yast2 
and a file that has been rebuild to add options we want to have from within the 
autoyast installation. It looks like the installation is executed correctly but 
no luck accessing the machine after reboot with any of the attempts.

I have done the same with SLES 12 SP2 and found no such problems.

What could be the cause of this?



Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen Flight Forum 3000 5657 EW Eindhoven • +31 (0)6 22564276
 [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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.

SLES12 SP3 autoyast install

[van Sleeuwen, Berry]

Hi All,

I am installing a new SLES 12 SP3 system. So first I run a manual install. 
After install is completed the machine is rebooted. So far no problem. After 
reboot the system is accessible as expected. So now I run yast2 clone_system to 
create an autoinst.xml file.

Next I use the autoinst.xml file to run an automatic install. The autoyast 
installer runs through the install. Next the machine is rebooted. The guest 
states sshd is started so I should be able to connect to the machine. The IP 
address is registered in the vswitch and I can ping the machine. But I can’t 
access the system for the second stage install, the ssh session simply times 
out.

I have used various versions of the xml file. Both the base as created by yast2 
and a file that has been rebuild to add options we want to have from within the 
autoyast installation. It looks like the installation is executed correctly but 
no luck accessing the machine after reboot with any of the attempts.

I have done the same with SLES 12 SP2 and found no such problems.

What could be the cause of this?



Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven
• +31 (0)6 22564276
 [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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.

Re: Open Vswitch and SLES12 KVM

[Tito Garrido]

Hi Folks!

The place that Robert pointed it is correct, but to update it we use a
script called qeth_configure (I guess it would be similar to chzdev but for
SuSE and network only)

So the answer was:

qeth_configure -l -o "bridge_role=primary" 1

Thank you!

Tito

On Tue, Dec 12, 2017 at 1:23 PM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

> On Tue, Dec 12, 2017 at 4:05 PM, Robert J Brenneman <bren...@gmail.com>
> wrote:
> > I have the following at the very end of my
> > /etc/udev/rules.d/51-qeth-0.0.1080.rules
>
> I think that is close to where chzdev [1] would place it, but IIRC
> SLES12 was not yet on chzdev right?
> If they are I beg your pardon - in that case you can enable it through
> chzdev and it will take care to store persistent config in the udev
> rules.
>
> [1]: https://www.ibm.com/support/knowledgecenter/en/linuxonibm/
> com.ibm.linux.z.lhdd/lhdd_r_chzdev_cmd.html
>
> --
> 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/
>



-- 

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: Open Vswitch and SLES12 KVM

[Marcy Cortes]

SLES 12 SP2 seems to have chzdev.

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Christian 
Ehrhardt
Sent: Tuesday, December 12, 2017 7:24 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Open Vswitch and SLES12 KVM

On Tue, Dec 12, 2017 at 4:05 PM, Robert J Brenneman <bren...@gmail.com> wrote:
> I have the following at the very end of my 
> /etc/udev/rules.d/51-qeth-0.0.1080.rules

I think that is close to where chzdev [1] would place it, but IIRC
SLES12 was not yet on chzdev right?
If they are I beg your pardon - in that case you can enable it through chzdev 
and it will take care to store persistent config in the udev rules.

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

Re: Open Vswitch and SLES12 KVM

[Christian Ehrhardt]

On Tue, Dec 12, 2017 at 4:05 PM, Robert J Brenneman <bren...@gmail.com> wrote:
> I have the following at the very end of my
> /etc/udev/rules.d/51-qeth-0.0.1080.rules

I think that is close to where chzdev [1] would place it, but IIRC
SLES12 was not yet on chzdev right?
If they are I beg your pardon - in that case you can enable it through
chzdev and it will take care to store persistent config in the udev
rules.

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

--
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: Open Vswitch and SLES12 KVM

[Robert J Brenneman]

I have the following at the very end of my
/etc/udev/rules.d/51-qeth-0.0.1080.rules
file:

>>>

ACTION=="add", SUBSYSTEM=="ccwgroup", KERNEL=="0.0.1080", ATTR{layer2}="1"

ACTION=="add", SUBSYSTEM=="ccwgroup", KERNEL=="0.0.1080",
ATTR{buffer_count}="128"

ACTION=="add", SUBSYSTEM=="ccwgroup", KERNEL=="0.0.1080",
ATTR{bridge_role}="primary"

ACTION=="add", SUBSYSTEM=="ccwgroup", KERNEL=="0.0.1080",
ATTR{bridge_state}="active"

ACTION=="add", SUBSYSTEM=="ccwgroup", KERNEL=="0.0.1080", ATTR{online}="1"
>>>


--
Jay Brenneman

--
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: Open Vswitch and SLES12 KVM

[Christian Ehrhardt]

On Mon, Dec 11, 2017 at 11:37 PM, Tito Garrido <titogarr...@gmail.com> wrote:
> Hi Folks,
>
> What is the recommended setup for open vswitch on SLES 12 on z?
>
> I can see:
> https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_ovs.html
>
> But it says nothing about BRIDGEPORT.
>
> Where should I put OPTIONS="layer2=1 bridge_role=primary
>
> Is "OPTIONS" a recognized option on SuSE?


Hi Tito,
until you have found where the "right" place in a config file would be
you can always control the device drivers directly (I don't expect
wicked and co to set it back).
>From the  device driver manual for  SLES12-SP3:
- layer2 [1]
- bridge_port [2]

[1]: 
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_qeth_wrk_layer2.html
[2]: 
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_t_qeth_wrk_hsbrdg.html

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

Open Vswitch and SLES12 KVM

[Tito Garrido]

Hi Folks,

What is the recommended setup for open vswitch on SLES 12 on z?

I can see:
https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_ovs.html

But it says nothing about BRIDGEPORT.

Where should I put OPTIONS="layer2=1 bridge_role=primary

Is "OPTIONS" a recognized option on SuSE?

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: Installing SLES12 SP2 can't access repository

[Mark Post]

>>> On 7/20/2017 at 06:26 PM, Julie Phinney  wrote: 
> Mark,
> 
> I can mount either one, using a command like this:
> 
> mount -o nolock -o vers=3  ipaddress:/install/penguin/SLES/sles12sp2/dvd1  
> /nfs
> 
> The contents of the dvd1 folder:
> LXTS12T2:/nfs # ls -l
> total 25952
> -r--r--r--  1 root root  5486315 Jun 13 18:50 ARCHIVES.gz
> -r--r--r--  1 root root 1484 Jun 13 18:50 COPYRIGHT
> -r--r--r--  1 root root 1648 Jun 13 18:50 COPYRIGHT.de
> -r--r--r--  1 root root 2063 Jun 13 18:50 ChangeLog
> -r--r--r--  1 root root41939 Jun 13 18:50 INDEX.gz
> -r--r--r--  1 root root   112779 Jun 13 18:50 NEWS
> -r--r--r--  1 root root 2910 Jun 13 18:50 README
> dr-xr-xr-x  4 root root  256 Jun 13 18:50 boot
> -r--r--r--  1 root root12497 Jun 13 18:50 content
> -r--r--r--  1 root root 2048 Jun 13 18:50 content.asc
> -r--r--r--  1 root root 8192 Jun 13 18:50 content.key
> -r--r--r--  1 root root53854 Jun 13 18:50 control.xml
> -r--r--r--  1 root root  260 Jun 13 18:50 directory.yast
> dr-xr-xr-x 17 root root 4096 Jun 13 18:50 docu
> -r--r--r--  1 root root  955 Jun 13 18:50 
> gpg-pubkey-39db7c82-510a966b.asc
> -r--r--r--  1 root root  975 Jun 13 18:50 
> gpg-pubkey-50a3dd1c-50f35137.asc
> -r--r--r--  1 root root90563 Jun 13 18:50 license.tar.gz
> -r--r--r--  1 root root64519 Jun 13 18:50 ls-lR.gz
> dr-xr-xr-x  2 root root  256 Jun 13 18:50 media.1
> -r--r--r--  1 root root 1288 Jun 13 18:50 pubring.gpg
> dr-xr-xr-x  6 root root  256 Jun 13 18:50 suse
> -r--r--r--  1 root root  212 Jun 13 18:50 suse.ins
> -r--r--r--  1 root root  224 Jun 13 18:50 susehmc.ins

If you can make the time, I would be interested in seeing the contents of the 
files under /var/log/YaST2/ when the install fails.  To generate a bit more 
information, if you add "linuxrc.debug=3 linuxrc.log=/dev/stdout" to the 
parmfile.  Then, send me the output from the z/VM console log for the guest.


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: Installing SLES12 SP2 can't access repository

[Julie Phinney]

Mark,

I can mount either one, using a command like this:

mount -o nolock -o vers=3  ipaddress:/install/penguin/SLES/sles12sp2/dvd1  /nfs

The contents of the dvd1 folder:
LXTS12T2:/nfs # ls -l
total 25952
-r--r--r--  1 root root  5486315 Jun 13 18:50 ARCHIVES.gz
-r--r--r--  1 root root 1484 Jun 13 18:50 COPYRIGHT
-r--r--r--  1 root root 1648 Jun 13 18:50 COPYRIGHT.de
-r--r--r--  1 root root 2063 Jun 13 18:50 ChangeLog
-r--r--r--  1 root root41939 Jun 13 18:50 INDEX.gz
-r--r--r--  1 root root   112779 Jun 13 18:50 NEWS
-r--r--r--  1 root root 2910 Jun 13 18:50 README
dr-xr-xr-x  4 root root  256 Jun 13 18:50 boot
-r--r--r--  1 root root12497 Jun 13 18:50 content
-r--r--r--  1 root root 2048 Jun 13 18:50 content.asc
-r--r--r--  1 root root 8192 Jun 13 18:50 content.key
-r--r--r--  1 root root53854 Jun 13 18:50 control.xml
-r--r--r--  1 root root  260 Jun 13 18:50 directory.yast
dr-xr-xr-x 17 root root 4096 Jun 13 18:50 docu
-r--r--r--  1 root root  955 Jun 13 18:50 gpg-pubkey-39db7c82-510a966b.asc
-r--r--r--  1 root root  975 Jun 13 18:50 gpg-pubkey-50a3dd1c-50f35137.asc
-r--r--r--  1 root root90563 Jun 13 18:50 license.tar.gz
-r--r--r--  1 root root64519 Jun 13 18:50 ls-lR.gz
dr-xr-xr-x  2 root root  256 Jun 13 18:50 media.1
-r--r--r--  1 root root 1288 Jun 13 18:50 pubring.gpg
dr-xr-xr-x  6 root root  256 Jun 13 18:50 suse
-r--r--r--  1 root root  212 Jun 13 18:50 suse.ins
-r--r--r--  1 root root  224 Jun 13 18:50 susehmc.ins

Thanks,
Julie
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Thursday, July 20, 2017 1:59 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Installing SLES12 SP2 can't access repository

>>> On 7/20/2017 at 02:19 PM, Julie Phinney 
>>> <jphin...@humana.com<mailto:jphin...@humana.com>> wrote:
> Thanks Mauro, Mark, Alan and everyone..
>
> Mark,
> My parm file has these lines:
> Install=nfs://ipaddress/install/penguin/SLES/sles12sp2/dvd1
> UseSSH=1 SSHPassword=12345678 upgrade=1 nfsopts=tcp,vers=3,nolock

And what are the contents of /install/penguin/SLES/sles12sp2/dvd1 on the NFS 
server?

> The /etc/exports on the nfs server has this line:
> /install/penguin -vers=3,sec=sys:none,rw And I'm able to mount the
> mountpoint successfully from this client before kicking off the
> install script.
> NFS version is 3.

When you say you're able to mount "the mountpoint" do you mean 
/install/penguin, or /install/penguin/SLES/sles12sp2/dvd1 ?


Mark Post

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


The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

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

Re: Installing SLES12 SP2 can't access repository

[Scott Rohling]

That's all dependent on the server and software you use for FTP ...   it
you keep FTP confined to a users /home directory - that's what you get..
 it may be set up differently depending on what flavor of ftp and how it's
configured. ( and what security is in place).
Scott Rohling

On Thu, Jul 20, 2017 at 11:33 AM, Jeffrey Barnard <j...@bsitcpip.com> wrote:

> On 07/19/2017 06:06 PM, Julie Phinney wrote:
>
>> One person said they created a symbolic link to the mounted .iso  in the
>> ftp user's home directory.
>>
>
> I was able to get this to work.
>
> I could not get SLES12SP2 to FTP install unless the .iso was mounted on a
> mount point in the FTP user's home directory.
>
> E.g., if the FTP userid is xxx
> then the FTP home directory might be /home/xxx
>
> If I mounted the .iso at /tmp/sles12 and pointed the install there ...
> failure.
>
> If I created a symlink from the home directory to this mount point ...
> success. Also, mounting the .iso to a mount point in the home directory
> worked too.
>
> E.g., a symlink from /home/xxx/sles12 ... to ... /tmp/sles12
> did the trick.
>
> Hope this helps.
> Jeff
>
> --
> 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: Installing SLES12 SP2 can't access repository

[Jeffrey Barnard]

On 07/19/2017 06:06 PM, Julie Phinney wrote:

One person said they created a symbolic link to the mounted .iso  in the ftp 
user's home directory.


I was able to get this to work.

I could not get SLES12SP2 to FTP install unless the .iso was mounted on a
mount point in the FTP user's home directory.

E.g., if the FTP userid is xxx
then the FTP home directory might be /home/xxx

If I mounted the .iso at /tmp/sles12 and pointed the install there ... failure.

If I created a symlink from the home directory to this mount point ...
success. Also, mounting the .iso to a mount point in the home directory
worked too.

E.g., a symlink from /home/xxx/sles12 ... to ... /tmp/sles12
did the trick.

Hope this helps.
Jeff

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

Re: Installing SLES12 SP2 can't access repository

[Mark Post]

>>> On 7/20/2017 at 02:19 PM, Julie Phinney  wrote: 
> Thanks Mauro, Mark, Alan and everyone..
> 
> Mark,
> My parm file has these lines:
> Install=nfs://ipaddress/install/penguin/SLES/sles12sp2/dvd1
> UseSSH=1 SSHPassword=12345678 upgrade=1 nfsopts=tcp,vers=3,nolock

And what are the contents of /install/penguin/SLES/sles12sp2/dvd1 on the NFS 
server?

> The /etc/exports on the nfs server has this line:
> /install/penguin -vers=3,sec=sys:none,rw
> And I'm able to mount the mountpoint successfully from this client before 
> kicking off the install script.
> NFS version is 3.

When you say you're able to mount "the mountpoint" do you mean 
/install/penguin, or /install/penguin/SLES/sles12sp2/dvd1 ?


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: Installing SLES12 SP2 can't access repository

[Julie Phinney]

Thanks Mauro, Mark, Alan and everyone..

Mark,
My parm file has these lines:
Install=nfs://ipaddress/install/penguin/SLES/sles12sp2/dvd1
UseSSH=1 SSHPassword=12345678 upgrade=1 nfsopts=tcp,vers=3,nolock

The /etc/exports on the nfs server has this line:
/install/penguin -vers=3,sec=sys:none,rw
And I'm able to mount the mountpoint successfully from this client before 
kicking off the install script.
NFS version is 3.

Alan,
I opened a ticket a few weeks ago.  The  latest thing they said to me, today, 
is to try is just using a dvd.

Mauro,  I tried using http today instead and it worked‼
I'm so happy I can move on.

Thanks again everyone!
Julie

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Thursday, July 20, 2017 12:43 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Installing SLES12 SP2 can't access repository

>>> On 7/19/2017 at 06:06 PM, Julie Phinney 
>>> <jphin...@humana.com<mailto:jphin...@humana.com>> wrote:
> Back in April you all talked about a problem someone had installing
> SLES12 sp2,  zvm 6.4, using FTP.
> Several people recommended burning the iso to dvd and installing from that.
> One person said they created a symbolic link to the mounted .iso  in
> the ftp user's home directory.
>
> I'm using an NFS mount.  Before starting the yast.ssh script to do the
> install, I can access the mount and its data just fine.
> I run the yast.ssh script and it fails with the same error some of you
> had in the April chat  - mount.nfs access denied  trying to access the
> repository.
> Has anyone gotten an NFS mounted install to work after having this problem?
> I'm not seeing any errors logged on the NFS server.

That's why I typically recommend _not_ using NFS.  It's very difficult to get 
any debugging information out of it compared to FTP or HTTP.

What are you specifying in the parameter file?  What does the /etc/exports file 
on the NFS server have in it?  What version of NFS is running on the NFS server?


Mark Post

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


The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Re: Installing SLES12 SP2 can't access repository

[Mark Post]

>>> On 7/19/2017 at 06:06 PM, Julie Phinney <jphin...@humana.com> wrote: 
> Back in April you all talked about a problem someone had installing SLES12 
> sp2,  zvm 6.4, using FTP.
> Several people recommended burning the iso to dvd and installing from that.
> One person said they created a symbolic link to the mounted .iso  in the ftp 
> user's home directory.
> 
> I'm using an NFS mount.  Before starting the yast.ssh script to do the 
> install, I can access the mount and its data just fine.
> I run the yast.ssh script and it fails with the same error some of you had 
> in the April chat  - mount.nfs access denied  trying to access the 
> repository.
> Has anyone gotten an NFS mounted install to work after having this problem?
> I'm not seeing any errors logged on the NFS server.

That's why I typically recommend _not_ using NFS.  It's very difficult to get 
any debugging information out of it compared to FTP or HTTP.

What are you specifying in the parameter file?  What does the /etc/exports file 
on the NFS server have in it?  What version of NFS is running on the NFS 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://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Installing SLES12 SP2 can't access repository

[Mark Post]

>>> On 7/20/2017 at 10:15 AM, Mauro Souza <thoriu...@gmail.com> wrote: 
> SLES11 worked fine with FTP, if I am not mistaken. SLES12 don't.

That's just not true.  I mostly use FTP in my testing, and it worked just fine 
for me, every time.  You have to make sure you understand how the FTP server is 
set up, and whether you're using anonymous or non-anonymous access.  Then you 
have to make sure you specify the correct path to the repository during the 
install.


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: Installing SLES12 SP2 can't access repository

[Mauro Souza]

Yes Alan, I know and agree, and I already got scolded by Mark the last time
I said so.

But I don't think most of us work on an environment where "let's try again,
file a bug report, send the logs, and install AFTER the fix is available"
is something possible. Or let's just reinstall a dummy machine using FTP to
get this bug fixed.

There's not enough time, there's less people on the team than we should
have, and HTTP works (for now). So we forget FTP and move on.

Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.

2017-07-20 11:54 GMT-03:00 Alan Altmark <alan_altm...@us.ibm.com>:

> On Thursday, 07/20/2017 at 02:16 GMT, Mauro Souza <thoriu...@gmail.com>
> wrote:
> > SLES11 worked fine with FTP, if I am not mistaken. SLES12 don't.
> >
> > We gave up on FTP and used HTTP on the repositories. FTP implementation
> on
> > yast is buggy right now, and it's way faster to just enter the directory
> > and run "python -m SimpleHTTPServer" than to fill a bug request, send
> lots
> > of logs, run strace/ptrace here and there, and wait for a fix.
>
> If no one opens a bug report, it won't get fixed, and you risk the
> function being removed.  If someone has a problem (ftp, nfs, http), call
> it into your support provider.  Sometimes the fixes are as simple as
> including more information in the error messages so that you can correct
> an administrative error (unknown if that's the problem in this case).
>
> Alan Altmark
>
> Senior Managing z/VM and Linux Consultant
> Lab Services System z Delivery Practice
> IBM Systems & Technology Group
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> 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: Installing SLES12 SP2 can't access repository

[Alan Altmark]

On Thursday, 07/20/2017 at 02:16 GMT, Mauro Souza <thoriu...@gmail.com> 
wrote:
> SLES11 worked fine with FTP, if I am not mistaken. SLES12 don't.
>
> We gave up on FTP and used HTTP on the repositories. FTP implementation 
on
> yast is buggy right now, and it's way faster to just enter the directory
> and run "python -m SimpleHTTPServer" than to fill a bug request, send 
lots
> of logs, run strace/ptrace here and there, and wait for a fix.

If no one opens a bug report, it won't get fixed, and you risk the 
function being removed.  If someone has a problem (ftp, nfs, http), call 
it into your support provider.  Sometimes the fixes are as simple as 
including more information in the error messages so that you can correct 
an administrative error (unknown if that's the problem in this case).

Alan Altmark

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

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

Re: Installing SLES12 SP2 can't access repository

[Mauro Souza]

SLES11 worked fine with FTP, if I am not mistaken. SLES12 don't.

We gave up on FTP and used HTTP on the repositories. FTP implementation on
yast is buggy right now, and it's way faster to just enter the directory
and run "python -m SimpleHTTPServer" than to fill a bug request, send lots
of logs, run strace/ptrace here and there, and wait for a fix.

Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.

2017-07-19 19:06 GMT-03:00 Julie Phinney <jphin...@humana.com>:

> Back in April you all talked about a problem someone had installing SLES12
> sp2,  zvm 6.4, using FTP.
> Several people recommended burning the iso to dvd and installing from that.
> One person said they created a symbolic link to the mounted .iso  in the
> ftp user's home directory.
>
> I'm using an NFS mount.  Before starting the yast.ssh script to do the
> install, I can access the mount and its data just fine.
> I run the yast.ssh script and it fails with the same error some of you had
> in the April chat  - mount.nfs access denied  trying to access the
> repository.
> Has anyone gotten an NFS mounted install to work after having this problem?
> I'm not seeing any errors logged on the NFS server.
>
> Julie Phinney
>
> The information transmitted is intended only for the person or entity to
> which it is addressed
> and may contain CONFIDENTIAL material.  If you receive this
> material/information in error,
> please contact the sender and delete or destroy the material/information.
>
> --
> 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/

Installing SLES12 SP2 can't access repository

[Julie Phinney]

Back in April you all talked about a problem someone had installing SLES12 sp2, 
 zvm 6.4, using FTP.
Several people recommended burning the iso to dvd and installing from that.
One person said they created a symbolic link to the mounted .iso  in the ftp 
user's home directory.

I'm using an NFS mount.  Before starting the yast.ssh script to do the install, 
I can access the mount and its data just fine.
I run the yast.ssh script and it fails with the same error some of you had in 
the April chat  - mount.nfs access denied  trying to access the repository.
Has anyone gotten an NFS mounted install to work after having this problem?
I'm not seeing any errors logged on the NFS server.

Julie Phinney

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

--
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: Oracle DB Certification on SLES12

[Jorge Fábregas]

On 05/11/2017 08:02 PM, Dominic Coulombe wrote:
> Is this what you're looking for?
>
> http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10877

Hi Dominic,

You've nailed it!  Thanks for the link!  I had no idea about these
Techdocs Library Flashes!

I'm glad to hear it's finally certified!  We'll be testing it shortly.

Thank you!

Regards,
Jorge

--
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: Oracle DB Certification on SLES12

[Dominic Coulombe]

Hello,

Is this what you're looking for?

IBM Techdocs Flash: SUSE® Linux Enterprise Server Version 12 available on
IBM LinuxONE™ and IBM z Systems® running with Oracle® Database 12c Release 1

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10877

*Abstract:* This Flash describes the availability of SLES 12 for Linux
running on z Systems and LinuxONE with Oracle Database Version 12cR1.

Hope this helps.

Have a nice day.


On May 11, 2017 14:43, "Jorge Fábregas"  wrote:

Hi everyone,

Does anyone here knows if we will ever see Oracle certify its DB against
SLES 12 on s390x?  It has been a while since they certified it against x86.

If I ask IBM about it they (appropriately) tell me to ask Oracle. If I
ask Oracle they tell me to open a support case.  If I open a case they
just send me to the current certification matrix. It's a mystery.

We'd like to know about this before SLES 11's General Support ends in 2
years.

Thanks!

Best regards,
Jorge

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

Oracle DB Certification on SLES12

[Jorge Fábregas]

Hi everyone,

Does anyone here knows if we will ever see Oracle certify its DB against
SLES 12 on s390x?  It has been a while since they certified it against x86.

If I ask IBM about it they (appropriately) tell me to ask Oracle. If I
ask Oracle they tell me to open a support case.  If I open a case they
just send me to the current certification matrix. It's a mystery.

We'd like to know about this before SLES 11's General Support ends in 2
years.

Thanks!

Best regards,
Jorge

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

Re: SLES12 boot error after clone

[Marcy Cortes]

Yes, my stuff gets the UUID out of everything and using by-path instead.
You get different UUIDs on different minidisks.


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Dave Myers
Sent: Tuesday, May 9, 2017 9:46 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SLES12 boot error after clone

Thanks for the replies.  We are going to try Marcy's script and see if that 
works.  I'll report back.

To clarify a few of my original comments:


1.  The source volumes were flash-copied to the equivalent virtual device 
numbers.  200>200  201>201

2.  201 is the root   (for both source/target)

3.  In /etc/default/grubwe have statements referencing 200  (not 201).  
So I'm guessing Marcy is correct that the boot process is ignoring those 
incorrect device numbers and using UUID. So after FC the targets have incorrect 
UUID ?  So, her script changes boot process to not use UUID and use  by-path  ??


From: Dave Myers
Sent: Monday, May 08, 2017 5:57 PM
To: 'LINUX-390@VM.MARIST.EDU' <LINUX-390@VM.MARIST.EDU>
Subject: SLES12 boot error after clone

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

At boot on the clone we get:

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


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

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

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


Thanks,
Dave



This message (including any attachments) is intended only for the use of the 
individual or entity to which it is addressed and may contain information that 
is non-public, proprietary, privileged, confidential, and exempt from 
disclosure under applicable law. If you are not the intended recipient, you are 
hereby notified that any use, dissemination, distribution, or copying of this 
communication is strictly prohibited. This message may be viewed by parties at 
Sirius Computer Solutions other than those named in the message header. This 
message does not contain an official representation of Sirius Computer 
Solutions. If you have received this communication in error, notify Sirius 
Computer Solutions immediately and (i) destroy this message if a facsimile or 
(ii) delete this message immediately if this is an electronic communication. 
Thank you.

Sirius Computer Solutions<http://www.siriuscom.com>

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

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

Re: SLES12 boot error after clone

[Dave Myers]

Thanks for the replies.  We are going to try Marcy's script and see if that 
works.  I'll report back.

To clarify a few of my original comments:


1.  The source volumes were flash-copied to the equivalent virtual device 
numbers.  200>200  201>201

2.  201 is the root   (for both source/target)

3.  In /etc/default/grubwe have statements referencing 200  (not 201).  
So I'm guessing Marcy is correct that the boot process is ignoring those 
incorrect device numbers and using UUID. So after FC the targets have incorrect 
UUID ?  So, her script changes boot process to not use UUID and use  by-path  ??


From: Dave Myers
Sent: Monday, May 08, 2017 5:57 PM
To: 'LINUX-390@VM.MARIST.EDU' <LINUX-390@VM.MARIST.EDU>
Subject: SLES12 boot error after clone

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

At boot on the clone we get:

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


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

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

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


Thanks,
Dave



This message (including any attachments) is intended only for the use of the 
individual or entity to which it is addressed and may contain information that 
is non-public, proprietary, privileged, confidential, and exempt from 
disclosure under applicable law. If you are not the intended recipient, you are 
hereby notified that any use, dissemination, distribution, or copying of this 
communication is strictly prohibited. This message may be viewed by parties at 
Sirius Computer Solutions other than those named in the message header. This 
message does not contain an official representation of Sirius Computer 
Solutions. If you have received this communication in error, notify Sirius 
Computer Solutions immediately and (i) destroy this message if a facsimile or 
(ii) delete this message immediately if this is an electronic communication. 
Thank you.

Sirius Computer Solutions<http://www.siriuscom.com>

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

Re: SLES12 boot error after clone

[Mark Post]

>>> On 5/8/2017 at 07:57 PM, Dave Myers <dave.my...@siriuscom.com> wrote: 
> A bootable SLES12 SP1 system was cloned using flashcopy.
> All minidisks on the clone are the same virtual address.
> 
> At boot on the clone we get:
> 
> IPL 201
> Booting default (grub2)
> dasd-eckd 42a207:  0.0.0200:  The specified record was not found.
> 
> 
> 1.  What's the most likely cause for this error?
> 
> 2.  What script/files do we need to tweak to fix it ?
> 
> Note:  On the golden copy, 200 is the root,  201 is a swap file.

I'm not quite sure what you mean by this.  When you say "golden copy" do you 
mean the source system, or the target system?  If 200 is the root file system, 
why are you trying to IPL from 201?


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 boot error after clone

[Scott Rohling]

I also think not swapping addresses around might help avoid errors and at
least confusion...what is the point of cloning 200 > 201 and 201 > 200
? Have you tried readdressing your disks to match the guest you cloned
from?

Scott Rohling

On Tue, May 9, 2017 at 8:26 AM, Stefan Haberland <s...@linux.vnet.ibm.com>
wrote:

> Hi,
>
> unfortunately I am not that deep into flashcopy, so please excuse if I
> assume something wrong.
>
> On 09.05.2017 01:57, Dave Myers wrote:
>
>> A bootable SLES12 SP1 system was cloned using flashcopy.
>> All minidisks on the clone are the same virtual address.
>>
>
> Do the minidisks have exactly the same size? Or is it possible that you
> cloned only parts of the disk?
>
>
>> At boot on the clone we get:
>>
>> IPL 201
>> Booting default (grub2)
>> dasd-eckd 42a207:  0.0.0200:  The specified record was not found.
>>
>> 1.  What's the most likely cause for this error?
>>
>
> That the disk is not fully formatted or (more unlikely) it is defective.
>
>
>> 2.  What script/files do we need to tweak to fix it ?
>>
>
> dasdfmt will format the whole disk but this would destroy all cloned
> data and might not be what you want.
>
> I suggest that the disks should have exactly the same size and
> everything should be cloned. If this is not possible for some reason you
> could format the target disk using dasdfmt (or if the source disk was
> formatted with another tool use this one) before cloning. Please note
> that you have to use the same disk format and blocksize as for the
> source disk.
>
> Regards,
> Stefan
>
>
> --
> 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: SLES12 boot error after clone

[Steffen Maier]

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

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

At boot on the clone we get:

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


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



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

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

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


Thanks,
Dave


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

Linux on z Systems Development

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

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

Re: SLES12 boot error after clone

[Marcy Cortes]

Oh wait, step 3 isn't necessary at some point in the dracut service stream.
SUSE created a /etc/dracut.conf.d/10-s390x_persistent_device.conf file which 
includes the persistent_policy=by-path thing

Not sure if you have that on - from rpm -q dracut --changelong
* Fri Dec 23 2016 tr...@suse.de
- Find devices by path for S390x (bsc#915218)
  * add s390x_persistent_device.conf

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy 
Cortes
Sent: Tuesday, May 9, 2017 7:58 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SLES12 boot error after clone

It's probably using UUID and not the 0200 address

Here's the things I had to do to allow clones and allow it to run in other 
places after a flashcopy.

1. Added root=/dev/disk/by-path/ccw-0.0.0101-part1   to the kernel parms (under 
yast2, system, bootloader)  (101 is our IPL address)
2. In /etc/default/grub
GRUB_DISABLE_LINUX_UUID=true
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"
SUSE_REMOVE_LINUX_ROOT_PARAM=true

And then rungrub2-mkconfig -o /boot/grub2/grub.cfg

3.  echo 'persistent_policy=by-path' >> /etc/dracut.conf
grub2-install
dracut -f


This was on SLES 12 SP2.   We didn't attempt SP1.




-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Dave Myers
Sent: Monday, May 8, 2017 4:57 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SLES12 boot error after clone

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

At boot on the clone we get:

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


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

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

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


Thanks,
Dave



This message (including any attachments) is intended only for the use of the 
individual or entity to which it is addressed and may contain information that 
is non-public, proprietary, privileged, confidential, and exempt from 
disclosure under applicable law. If you are not the intended recipient, you are 
hereby notified that any use, dissemination, distribution, or copying of this 
communication is strictly prohibited. This message may be viewed by parties at 
Sirius Computer Solutions other than those named in the message header. This 
message does not contain an official representation of Sirius Computer 
Solutions. If you have received this communication in error, notify Sirius 
Computer Solutions immediately and (i) destroy this message if a facsimile or 
(ii) delete this message immediately if this is an electronic communication. 
Thank you.

Sirius Computer Solutions<http://www.siriuscom.com>

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

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.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: SLES12 boot error after clone

[Marcy Cortes]

It's probably using UUID and not the 0200 address

Here's the things I had to do to allow clones and allow it to run in other 
places after a flashcopy.

1. Added root=/dev/disk/by-path/ccw-0.0.0101-part1   to the kernel parms (under 
yast2, system, bootloader)  (101 is our IPL address)
2. In /etc/default/grub
GRUB_DISABLE_LINUX_UUID=true
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"
SUSE_REMOVE_LINUX_ROOT_PARAM=true

And then rungrub2-mkconfig -o /boot/grub2/grub.cfg

3.  echo 'persistent_policy=by-path' >> /etc/dracut.conf
grub2-install
dracut -f


This was on SLES 12 SP2.   We didn't attempt SP1.




-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Dave Myers
Sent: Monday, May 8, 2017 4:57 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] SLES12 boot error after clone

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

At boot on the clone we get:

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


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

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

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


Thanks,
Dave



This message (including any attachments) is intended only for the use of the 
individual or entity to which it is addressed and may contain information that 
is non-public, proprietary, privileged, confidential, and exempt from 
disclosure under applicable law. If you are not the intended recipient, you are 
hereby notified that any use, dissemination, distribution, or copying of this 
communication is strictly prohibited. This message may be viewed by parties at 
Sirius Computer Solutions other than those named in the message header. This 
message does not contain an official representation of Sirius Computer 
Solutions. If you have received this communication in error, notify Sirius 
Computer Solutions immediately and (i) destroy this message if a facsimile or 
(ii) delete this message immediately if this is an electronic communication. 
Thank you.

Sirius Computer Solutions<http://www.siriuscom.com>

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

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.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: Rexx for SLES12?

[Mark Post]

>>> On 5/8/2017 at 06:54 PM, Ted Rodriguez-Bell <te...@wellsfargo.com> wrote: 
> One of our users has and likes Regina on his SLES 11SP4 servers.  He's 
> getting upgraded to 12SP2, and Regina isn't there any longer.  Am I missing a 
> software channel?  Is there another Rexx implementation that will work on 
> SLES12?
> I can install the 11SP4 Regina and run a "hello, world" program, but that's 
> unsupported and may not fly with the Powers That Be.

For a long time, Regina was only available on the Software Development Kit 
(SDK) for SLES.  That meant that it was not supported.  Now that the SUSE 
Package Hub has been made available, you can get Regina for all our supported 
architectures there.

https://packagehub.suse.com/

At the bottom of that page are very general instructions on how to get access 
to the Package Hub.  Clicking on the "more..." below that will bring up some 
more details.

Packages from the Package Hub are also not supported by SUSE, but they are 
maintained by the openSUSE community, and bug reports are welcome at 
https://bugzilla.opensuse.org .  By design, installing packages from the 
Package Hub will _not_ invalidate any support agreement you have.


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/

SLES12 boot error after clone

[Dave Myers]

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

At boot on the clone we get:

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


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

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

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


Thanks,
Dave



This message (including any attachments) is intended only for the use of the 
individual or entity to which it is addressed and may contain information that 
is non-public, proprietary, privileged, confidential, and exempt from 
disclosure under applicable law. If you are not the intended recipient, you are 
hereby notified that any use, dissemination, distribution, or copying of this 
communication is strictly prohibited. This message may be viewed by parties at 
Sirius Computer Solutions other than those named in the message header. This 
message does not contain an official representation of Sirius Computer 
Solutions. If you have received this communication in error, notify Sirius 
Computer Solutions immediately and (i) destroy this message if a facsimile or 
(ii) delete this message immediately if this is an electronic communication. 
Thank you.

Sirius Computer Solutions<http://www.siriuscom.com>

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

Rexx for SLES12?

[Ted Rodriguez-Bell]

One of our users has and likes Regina on his SLES 11SP4 servers.  He's getting 
upgraded to 12SP2, and Regina isn't there any longer.  Am I missing a software 
channel?  Is there another Rexx implementation that will work on SLES12?
I can install the 11SP4 Regina and run a "hello, world" program, but that's 
unsupported and may not fly with the Powers That Be.
Thank you!
Ted Rodriguez-Bell
Enterprise Virtualization - z/VM and z/Linux
te...@wellsfargo.com

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.




--
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: Anomaly of EDEV mdisk attachment in SLES12

[Juha Vuori]

On 13.04.2017 17:43, Alan Altmark wrote:

One of the tenets of a secure system is the idea that you do not leave
residual data on a device that has been removed from a server.  It should
be formatted immediately after de-provisioning, prior to placing in the
'available' pool.   The primary purpose is to ensure that confidential or
other sensitive data is deleted since it is no longer under effective
access control.  The side effect is that you don't have to worry about
driver fingerprints, smudged or partial.

You also cleanse a device when it is first added to the pool since you
don't know where it's been or what it's been doing.

This is one of the reasons people like thin provisioning: you effectively
format the device by simply releasing all of the extents. (Writing zeroes
is SO twentieth century.)  Of course, getting people to separate "format"
from "erase" is a tall order.  When all you have is a hammer


Alan,

I fully agree, well put.

In this system, all guests get their disks from a static pool of EDEVICEs.
In the birth of the system, all those SAN disks were empty.
As z/VM does not have any means to provide thin provisioning for minidisks, 
I've tried to follow the
above norm by using the 20th century methods
  DIRM PURGE CLEAN for de-provisioning guests
  DIRM DMDISK CLEAN for de-provisioning single mdisks
I think that meets the security aspects of the policy.
The technical issue I am now wondering is that are the freed blocks formatted 
by DIRM CLEANing
process in a way that sles12.2 drivers don't recognize new minidisks on those 
blocks as fba devices.
If that's the case, I really have to bring my cleaning processes up to the 
century at hand :)
But note: that is not a fact yet! I cannot be sure that just the blocks that 
happened to form the
minidisk I was using in this case were formatted by DIRM CLEAN. I'll have to do 
more tests..
(Our DIRM CLEAN is still in its factory default settings..)

--
Regards,
Juha

--
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: Anomaly of EDEV mdisk attachment in SLES12

[Juha Vuori]

On 13.04.2017 14:03, Stefan Haberland wrote:

You have to mention that the partition detection process is -
independent of the disk type - a hierarchical process. Those partition
detection parts high in the hierarchy are asked first if they would like
to try and possibly take the disk as theirs. Only if they deny or fail
in a proper way the disk gets passed to the next layer. The DASD
specific part is very low in the hierarchy (which is OK since it is
quite uncommon for none s390 systems to have a DASD device). But this
leads to the point that most of the other partition tables overrule the
DASD  part. If there is for example a msdos style partition table that
states you have an empty disk without a partition on the FBA DASD, than
the DASD partition detection will never be asked and there will be no
default partition.
So you always have to take care if you recycle previously used disks.


Thanks Stefan,
now I understand the technical background much better.

--
Regards,
Juha

--
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: Anomaly of EDEV mdisk attachment in SLES12

[Alan Altmark]

On Thursday, 04/13/2017 at 11:05 GMT, Stefan Haberland 
 wrote:
> So you always have to take care if you recycle previously used disks.

One of the tenets of a secure system is the idea that you do not leave 
residual data on a device that has been removed from a server.  It should 
be formatted immediately after de-provisioning, prior to placing in the 
'available' pool.   The primary purpose is to ensure that confidential or 
other sensitive data is deleted since it is no longer under effective 
access control.  The side effect is that you don't have to worry about 
driver fingerprints, smudged or partial.

You also cleanse a device when it is first added to the pool since you 
don't know where it's been or what it's been doing.

This is one of the reasons people like thin provisioning: you effectively 
format the device by simply releasing all of the extents. (Writing zeroes 
is SO twentieth century.)  Of course, getting people to separate "format" 
from "erase" is a tall order.  When all you have is a hammer

Alan Altmark

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

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

Re: Anomaly of EDEV mdisk attachment in SLES12

[Stefan Haberland]

On 12.04.2017 20:54, juha.vu...@pp2.inet.fi wrote:

Trying to add fba mdisk from EDEVICE to sles12.2 guest, and dasd_fba driver 
does not create the full partition node, /dev/dasdh1, for it for some reason:

zlnx030:~ # vmcp link '*' 305 a305 mr
zlnx030:~ # chccwdev -e a305
Setting device 0.0.a305 online
Done
zlnx030:~ # lsdasd a305
Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==
0.0.a305   active  dasdh 94:28   FBA   51210240MB   20971520
zlnx030:~ # ll /dev/dasdh*
brw-rw 1 root disk 94, 28 Apr 12 13:04 /dev/dasdh

Log for setting online:

2017-04-12T13:04:07.613846+03:00 zlnx030 kernel: dasd-fba.f36f2f: 0.0.a305: New 
FBA DASD 9336/10 (CU 6310/80) with 10240 MB and 512 B/blk

but not partition creation happening as in SLES11.4 for the same mdisk:

kernel:  dasdk:(nonl) dasdk1

Seems that this is related to what old garbage you have in the blocks of the 
new mdisk.
Once I dd'd /dev/zero to /dev/dasdh, put it offline and back online, dasd_fba 
did its magic and created the partition /dev/dasdh1.
Seems that the logic in dasd drivers for recognizing the type of a dasd is not 
inclusive, and the latest level drivers in sles11.4 do better job in that than 
the ones in sles12.2.

A bit annoying, but once you know it you can live with it :)
I don't see a point in opening a bug report, now. (Or better, just call me 
lazy.)

--
Regards,
Juha

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


Hi,

you are right, garbage on the disk might lead to other partition
detection code to take it and it _never_ gets to the DASD specific
partition detection.

You have to mention that the partition detection process is -
independent of the disk type - a hierarchical process. Those partition
detection parts high in the hierarchy are asked first if they would like
to try and possibly take the disk as theirs. Only if they deny or fail
in a proper way the disk gets passed to the next layer. The DASD
specific part is very low in the hierarchy (which is OK since it is
quite uncommon for none s390 systems to have a DASD device). But this
leads to the point that most of the other partition tables overrule the
DASD  part. If there is for example a msdos style partition table that
states you have an empty disk without a partition on the FBA DASD, than
the DASD partition detection will never be asked and there will be no
default partition.
So you always have to take care if you recycle previously used disks.

I am not sure why there is this difference between SLES11 and SLES12,
maybe the corresponding partition detection code for the garbage was not
present in SLES11 and now is on SLES12 or whatsoever.

Regards,
Stefan

--
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: Anomaly of EDEV mdisk attachment in SLES12

[juha.vu...@pp2.inet.fi]

>Trying to add fba mdisk from EDEVICE to sles12.2 guest, and dasd_fba driver 
>does not create the full partition node, /dev/dasdh1, for it for some reason:
>
>zlnx030:~ # vmcp link '*' 305 a305 mr
>zlnx030:~ # chccwdev -e a305
>Setting device 0.0.a305 online
>Done
>zlnx030:~ # lsdasd a305
>Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
>==
>0.0.a305   active  dasdh 94:28   FBA   51210240MB   20971520
>zlnx030:~ # ll /dev/dasdh*
>brw-rw 1 root disk 94, 28 Apr 12 13:04 /dev/dasdh
>
>Log for setting online:
>
>2017-04-12T13:04:07.613846+03:00 zlnx030 kernel: dasd-fba.f36f2f: 0.0.a305: 
>New FBA DASD 9336/10 (CU 6310/80) with 10240 MB and 512 B/blk
>
>but not partition creation happening as in SLES11.4 for the same mdisk:
>
>kernel:  dasdk:(nonl) dasdk1

Seems that this is related to what old garbage you have in the blocks of the 
new mdisk.
Once I dd'd /dev/zero to /dev/dasdh, put it offline and back online, dasd_fba 
did its magic and created the partition /dev/dasdh1.
Seems that the logic in dasd drivers for recognizing the type of a dasd is not 
inclusive, and the latest level drivers in sles11.4 do better job in that than 
the ones in sles12.2.

A bit annoying, but once you know it you can live with it :)
I don't see a point in opening a bug report, now. (Or better, just call me 
lazy.)

--
Regards,
Juha

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

Anomaly of EDEV mdisk attachment in SLES12

[juha.vu...@pp2.inet.fi]

Hi

Trying to add fba mdisk from EDEVICE to sles12.2 guest, and dasd_fba driver 
does not create the full partition node, /dev/dasdf1, for it for some reason:

zlnx030:~ # vmcp link '*' 305 a305 mr
zlnx030:~ # chccwdev -e a305
Setting device 0.0.a305 online
Done
zlnx030:~ # lsdasd a305
Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==
0.0.a305   active  dasdh 94:28   FBA   51210240MB   20971520
zlnx030:~ # ll /dev/dasdh*
brw-rw 1 root disk 94, 28 Apr 12 13:04 /dev/dasdh

Log for setting online:

2017-04-12T13:04:07.613846+03:00 zlnx030 kernel: dasd-fba.f36f2f: 0.0.a305: New 
FBA DASD 9336/10 (CU 6310/80) with 10240 MB and 512 B/blk

but not partition creation happening as in SLES11.4 for the same mdisk:

kernel:  dasdk:(nonl) dasdk1

I vaguely recall the same problem has been dealt here before, but I can't 
remember the outcome, was it a bug or a change in the kernel/drivers of 
sles12.2 level..

Just checking if somebody remembers how this case can be tackled before I set 
up a PMR.

Thanks.

--
Regards,
Juha

--
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 Kernel parameter root=/dev/dasd-x

[van Sleeuwen, Berry]

Hi Mark,

Thanks. I missed that one. I now have the correct boot parms.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Thursday, December 22, 2016 8:55 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES12 Kernel parameter root=/dev/dasd-x

>>> On 12/22/2016 at 09:21 AM, "van Sleeuwen, Berry"
>>> <berry.vansleeu...@atos.net>
wrote:

> How can we enforce the root device to be referenced as
> /dev/disk/by-path/ccw-0.0.0100?

http://www2.marist.edu/htbin/wlvtype?LINUX-VM.93689


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

Re: SLES12 Kernel parameter root=/dev/dasd-x

[Alan Ackerman]

http://www2.marist.edu/htbin/wlvtype?LINUX-VM.93689 
 got me:

linux-...@www2.marist.edu post from :
Index 
Previous  Lines: From: 
Subject:
 Sorry,  WLVTYPE  has experienced a serious syntax error. If the error 
persists, contact  Error Report 

That link in turn tries to send email to HARRY@SERVER_NAME.

What's going on here?

Alan Ackerman
alan.ackerma...@gmail.com




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

Re: SLES12 Kernel parameter root=/dev/dasd-x

[Mark Post]

>>> On 12/22/2016 at 09:21 AM, "van Sleeuwen, Berry" 
>>> 
wrote: 

> How can we enforce the root device to be referenced as 
> /dev/disk/by-path/ccw-0.0.0100?

http://www2.marist.edu/htbin/wlvtype?LINUX-VM.93689


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/

SLES12 Kernel parameter root=/dev/dasd-x

[van Sleeuwen, Berry]

Hi All,

Some time ago there was a thread discussing the kernel parameter root=/dev/xxx. 
It was noted that this refers by default to an UUID. In order to remove the 
UUID reference, I have added “persistent_policy=by-path” to the 
/etc/dracut.conf file.

After rebuilding indeed the parameter is now changed. However, root is now 
referenced as root=/dev/dasda1. So far so good, indeed the root device is 
/dev/dasda1. And the system booted, most of the time.

Now I have been trying to reboot the guest quite a few times, but the boot has 
halted every time when it wants to try to mount /sysroot. After some 
investigation I have found the cause. Device 100 and 101 are switched. Device 
101 is now /dev/dasda and 100 is dev/dasdb. So now the swap device is to be 
mounted on /sysroot, obviously that fails.

How can we enforce the root device to be referenced as 
/dev/disk/by-path/ccw-0.0.0100? Based on the dracut parameter I would have 
expected the root device would be referenced to as by-path, but that’s not the 
case at this moment.


Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven
• +31 (0)6 22564276
 [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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.

Linux on z Systems: new documentation for SLES12 SP2

[Dorothea Matthaeus]

The following Linux on z Systems publications for SUSE Linux Enterprise
Sever 12 SP2 are now available at IBM Knowledge Center and developerWorks:

http://www.ibm.com/support/knowledgecenter/linuxonibm/liaaf/lnz_r_s122.html
http://www.ibm.com/developerworks/linux/linux390/documentation_suse.html




This document describes the device drivers available to SUSE Linux
Enterprise Server 12 SP2 as a KVM guest for the control of z Systems
devices and attachments.
It also provides information on commands and parameters relevant to
configuring Linux on z Systems as a KVM guest.


This publication describes the device drivers and features available to
SUSE Linux Enterprise Server 12 SP2 for the control of z Systems devices
and attachments.
It also provides information on commands and parameters relevant to
configuring Linux on z Systems.


This message reference document contains the messages that IBM z Systems
specific kernel modules issue on the console and write to the syslog.






Dorothea Matthaeus
Linux on z Systems Information Development
IBM Deutschland Research and Development GmbH


--
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: LVM on unpartitioned disks (Was: RE: SLES12 + EDEV + bug)

[van Sleeuwen, Berry]

Hi Mark,

Indeed I didn't expect SP3 would be entitled for it, but SP4 might. We do have 
a support agreement. So we could go that path or move into SLES12 SP1 asap. I 
guess the latter would be even a better option. We do plan for SLES12 and this 
server would be one of the first to go into the new version anyway.

Thanks for explaining the patch comment. Good to know it still works for LDL 
disks.

Actually I had to get the lvm2 package from another SP3 source disk and 
installed it with rpm. We are now back on the SP3 base version and the LVM is 
mounted once again.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Tuesday, July 05, 2016 7:18 PM
To: LINUX-390@VM.MARIST.EDU
Subject: LVM on unpartitioned disks (Was: RE: SLES12 + EDEV + bug)

>>> On 7/1/2016 at 07:55 PM, "van Sleeuwen, Berry"
>>> <berry.vansleeu...@atos.net>
wrote:
> I have been looking for the fix for bug 948859. Indeed I found an
> update in the SLES12 SP1 fixes. Might this fix become available for SLES11 as 
> well?

SLES11 SP3 is out of support unless your site purchased Long-Term Servicepack 
Support.

If you don't have LTSS, but you have a support agreement, you might be able to 
get a fix for this in SLES11 SP4.

> Also, the comment in the patch states: "Allow creation of PVs on
> unpartitioned DASD devices formatted with CDL. (bsc#948859,
>   bsc##946217)". Is the only for CDL disks and not for LDL disks?

What the comment says is actually "Only not support unpartitioned DASD device 
with CDL formatted. (bnc#948859#946217)"  Which, when you unwind the statement, 
means LDL formatted DASD volumes will be supported, whether a partition was 
used (/dev/dasd?1) or not (/dev/dasd?).  CDL formatted volumes will only be 
supported if a partition was used.

> Today I have updated an SLES11 SP3 and I can't access the LVM anymore.
> This is an LVM based on unpartitioned LDL formatted disks.

If you don't have a support agreement and can't get a fix that way, you can 
revert the update to lvm2:
zypper in --oldpackage lvm2-${version}
where ${version} is the prior version you had installed.


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