Of course, as already suggested, adapting the virtual device numbers in the hypervisor is the primary and easiest choice, if possible.
For cases where this is not an option or not even possible (e.g. WWPN and LUN with FCP), I strongly recommend to follow the RHEL 6 documentation. For any resources (transitively, i.e. through and including any LVM or multipathing) required to bring up and mount the root fs, dracut needs to be instructed on the kernel command line to activate the base physical devices (in contrast to other distro releases, that information is usually (unless you build a host-only initramfs) not inside the initramfs which makes zipl or even other dynamic ways of passing kernel boot options at IPL suffice): * DASD https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info.html#ap-s390info-Adding_DASDs-Persistently_setting_online-Part_of_root_file_system * ZFCP https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_FCP-Attached_LUNs-Persistently.html#ap-s390info-Adding_FCP-Attached_LUNs-Persistently-Part_of_root_file_system * And for the probably uncommon case of a network root-fs https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_a_Network_Device.html#ap-s390info-Adding_a_Network_Device-qeth_Device-Persistently https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_a_Network_Device-Configuring_network_device_for_Network_Root_File_System.html#ap-s390info-Adding_a_Network_Device-Configuring_network_device_for_Network_Root_File_System So in the original posting of this thread, I suppose the rd_DASD entries in /etc/zipl.conf would have to be adjusted and /etc/fstab because RHEL6 uses by-path for DASDs (in order to enable devno virtualization in the hypervisor as mentioned at the top of this mail) plus a zipl run. Above is a significant difference to the persistent activation configuration of any other (data) volume, i.e. volumes that are *no* dependencies for the root fs. They only use /etc/dasd.conf, /etc/zfcp.conf, or /etc/sysconfig/network-scripts/ifcfg-... respectively. No recreation of initramfs nor zipl run. Since RHEL 6.0 there is transparent support for cio_ignore, if you use the documented ways of persistently configuring devices (both for the root fs as well as any other). https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info.html#ap-s390info-Adding_DASDs-Persistently_setting_online > cio_ignore is handled transparently for persistent device > configurations and you do not need to free devices from the ignore > list manually. > There is no need to recreate the initramfs. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_FCP-Attached_LUNs-Persistently.html#ap-s390info-Adding_FCP-Attached_LUNs-Persistently > cio_ignore is handled transparently for persistent device > configurations and you do not need to free devices from the ignore > list manually. > There is no more need to recreate the initramfs. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_a_Network_Device.html#ap-s390info-Adding_a_Network_Device-qeth_Device-Persistently > cio_ignore is handled transparently for persistent device > configurations and you do not need to free devices from the ignore > list manually. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_a_Network_Device-Configuring_network_device_for_Network_Root_File_System.html#ap-s390info-Adding_a_Network_Device-Configuring_network_device_for_Network_Root_File_System > There is no need to recreate the initramfs. cio_ignore for the > network channels is handled transparently on boot. For strictly maintained I/O configurations in the hypervisor (whether in z/VM or PR/SM), you may remove the cio_ignore option from the kernel command line, but it's not necessary. HTH Steffen Maier Linux on System z Development 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 On 05/21/2013 07:11 PM, Mauro Souza wrote: > I usually get rid of cio_ignore every time I install a Linux guest > (but sometimes I forget to). I think this parameter is usable only > when you install Linux on a partition, and this partition can see > every device on the mainframe. On a Linux guest, the only devices > Linux can see is the devices we gave to it, so cio_ignore does > nothing we haven't already done. But it can lead to a lot of > confusion and scratched heads when we change a device. > > Mauro http://mauro.limeiratem.com - registered Linux User: 294521 > Scripture is both history, and a love letter from God. > > > 2013/5/21 Mark Post <mp...@suse.com> > >>>>> On 5/21/2013 at 04:25 AM, SrinivasG <sriniv...@infosys.com> >>>>> wrote: >>> Hi, >>> >>> I am getting error while doing an IPL of virtual Linux server. >>> >>> I have dumped the volumes of cloner server to the virtual server >>> created. Dumping is successful >>> >>> Dumping volume 300 ,301 to virtual server volume 200, 201 using >>> DDR(zVM dump/restore program) command in zVM >>> >>> After dumping, trying to IPL using the volume 200 and getting >>> the >> following >>> error: >>> >>> ***************** dracut: dracut-004-283.el6 dracut: rd_NO_LUKS: >>> removing cryptoluks activation device-mapper: uevent: version >>> 1.0.3 device-mapper: ioctl: 4.22.6-ioctl (2011-10-19) >>> initialised: dm-de...@redhat.com >>> >>> udev: starting version 147 dracut: Starting plymouth daemon >>> dracut: rd_NO_DM: removing DM RAID activation dracut: rd_NO_MD: >>> removing MD RAID activation dracut Warning: No root device >>> "block:/dev/mapper/vg_mysgld-lv_root" >> found >>> dracut Warning: LVM vg_mysgld/lv_root not found dracut Warning: >>> LVM vg_mysgld/lv_swap not found >> >> Others have pointed out that changing the virtual device numbers >> from 200-201 to 300-301 will most likely fix this problem. (That's >> one of the nice things about z/VM when doing cloning. You don't >> _have_ to change the virtual device numbers.) >> >> However, I believe this problem is rooted in the cio_ignore kernel >> parameter. LVM doesn't care what device numbers are used. It >> scans all block devices not filtered out by /etc/lvm/lvm.conf, and >> looks for LVM metadata. If the devices aren't even probed by the >> kernel at IPL time due to cio_ignore, LVM won't have the chance to >> scan them later. >> >> >> 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/
