Re: Adding disk to root LVM with RHEL 7

2020-04-16 Thread Martha McConaghy
Thanks, Jan.  You identified the problem.  I failed to put the disk in 
/etc/zipl.conf before doing zipl.  A colleague and I managed to stumble onto 
that after some struggle last night.  I didn't see your email until this 
morning, but the link is just what I needed.  It looks familiar, I bet I have 
read it before, but had just forgotten about it.  I don't work with RHEL that 
often.  You can bet it is bookmarked now.

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Vice President

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Jan Stodola 

Sent: Thursday, April 16, 2020 3:36 AM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Adding disk to root LVM with RHEL 7

On Wed, Apr 15, 2020 at 10:29 PM Martha McConaghy <
martha.mccona...@marist.edu> wrote:

> I feel like Alice through the looking glass at this point.  I was hopeful
> that mkinitrd would do the trick, but now I have a whole new problem.
> After bringing the disk online, adding it to /etc/dasd.conf, I ran mkinitrd
> and zipl.  Then, I rebooted.  I did NOT touch the LVM, or anything, at that
> point.  This resulted in a bunch of dracut timeout errors and am now in
> dracut emergency mode.  I'm about to give up and just give this darned
> thing a TB LUN and be done with it.  But, this shouldn't be so hard for
> crying out loud.  Its bugging me that I don't know what I'm doing wrong.
> The RedHat web site lets me log in, but won't show me their solution
> pagesarggg.
>

Hi Martha,
check the steps in the RHEL-7 documentation, there is no need to log in:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-post-installation-configuration-s390#sect-post-installation-adding-dasds-s390
You should not need to re-create initrd if you specify the new DASD device
ID on the kernel command line.


>
> So, any thoughts?
>
> Martha
>
> Pre-reboot:
>
> [root@opncl42 ~]# cio_ignore -l
> Ignored devices:
> =
> [root@opncl42 ~]# chccwdev --online 0.0.0200
> Setting device 0.0.0200 online
> Done
> [root@opncl42 ~]# lsdasd
> Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
>
> ==
> 0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
> 0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
> [root@opncl42 ~]# vi /etc/dasd.conf
> [root@opncl42 ~]#  mkinitrd -f /boot/initramfs-3.10.0-1127.el7.s390x.img
> 3.10.0-1127.el7.s390x
> [root@opncl42 ~]# zipl
> Using config file '/etc/zipl.conf'
> Building bootmap in '/boot'
> Building menu 'zipl-automatic-menu'
> Adding #1: IPL section '3.10.0-1127.el7.s390x' (default)
> Adding #2: IPL section '3.10.0-1127.el7.s390x_with_debugging'
> Adding #3: IPL section 'linux'
> Preparing boot device: dasda (0150).
> Done.
> [root@opncl42 ~]# reboot
>
> Post-reboot:
>
> Ý"Ý32m  OK  "Ý0m+ Reached target System Initialization.
> Ý1.149462+ dasd-eckd 0.0.0150: A channel path to the device has become
> opera
> tional
> Ý1.151741+ dasd-eckd 0.0.0150: New DASD 3390/0C (CU 3990/01) with
> 65519 cyli
> nders, 15 heads, 224 sectors
> Ý1.153040+ dasd-eckd 0.0.0150: DASD with 4 KB/block, 47173680 KB total
> size,
>  48 KB/track, linux disk layout
> Ý1.153145+ qeth: register layer 2 discipline
>
> Ý1.154257+ qdio: 0.0.0702 OSA on SC 5 using AI:1 QEBSM:0 PRI:1 TDD:1
> SIGA:RW
>  A
> Ý1.155122+  dasda:VOL1/  0X0150: dasda1 dasda2
> Ý1.156584+ dasd-eckd 0.0.0200: A channel path to the device has become
> opera
> tional
> Ý1.159045+ dasd-eckd 0.0.0200: New DASD 3390/0C (CU 3990/01) with
> 32759 cyli
> nders, 15 heads, 224 sectors
> Ý1.159581+ dasd-eckd 0.0.0200: DASD with 4 KB/block, 23586480 KB total
> size,
>  48 KB/track, compatible disk layout
> Ý1.160634+  dasdb:VOL1/  0X0200: dasdb1
> Ý"Ý32m  OK  "Ý0m+ Started Show Plymouth Boot Screen.""
> Ý"Ý32m  OK  "Ý0m+ Reached target Paths.""
> Ý"Ý32m  OK  "Ý0m+ Started Forward Password Requests to Plymouth Directory
> Watch.
> ""
> Ý"Ý32m  OK  "Ý0m+ Reached target Basic System.""
> Ý1.169428+ netif_napi_add() called with weight 128 on device eth%d
> Ý1.169600+ qeth 0.0.0700: MAC address 02:01:42:00:00:08 successfully
> registered on device eth0
> Ý1.169613+ qeth 0.0.0700: Device is a Virtual NIC QDIO card (level:
> V712)
> Ý1.169613+ with link type Virt.NIC QDIO (portname: )
> Ý  124.355856+ dracut-initqueueÝ363+: Warning: dracut-initqueue timeout -
> starting timeout scripts""
> Ý  

Re: Adding disk to root LVM with RHEL 7

2020-04-16 Thread Jan Stodola
tering emergency mode. Exit the shell to continue.
> Type "journalctl" to view system logs.
> You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or
> /boot
> after mounting them and attach it to a bug report.
>
>
>
>
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Vice President
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of Marcy
> Cortes 
> Sent: Wednesday, April 15, 2020 11:42 AM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Adding disk to root LVM with RHEL 7
>
> I'm kind of assuming RH7 works like sles11 and doesn't use grub2, but did
> you "mkinird; zipl" after getting that disk online?
>
> You can also "cat / run/initramfs/rdsosreport.txt" in that emergency mode
> to get more details.
>
>
>
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Rick Troth
> Sent: Wednesday, April 15, 2020 8:26 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: [LINUX-390] Adding disk to root LVM with RHEL 7
>
> Looks like you did everything right: online, dasdfmt, fdasd, lvextend,
> vgextend, and using "1" instead of the whole disk (because it's ECKD and
> requires the VTOC).
>
> The first block where you get an error is 16380912. Maybe that's a clue?
> Looks like cylinder #109206 (150 4K blocks per ECKD cyl). Someone check
> my math? And the (new) root FS looks like 110100 cyls.
> The VG has two disks, correct? How big are they?
> So where is this troublesome block in the grand scheme?
>
> I don't recall resizing a filesystem *down*, but I think it can be done.
> I'm always nervous about that last block (or several) in any filesystem,
> any backing store (CKD, FBA, SCSI/SAN), anymode (LVM, partitioned, whole).
> Never know when the system or some program will walk to the end "just
> because".
>
> -- R; <><
>
>
> On 4/15/20 10:58 AM, Martha McConaghy wrote:
> > I have servers that I'm setting up with RHEL 7.8 on ECKD disk.  I
> installed it with root in an LVM, all of that worked fine.  Now, I'm
> testing adding a 2nd ECKD disk to the LVM as I know that will be required
> in the future, but I'm running into a confusing problem.  Everything works
> as I expect and the disk space shows up in / as it should.  When I reboot
> the server, however, it goes to heck and ends up in emergency mode.  The
> most prominent feature of the console are a bunch of I/O errors on device
> dm-2, which is the disk I just added.  Below are the steps I followed to
> add the disk.  Before doing this, I had activated the disk, added it to
> /etc/dasd.conf and run zipl.  After doing that, I rebooted to ensure that
> the disk came up online, which it did.  So, I'm confident that the disk is
> there when the system rebooted the 2nd time.
> >
> > I have a lot of colleagues who work with Linux all the time, but don't
> usually have root as an LVM.  They haven't seen this problem before, but
> they work mainly on X.  Could this be specific problem to using ECKD?  I
> have thought of going to an FBA LUN, but had spare ECKD to use.
> >
> > Martha
> >
> >
> > [root@opncl42 ~]# cio_ignore -r 0.0.0200
> > [root@opncl42 ~]# chccwdev --online 0.0.0200
> > Setting device 0.0.0200 online
> > Done
> > [root@opncl42 ~]# lsdasd
> > Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
> >
> ==
> > 0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
> > 0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
> > [root@opncl42 ~]# vi /etc/dasd.conf
> > [root@opncl42 ~]# zipl
> > Using config file '/etc/zipl.conf'
> > Building bootmap in '/boot'
> > Building menu 'zipl-automatic-menu'
> > Adding #1: IPL section '3.10.0-1127.el7.s390x' (default)
> > Adding #2: IPL section '3.10.0-1127.el7.s390x_with_debugging'
> > Adding #3: IPL section 'linux'
> > Preparing boot device: dasda (0150).
> > Done.
> > [root@opncl42 ~]# reboot
> > ---
> > [root@opncl42 ~]# lsdasd
> > Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
> >
> ==
> > 0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
> > 0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
> >
> > [root@opncl42 ~]# dasdfmt -p -f /dev/dasdb
> >

Re: Adding disk to root LVM with RHEL 7

2020-04-15 Thread Dan Horák
Hi Martha,

On Wed, 15 Apr 2020 20:25:37 +
Martha McConaghy  wrote:

> I feel like Alice through the looking glass at this point.  I was
> hopeful that mkinitrd would do the trick, but now I have a whole new
> problem.  After bringing the disk online, adding it
> to /etc/dasd.conf, I ran mkinitrd and zipl.  Then, I rebooted.  I did
> NOT touch the LVM, or anything, at that point.  This resulted in a
> bunch of dracut timeout errors and am now in dracut emergency mode.
> I'm about to give up and just give this darned thing a TB LUN and be
> done with it.  But, this shouldn't be so hard for crying out loud.
> Its bugging me that I don't know what I'm doing wrong.  The RedHat
> web site lets me log in, but won't show me their solution
> pagesarggg.
> 
> So, any thoughts?

hmm, this looks strange

have you changed the partition type to "LVM" in fdasd for the new DASD?

what does "lvm pvs" or "lvm vgs" in the emergency shell say?

If I see right, then kernel sees both the DASDs, so the problem will be
in LVM.


Dan

> 
> Martha
> 
> Pre-reboot:
> 
> [root@opncl42 ~]# cio_ignore -l
> Ignored devices:
> =
> [root@opncl42 ~]# chccwdev --online 0.0.0200
> Setting device 0.0.0200 online
> Done
> [root@opncl42 ~]# lsdasd
> Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
> ==
> 0.0.0150   active  dasda 94:0ECKD  4096   46068MB
> 11793420 0.0.0200   active  dasdb 94:4ECKD  4096
> 23033MB   5896620 [root@opncl42 ~]# vi /etc/dasd.conf
> [root@opncl42 ~]#  mkinitrd
> -f /boot/initramfs-3.10.0-1127.el7.s390x.img 3.10.0-1127.el7.s390x
> [root@opncl42 ~]# zipl Using config file '/etc/zipl.conf'
> Building bootmap in '/boot'
> Building menu 'zipl-automatic-menu'
> Adding #1: IPL section '3.10.0-1127.el7.s390x' (default)
> Adding #2: IPL section '3.10.0-1127.el7.s390x_with_debugging'
> Adding #3: IPL section 'linux'
> Preparing boot device: dasda (0150).
> Done.
> [root@opncl42 ~]# reboot
> 
> Post-reboot:
> 
> Ý"Ý32m  OK  "Ý0m+ Reached target System Initialization.
> Ý1.149462+ dasd-eckd 0.0.0150: A channel path to the device has
> become opera tional
> Ý1.151741+ dasd-eckd 0.0.0150: New DASD 3390/0C (CU 3990/01) with
> 65519 cyli nders, 15 heads, 224 sectors
> Ý1.153040+ dasd-eckd 0.0.0150: DASD with 4 KB/block, 47173680 KB
> total size, 48 KB/track, linux disk layout
> Ý1.153145+ qeth: register layer 2 discipline
> 
> Ý1.154257+ qdio: 0.0.0702 OSA on SC 5 using AI:1 QEBSM:0 PRI:1
> TDD:1 SIGA:RW A
> Ý1.155122+  dasda:VOL1/  0X0150: dasda1 dasda2
> Ý1.156584+ dasd-eckd 0.0.0200: A channel path to the device has
> become opera tional
> Ý1.159045+ dasd-eckd 0.0.0200: New DASD 3390/0C (CU 3990/01) with
> 32759 cyli nders, 15 heads, 224 sectors
> Ý1.159581+ dasd-eckd 0.0.0200: DASD with 4 KB/block, 23586480 KB
> total size, 48 KB/track, compatible disk layout
> Ý1.160634+  dasdb:VOL1/  0X0200: dasdb1
> Ý"Ý32m  OK  "Ý0m+ Started Show Plymouth Boot Screen.""
> Ý"Ý32m  OK  "Ý0m+ Reached target Paths.""
> Ý"Ý32m  OK  "Ý0m+ Started Forward Password Requests to Plymouth
> Directory Watch. ""
> Ý"Ý32m  OK  "Ý0m+ Reached target Basic System.""
> Ý1.169428+ netif_napi_add() called with weight 128 on device eth%d
> Ý1.169600+ qeth 0.0.0700: MAC address 02:01:42:00:00:08
> successfully registered on device eth0 Ý1.169613+ qeth 0.0.0700:
> Device is a Virtual NIC QDIO card (level: V712) Ý1.169613+ with
> link type Virt.NIC QDIO (portname: ) Ý  124.355856+
> dracut-initqueueÝ363+: Warning: dracut-initqueue timeout - starting
> timeout scripts"" Ý  124.862823+ dracut-initqueueÝ363+: Warning:
> dracut-initqueue timeout - starting timeout scripts"" Ý  125.366826+
> dracut-initqueueÝ363+: Warning: dracut-initqueue timeout - starting
> timeout scripts"" ...lots of timeout script errors... Ý
> 184.424496+ dracut-initqueueÝ363+: Warning: dracut-initqueue timeout
> - starting timeout scripts"" Ý  184.424755+ dracut-initqueueÝ363+:
> Warning: Could not boot."" Ý  184.425825+ dracut-initqueueÝ363+:
> Warning: /dev/mapper/rhel_opncl41-root does not exist" Starting
> Dracut Emergency Shell..." Warning: /dev/mapper/rhel_opncl41-root
> does not exist
> 
> Generating "/run/initramfs/rdsosreport.txt"
> 
> 
> Entering emergency mode. Exit the shell to continue.
> Type "journalctl" to view system logs.
> You might want to save "/run/initramfs/rdsosreport.txt"

Re: Adding disk to root LVM with RHEL 7

2020-04-15 Thread Marcy Cortes
I'm with you, Alice:)  I had a weird one over the weekend with similar errors 
on a server and fought with it for hours (couldn't get a path).  I eventually 
moved it to a different volume and it worked.  Then moved it back and it didn't.
then cpfmtxa'd the volume and all was well.  I opened a PRM with VM since I 
don't see how that could have been Linux or the HW.  The volume I moved to was 
right next door on the same LCU. 

Anyway, that's not your problem :)

cat that file called /run/initramfs/rdsosreport.txt  when you are in the Dracut 
emergency shell and cut and paste it here. 

We did have a similar thing with new disks like you had when we went to sles 12 
sp4 on several servers, but there was a SUSE bug that was fixed.  The udev 
rules were named differently and I suspect that had something to do with it.  
Mark P may know more details. 





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

I feel like Alice through the looking glass at this point.  I was hopeful that 
mkinitrd would do the trick, but now I have a whole new problem.  After 
bringing the disk online, adding it to /etc/dasd.conf, I ran mkinitrd and zipl. 
 Then, I rebooted.  I did NOT touch the LVM, or anything, at that point.  This 
resulted in a bunch of dracut timeout errors and am now in dracut emergency 
mode.  I'm about to give up and just give this darned thing a TB LUN and be 
done with it.  But, this shouldn't be so hard for crying out loud.  Its bugging 
me that I don't know what I'm doing wrong.  The RedHat web site lets me log in, 
but won't show me their solution pagesarggg.

So, any thoughts?

Martha

Pre-reboot:

[root@opncl42 ~]# cio_ignore -l
Ignored devices:
=
[root@opncl42 ~]# chccwdev --online 0.0.0200
Setting device 0.0.0200 online
Done
[root@opncl42 ~]# lsdasd
Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==
0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
[root@opncl42 ~]# vi /etc/dasd.conf
[root@opncl42 ~]#  mkinitrd -f /boot/initramfs-3.10.0-1127.el7.s390x.img 
3.10.0-1127.el7.s390x
[root@opncl42 ~]# zipl
Using config file '/etc/zipl.conf'
Building bootmap in '/boot'
Building menu 'zipl-automatic-menu'
Adding #1: IPL section '3.10.0-1127.el7.s390x' (default)
Adding #2: IPL section '3.10.0-1127.el7.s390x_with_debugging'
Adding #3: IPL section 'linux'
Preparing boot device: dasda (0150).
Done.
[root@opncl42 ~]# reboot

Post-reboot:

Ý"Ý32m  OK  "Ý0m+ Reached target System Initialization.
Ý1.149462+ dasd-eckd 0.0.0150: A channel path to the device has become opera
tional
Ý1.151741+ dasd-eckd 0.0.0150: New DASD 3390/0C (CU 3990/01) with 65519 cyli
nders, 15 heads, 224 sectors
Ý1.153040+ dasd-eckd 0.0.0150: DASD with 4 KB/block, 47173680 KB total size,
 48 KB/track, linux disk layout
Ý1.153145+ qeth: register layer 2 discipline

Ý1.154257+ qdio: 0.0.0702 OSA on SC 5 using AI:1 QEBSM:0 PRI:1 TDD:1 SIGA:RW
 A
Ý1.155122+  dasda:VOL1/  0X0150: dasda1 dasda2
Ý1.156584+ dasd-eckd 0.0.0200: A channel path to the device has become opera
tional
Ý1.159045+ dasd-eckd 0.0.0200: New DASD 3390/0C (CU 3990/01) with 32759 cyli
nders, 15 heads, 224 sectors
Ý1.159581+ dasd-eckd 0.0.0200: DASD with 4 KB/block, 23586480 KB total size,
 48 KB/track, compatible disk layout
Ý1.160634+  dasdb:VOL1/  0X0200: dasdb1
Ý"Ý32m  OK  "Ý0m+ Started Show Plymouth Boot Screen.""
Ý"Ý32m  OK  "Ý0m+ Reached target Paths.""
Ý"Ý32m  OK  "Ý0m+ Started Forward Password Requests to Plymouth Directory Watch.
""
Ý"Ý32m  OK  "Ý0m+ Reached target Basic System.""
Ý1.169428+ netif_napi_add() called with weight 128 on device eth%d
Ý1.169600+ qeth 0.0.0700: MAC address 02:01:42:00:00:08 successfully 
registered on device eth0
Ý1.169613+ qeth 0.0.0700: Device is a Virtual NIC QDIO card (level: V712)
Ý1.169613+ with link type Virt.NIC QDIO (portname: )
Ý  124.355856+ dracut-initqueueÝ363+: Warning: dracut-initqueue timeout - 
starting timeout scripts""
Ý  124.862823+ dracut-initqueueÝ363+: Warning: dracut-initqueue timeout - 
starting timeout scripts""
Ý  125.366826+ dracut-initqueueÝ363+: Warning: dracut-initqueue timeout - 
starting timeout scripts""
...lots of timeout script errors...
Ý  184.424496+ dracut-initqueueÝ363+: Warning: dracut-initqueue timeout - 
starting timeout scripts""
Ý  184.424755+ dracut-initqueueÝ363+: Warning: Could not boot.""
Ý  184.425825+ dracut-initqueueÝ363+: Warning: /dev/mapper/rhel_opncl41-root 
does not exist"
 Starting Dracut Emergency Shell

Re: Adding disk to root LVM with RHEL 7

2020-04-15 Thread Martha McConaghy
I feel like Alice through the looking glass at this point.  I was hopeful that 
mkinitrd would do the trick, but now I have a whole new problem.  After 
bringing the disk online, adding it to /etc/dasd.conf, I ran mkinitrd and zipl. 
 Then, I rebooted.  I did NOT touch the LVM, or anything, at that point.  This 
resulted in a bunch of dracut timeout errors and am now in dracut emergency 
mode.  I'm about to give up and just give this darned thing a TB LUN and be 
done with it.  But, this shouldn't be so hard for crying out loud.  Its bugging 
me that I don't know what I'm doing wrong.  The RedHat web site lets me log in, 
but won't show me their solution pagesarggg.

So, any thoughts?

Martha

Pre-reboot:

[root@opncl42 ~]# cio_ignore -l
Ignored devices:
=
[root@opncl42 ~]# chccwdev --online 0.0.0200
Setting device 0.0.0200 online
Done
[root@opncl42 ~]# lsdasd
Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==
0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
[root@opncl42 ~]# vi /etc/dasd.conf
[root@opncl42 ~]#  mkinitrd -f /boot/initramfs-3.10.0-1127.el7.s390x.img 
3.10.0-1127.el7.s390x
[root@opncl42 ~]# zipl
Using config file '/etc/zipl.conf'
Building bootmap in '/boot'
Building menu 'zipl-automatic-menu'
Adding #1: IPL section '3.10.0-1127.el7.s390x' (default)
Adding #2: IPL section '3.10.0-1127.el7.s390x_with_debugging'
Adding #3: IPL section 'linux'
Preparing boot device: dasda (0150).
Done.
[root@opncl42 ~]# reboot

Post-reboot:

Ý"Ý32m  OK  "Ý0m+ Reached target System Initialization.
Ý1.149462+ dasd-eckd 0.0.0150: A channel path to the device has become opera
tional
Ý1.151741+ dasd-eckd 0.0.0150: New DASD 3390/0C (CU 3990/01) with 65519 cyli
nders, 15 heads, 224 sectors
Ý1.153040+ dasd-eckd 0.0.0150: DASD with 4 KB/block, 47173680 KB total size,
 48 KB/track, linux disk layout
Ý1.153145+ qeth: register layer 2 discipline

Ý1.154257+ qdio: 0.0.0702 OSA on SC 5 using AI:1 QEBSM:0 PRI:1 TDD:1 SIGA:RW
 A
Ý1.155122+  dasda:VOL1/  0X0150: dasda1 dasda2
Ý1.156584+ dasd-eckd 0.0.0200: A channel path to the device has become opera
tional
Ý1.159045+ dasd-eckd 0.0.0200: New DASD 3390/0C (CU 3990/01) with 32759 cyli
nders, 15 heads, 224 sectors
Ý1.159581+ dasd-eckd 0.0.0200: DASD with 4 KB/block, 23586480 KB total size,
 48 KB/track, compatible disk layout
Ý1.160634+  dasdb:VOL1/  0X0200: dasdb1
Ý"Ý32m  OK  "Ý0m+ Started Show Plymouth Boot Screen.""
Ý"Ý32m  OK  "Ý0m+ Reached target Paths.""
Ý"Ý32m  OK  "Ý0m+ Started Forward Password Requests to Plymouth Directory Watch.
""
Ý"Ý32m  OK  "Ý0m+ Reached target Basic System.""
Ý1.169428+ netif_napi_add() called with weight 128 on device eth%d
Ý1.169600+ qeth 0.0.0700: MAC address 02:01:42:00:00:08 successfully 
registered on device eth0
Ý1.169613+ qeth 0.0.0700: Device is a Virtual NIC QDIO card (level: V712)
Ý1.169613+ with link type Virt.NIC QDIO (portname: )
Ý  124.355856+ dracut-initqueueÝ363+: Warning: dracut-initqueue timeout - 
starting timeout scripts""
Ý  124.862823+ dracut-initqueueÝ363+: Warning: dracut-initqueue timeout - 
starting timeout scripts""
Ý  125.366826+ dracut-initqueueÝ363+: Warning: dracut-initqueue timeout - 
starting timeout scripts""
...lots of timeout script errors...
Ý  184.424496+ dracut-initqueueÝ363+: Warning: dracut-initqueue timeout - 
starting timeout scripts""
Ý  184.424755+ dracut-initqueueÝ363+: Warning: Could not boot.""
Ý  184.425825+ dracut-initqueueÝ363+: Warning: /dev/mapper/rhel_opncl41-root 
does not exist"
 Starting Dracut Emergency Shell..."
Warning: /dev/mapper/rhel_opncl41-root does not exist

Generating "/run/initramfs/rdsosreport.txt"


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






Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Vice President

Marist College IT

Poughkeepsie, NY 12601

________
From: Linux on 390 Port  on behalf of Marcy Cortes 

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

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

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




-----Original Message-
From: Linux on 390 Port  On Behalf Of Rick Troth
Sent: Wednesday, April 15, 2020 

Re: Adding disk to root LVM with RHEL 7

2020-04-15 Thread Davis, Larry (National VM Capability)
Also make sure that you add the address "0.0.0200" to the /etc/dasd.conf file


Larry Davis (z/VM Team)

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

Sorry

Thanks,

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

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

Martha not Marcy :)


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

Marcy,

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

Thanks,

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

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

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

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




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

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

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

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

-- R; <><


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

Re: Adding disk to root LVM with RHEL 7

2020-04-15 Thread Mark Post
On 4/15/20 12:02 PM, Martha McConaghy wrote:
> Ah, DOH!  I did not run mkinitrd and am now kicking myself.  (Its OK, I need 
> the exercise.)  I'll give that a try and see if it makes a difference.

Do yourself a favor and remove the cio_ignore parameter from
/etc/zipl.conf entirely. It's a z/VM guest, it doesn't need that. At
all. If you were a brand-new z/VM systems programmer that had tons of
unnecessary devices defined, that would be different. But, you're not. :)


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: Adding disk to root LVM with RHEL 7

2020-04-15 Thread Cohen, Sam
Sorry

Thanks,

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

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

Martha not Marcy :) 


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

Marcy,

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

Thanks,

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

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

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

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




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

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

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

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

-- R; <><


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

Re: Adding disk to root LVM with RHEL 7

2020-04-15 Thread Marcy Cortes
Martha not Marcy :) 


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

Marcy,

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

Thanks,

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

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

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

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




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

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

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

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

-- R; <><


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

Re: Adding disk to root LVM with RHEL 7

2020-04-15 Thread Martha McConaghy
Ah, DOH!  I did not run mkinitrd and am now kicking myself.  (Its OK, I need 
the exercise.)  I'll give that a try and see if it makes a difference.

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Vice President

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Marcy Cortes 

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

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

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




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

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

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

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

-- R; <><


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

Re: Adding disk to root LVM with RHEL 7

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

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




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

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

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

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

-- R; <><


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

Re: Adding disk to root LVM with RHEL 7

2020-04-15 Thread Cohen, Sam
Marcy,

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

Thanks,

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

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

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

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




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

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

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

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

-- R; <><


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

Re: Adding disk to root LVM with RHEL 7

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

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

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

-- R; <><


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

Adding disk to root LVM with RHEL 7

2020-04-15 Thread Martha McConaghy
I have servers that I'm setting up with RHEL 7.8 on ECKD disk.  I installed it 
with root in an LVM, all of that worked fine.  Now, I'm testing adding a 2nd 
ECKD disk to the LVM as I know that will be required in the future, but I'm 
running into a confusing problem.  Everything works as I expect and the disk 
space shows up in / as it should.  When I reboot the server, however, it goes 
to heck and ends up in emergency mode.  The most prominent feature of the 
console are a bunch of I/O errors on device dm-2, which is the disk I just 
added.  Below are the steps I followed to add the disk.  Before doing this, I 
had activated the disk, added it to /etc/dasd.conf and run zipl.  After doing 
that, I rebooted to ensure that the disk came up online, which it did.  So, I'm 
confident that the disk is there when the system rebooted the 2nd time.

I have a lot of colleagues who work with Linux all the time, but don't usually 
have root as an LVM.  They haven't seen this problem before, but they work 
mainly on X.  Could this be specific problem to using ECKD?  I have thought of 
going to an FBA LUN, but had spare ECKD to use.

Martha


[root@opncl42 ~]# cio_ignore -r 0.0.0200
[root@opncl42 ~]# chccwdev --online 0.0.0200
Setting device 0.0.0200 online
Done
[root@opncl42 ~]# lsdasd
Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==
0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620
[root@opncl42 ~]# vi /etc/dasd.conf
[root@opncl42 ~]# zipl
Using config file '/etc/zipl.conf'
Building bootmap in '/boot'
Building menu 'zipl-automatic-menu'
Adding #1: IPL section '3.10.0-1127.el7.s390x' (default)
Adding #2: IPL section '3.10.0-1127.el7.s390x_with_debugging'
Adding #3: IPL section 'linux'
Preparing boot device: dasda (0150).
Done.
[root@opncl42 ~]# reboot
---
[root@opncl42 ~]# lsdasd
Bus-ID Status  Name  Device  Type  BlkSz  Size  Blocks
==
0.0.0150   active  dasda 94:0ECKD  4096   46068MB   11793420
0.0.0200   active  dasdb 94:4ECKD  4096   23033MB   5896620

[root@opncl42 ~]# dasdfmt -p -f /dev/dasdb
Please enter the blocksize of the formatting [4096]:
Drive Geometry: 32759 Cylinders * 15 Heads =  491385 Tracks

I am going to format the device /dev/dasdb in the following way:
   Device number of device : 0x200
   Labelling device: yes
   Disk label  : VOL1
   Disk identifier : 0X0200
   Extent start (trk no)   : 0
   Extent end (trk no) : 491384
   Compatible Disk Layout  : yes
   Blocksize   : 4096
   Mode: Full

--->> ATTENTION! <<---
All data of that device will be lost.
Type "yes" to continue, no will leave the disk untouched: yes
Formatting the device. This may take a while (get yourself a coffee).
cyl   32759 of   32759 |#|100% [2m 43s]
Finished formatting the device.
Rereading the partition table... ok
[root@opncl42 ~]# pvcreate /dev/dasdb1
  Device /dev/dasdb1 not found.
[root@opncl42 ~]# fdasd /dev/dasdb
reading volume label ..: VOL1
reading vtoc ..: ok

Command action
   m   print this menu
   p   print the partition table
   n   add a new partition
   d   delete a partition
   v   change volume serial
   t   change partition type
   r   re-create VTOC and delete all partitions
   u   re-create VTOC re-using existing partition sizes
   s   show mapping (partition number - data set name)
   q   quit without saving changes
   w   write table to disk and exit

Command (m for help): n
First track (1 track = 48 KByte) ([2]-491384):
Using default value 2
Last track or +size[c|k|M] (2-[491384]):
Using default value 491384

Command (m for help): w
writing VTOC...
rereading partition table...
[root@opncl42 ~]# pvcreate /dev/dasdb1
  Physical volume "/dev/dasdb1" successfully created.
[root@opncl42 ~]# vgdisplay
  --- Volume group ---
  VG Name   rhel_opncl41
  System ID
  Formatlvm2
  Metadata Areas1
  Metadata Sequence No  3
  VG Access read/write
  VG Status resizable
  MAX LV0
  Cur LV2
  Open LV   2
  Max PV0
  Cur PV1
  Act PV1
  VG Size   <44.50 GiB
  PE Size   4.00 MiB
  Total PE  11391
  Alloc PE / Size   11381 / <44.46 GiB
  Free  PE / Size   10 / 40.00 MiB
  VG UUID   uEvApZ-Wrx7-7n47-f0f0-IQ6R-uU4K-JO8wAN

[root@opncl42 ~]# vgextend rhel_opncl41 /dev/dasdb1
  Volume group "rhel_opncl41" successfully extended
[root@opncl42 ~]# vgdisplay
  --- Volume group ---
  VG Name   rhel_opncl41
  System ID
  Formatlvm2
  Metadata