On 4/22/20 12:16 PM, Will, Chris wrote: > Mark, > > Dasda2 and dasdd1 should have all the LVM logical volumes that are part of > the root file system (/usr, /var, /opt, /home, /tmp) which are xfs file > systems. The remainder of the root file system(/) is on dasda1 (ext4). > When I cat /proc/cio_ignore it is empty. When I run Dracut I get the > following, why does it not include the 200 disk (dasdd1) and only the lvm for > usr-lv? This is the way it is for all our other systems and they all boot > (except if I do the lvextend). The 300 devices are swap and the 400 fcp. > > dracut: > rd.cio_accept=0.0.0300,0.0.0301,0.0.0400,0.0.0401,0.0.0401,0.0.0400 > dracut: rd.lvm.lv=system-vg/usr-lv > dracut: rd.dasd=0.0.0100 > rd.dasd=0.0.0300 > rd.dasd=0.0.0301
This is why I asked if you had opened up a problem with your support provider. Lots of interlocking pieces that need to be considered. You keep talking about things being "part of the root file system" such as /usr, /var, etc. If those are being mounted, they are *not* part of the root file system. Knowing exactly what is, or is not, part of the root file system would be helpful. As would knowing exactly which block devices make up the root file system. I don't believe this to be your case, but if / was an LVM LV, then every block device (PV) that makes up the volume group (VG) would be in that list. I/we have no idea how the device numbers listed in rd.cio_accept map to device names such as /dev/dasda. For example, I have no idea what device 0.0.0200 is. I don't remember if I've gone over this in the past for the mailing list, so sorry for any repetition here: The task of grub2, and the kernel and initrd it uses it to: 1. Activate the block device that contains /boot. This requires a corresponding udev rule in /etc/udev/rules.d in the /boot/zipl/initrd file. 2. Look at the contents of /boot/grub2/grub.cfg to determine what kernels and initrds should be in the boot menu grub2 constructs. 3. Take the selection the user gives, and boot with that kernel and initrd combination. >From there, the initrd that was loaded from /boot has its own set of tasks: 1. Activate the block device(s) that make up the root file system, *and* /usr if it is a separate file system from /. Again, udev rule(s) in /etc/udev/rules.d in the /boot/initrd file must be present for all of the necessary block devices. 1a. As noted above, if "/" is on an LV, then all of the block devices that make up the VG need to be activated at this time as well. 2. Mount the root file system read-only on /sysroot in the initrd. 3. If /usr is on a separate file system, mount that on /sysroot/usr 3a. If /usr is on an LV, as yours is, then dracut needs to activate all the PVs that make up the VG holding it, then activate the VG and LVs. 4. Do a pivot_root with /sysroot and start /sbin/init (which should be a symbolic link to ../usr/lib/systemd/systemd) During both the grub2 kernel/initrd and "real" kernel/initrd processing, cio_ignore can cause all sorts of havoc if you don't have all the DASD devices specified in the right places to make sure they can be activated. This is why SUSE does not enable cio_ignore by default except in an LPAR installation. It's only really useful in that case, and it's too easy to mess things up. I'm pretty sure we've got the tooling bugs fixed, but a good number of people don't know what tools to use to keep things working. You seem to *not* have cio_ignore specified in the kernel parameters, so that's a good thing. So, if all the necessary devices are available, that isn't contributing to your problem. To try and figure out what might be, please do this: 1. Spool the console log to the guest (#CP SP CONS *) 2. Boot from the proper device such as this: IPL 200 clear parm rd.debug=1 3. Close the spool file (#CP SP CONS STOP CLOSE) 4. Transfer the console log to either another Linux guest, or to a CMS user so that it can be examined. You're going to see a *lot* of output from this. Hopefully somewhere in there will be an indication of why the VG isn't getting properly activated. 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
