I understand now that the PV NAME displayed by pvdisplay is not important. This is on RHEL 7.
Here is the story so far. I added a volume to the server at address 10a. I added 010a to dasd.conf. The Linux group added the new volume to the root vg. Upon next reboot, it failed with Buffer I/O error on dev dm-2, logical block 2269168, async page read sysroot.mount mount process exited, code=exited status=1 Failed to mount /sysroot. Restored server. Added 010a to dasd.conf again. I then added rd.dasd=0.0.010a to the kernel parms in zipl.conf and ran zipl. On next reboot it failed with: Warning: could not boot... Warning: /dev/mapper/rhel_enyza032-root does not exist Warning: /dev/rhel_enyza032/root does not exist Warning: /dev/rhel_enyza032/swap does not exist Restored server again. Added 010a to dasd.conf again. Then I realized /etc/dasd.conf is in the initramfs and of course does not have dasd 010a in it. Regenerated initramfs. Have not rebooted server yet to verify, but I think we should be ok. I think regenerating initramfs is the key if expanding the root vg onto a volume which was not already in dasd.conf. Neal On Fri, Dec 14, 2018 at 12:59 AM Mark Post <mp...@suse.com> wrote: > > >>> On 12/12/2018 at 11:39 AM, Neal Scheffler <vmwiz...@gmail.com> wrote: > > The Linux group expanded the root vg to a second physical dasd volume. > > Doing a pvdisplay shows the PV Name of /dev/dasdm1 > > zipl.conf was updated to include the parm "rd.dasd=0.0.010a" since > > this is part of the root file system. > > > > After reboot, dasd 010a is now /dev/dasdb1 so the server reboot failed. > > > > What is the best way to handle this? > > Should they be using /dev/disk/by-path/ccw-0.0.010a-part1 to reference > > the new dasd? > > This doesn't make much sense to me. LVM doesn't care about the names of > block devices, whether /dev/dasdb1 or /dev/disk/by-path/ccw-0.0.010a-part1. > Apart from any block devices that are excluded in /etc/lvm/lvm.conf, LVM > looks at all available block devices to see if they have any LVM metadata on > them, and uses them regardless of their name. > > Exactly _how_ did the reboot fail? > > > 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/
