Hi Steffen, fstab shows that /boot is on a physical partition (/dev/sda1 has label /boot): /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 I mis-read your reply about the restrictions when using logical volumes for the boot device - I assumed it meant that the root file system had to be on the first PV of the LV. So running mkinitrd and zipl from another system should be OK, as you suggest. However I decided to go down another path - move some data off the LV, then use pvmove and pvremove to remove the second PV so that I could boot the system without it. pvmove is still saying that the first PV is full, but that is another problem. Maybe the unix guy can fix this when he returns next week. Meanwhile I am going to create a new system (these are test systems of course, but we need to have various levels of both RH and SUSE to test our software). Keith On Wednesday, 21 May 2014, 19:13, Steffen Maier <[email protected]> wrote:
Hi Keith, On 05/21/2014 02:05 PM, Keith Gooding wrote: > Thank you to everyone who responded. No, we did not run mkinitrd and > zipl after adding the second LUN to the root file system. When we > have added LUNs in the past it has been unnecessary because they were > not needed during boot - I started to understand this just after I > posted my question. (My linux knowledge is not very good - I > understand z/OS and system z in general and do the 'z' parts of > installing zLinux. A colleage who knows little about system z then > takes over. There seems to be a big gap in our combined knowledge, > but I have now learned something about the boot process - at least I > now understand that 'rd' in initrd stands for 'ram disk'). > > Unfortunately the volume groups in all of our systems are called > 'VolGroup00' so I was not able to vgimport the group into a RH 5 > system so I accessed it from a SUSE system which does not LVs so that > I could rename it. I was just about to import it into a RH 5 system > so that I could run initmkd and zipl under chroot when I read > Steffen's refernce to the restrictions with LVs in RH 5. The reason > for adding the second PV was that the first was full, so it is > possible that any new boot image will be created on the new physical > volume. I think this is getting too difficult. I'm missing some setup information to make a valid statement here. What does your /etc/fstab look like? Since RHEL5 most likely does not support /boot (whether separately or included in the root-fs) on multipathing or LVM (or any non-physical block device(s)), don't you already have /boot separately on some single-path /dev/sdXYNM ? If so, adding PVs to your root-fs should not be a problem at all. > Re-installing with a > later release is probably more productive. > > Incidentally I spent some time yesterday in attempting to enter > kernel parameters using the SCPDATA option of LOADDEV in zVM V5. > (a). I assumed that the parameters have to be in ascii so I entered > them in hexadecimal. (b). Is this method actually available for RH 5? Linux kernel support for SCPDATA only appeared via upstream with kernel 2.6.32, so it's not available for RHEL5, but e.g. with SLES11 SP1 / RHEL6 or later. http://www.ibm.com/developerworks/linux/linux390/kernel-2.6.32.html <quote> Summary: kernel: Extra kernel parameter for SCSI IPL Description: When booting from a SCSI boot device, you can now specify kernel parameters in addition to the existing kernel parameters that are used by your boot configuration. To specify kernel parameters, use the SCPDATA option of the CP LOADDEV command or enter kernel parameters in the 'Operating system specific load parameters' panel when IPLing a system from the HMC. Please refer to the 'Device Drivers, Features, and Commands' manual (Documentation), Chapter 'Booting Linux', section 'Providing additional kernel parameters when booting'. </quote> It seems parameters have to be ASCII characters (not hex), otherwise SCPDATA is ignored. The used setting can be read from /sys/firmware/ipl/scp_data in the IPLed kernel (where you could also reconfigure for an upcoming reboot under /sys/firmware/reipl/fcp/scp_data). It works for both a regular IPL as well as for an IPL of the SCSI standalone dumper (zfcpdump). I'd recommend to pick the device drivers book matching your distribution from http://www.ibm.com/developerworks/linux/linux390/distribution_hints.html to get matching customized documentation. You might look into more recent minor release books in case there were documentation fixes. > - I found the reference in the RH 6 documentation. (c). If SCPDATA > can be used with RH 5, what is the syntax of the zfcp options. I > asssumed that it was "zfcp.device=0.0.uuuu,<wwpn>,<lun>" but also Please do not use the zfcp module parameter zfcp.device=. It's only for test purposes and can only activate exactly one single LUN. This is of course not sufficient for production environments with >=2 paths. RHEL and SLES use different methods to activate zFCP LUNs. > tried the "rd.zfcp" format from RH 7. Should it be 'rh_zfcp" as in RH > 6 or is it not available at all ? Since RHEL5 does not have any pseudo boot parameter to activate zFCP LUNs (it only takes info from inside initrd), passing parameters on boot most probably won't help you with RHEL5. Hence, you were absolutely right attaching the disk(s) somewhere else and recreating initrd in a chroot environment. This only works with RHEL6 (rd_ZFCP= and it's case sensitive!) or RHEL7 (rd.zfcp= also case sensitive!). > > Keith > On Wednesday, 21 May 2014, 11:21, Steffen Maier <[email protected]> > wrote: > > > > Hi Keith, > > On 05/20/2014 02:36 PM, Keith Gooding wrote: >> We installed a RH 5.2 system where the root file system is on a >> logical volume comprising a single physical volume which is on zFCP LUN. >> Later we added another zFCP LUN, updated zfcp.conf and added the >> physical volume to the LV. This appeared to be OK until we had a >> scheduled reboot of the system. > > Did you run mkinitrd and then zipl after having changed /etc/zfcp.conf? > RHEL5 simply copies activation statements of all entries of zfcp.conf > into the initrd (whether those LUNs are needed for the root-fs or not, > so it's at least sufficient to activate all LUNs for the root-fs). > >> The boot starts OK until: >> >> Scanning logical volumes >> Reading all physical volumes. >> This may take a while... >> Couldn't find device with uuid 'YD0yYY-Ty0J-I303-2jqQ-4bYs-SSFx-QyzQzc'. >> Found volume group "VolGroup00" using metadata type lvm2 >> >> Eventually it gives up because it cannot mount the root file system >> because the logical volume is incomplete.I was able to access both >> LUNs from another system and I ran vgimport on that system to check >> the zfcp.conf. It seems to be OK. Does anyone know if I need some >> entries in the zipl.conf file for the zfcp LUNs?. The RHEL 7 (beta) >> documentation states that if the root file system is on a logical >> volume using zFCP then entries are needed in zipl.conf but I cannot >> find any instructions for RHEL 5, or indeed any documentation of the >> syntax for zipl.conf. The zipl.conf which was generated by the RHEL >> 5 installer does not have any zfcp entries in zipl.conf.We could just >> install a new system with a larger root file system but I would like >> to be able to fix this if possible.Keith Gooding > > This procedure is only different starting with RHEL6 (including RHEL7, > where the syntax of rd_ZFCP= changed slightly to rd.zfcp=). > It's dracut (successor of mkinitrd) does not (depending on dracut > config) copy activation statements from zfcp.conf into the initramfs, > but the user (or anaconda during installation) has to use explicit > rd.zfcp= statements as pseudo kernel boot parameters to activate LUNs of > all paths required for the root-fs. > [https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_FCP-Attached_LUNs-Persistently.html > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Installation_Guide/sect-post-installation-fcp-attached-luns-persistent-s390.html] > > Everything else, such as all data volumes (even /boot if it's not > included in the root-fs) or scsi tapes only go into /etc/zfcp.conf. > [https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info-Adding_FCP-Attached_LUNs-Persistently-Not_part_of_root_file_system.html > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Installation_Guide/sect-post-installation-fcp-attached-luns-no-root-s390.html] > > Re-running mkinitrd/dracut is not necessary in all cases (only if > lvm.conf or other config files that changed are included in initramfs), > but it would probably be safest to re-create anyways. > > You definitely have to re-run zipl to enable the added kernel boot > parameters. > > > > If I looked it up correctly, RHEL5 does not have zipl support for > device-mapper devices [1]. So /boot is most likely a single path SCSI > device (or DASD) without LVM in your case anyway and thus independent of > and unrelated to the root-fs. > Other releases that have this support (such as RHEL6/7 or SLES, via > upstream s390-tools-1.8.3 or as backport), have particular constraints > for the device-mapper support, which are described in detail in the book > 'Device Drivers, Features, and Commands', Chapter 'Initial program > loader for System z - zipl > ', Section 'Preparing a logical device as a boot device' [2 and pick > suitable distro release]: > > <quote> > You can prepare logical devices as boot devices. Logical devices are > provided by device drivers that do not work on real hardware. For > example, device mapper provides logical devices. > In this context, a target device means a logical device on which the > file system is located. A base device is a physical device on which the > logical device is located, or a logical device that is a linear mapping > beginning at block 0 of the physical device. > You can prepare a logical DASD or SCSI device as a boot device if the > following conditions are met: > * Kernel, initial RAM disk, and parameter files are all located on a > logical device that maps to a single base device. This base device can > be mirrored or accessed through a multipath configuration. > * Adjacent data blocks on the logical device correspond to adjacent data > blocks on the base device. > * zipl has access to the first blocks, including block 0, of the base > device. > </quote> > > The first bullet generically describes a special case of multi-PV LVM VG > where the /boot LV happens to map to one single PV. As long as you > ensure this constraint remains fulfilled, it is possible, though it > could be considered unsafe. > This matches the discussion Tomas Pavelka pointed to. > > [1] > http://www.ibm.com/developerworks/linux/linux390/s390-tools-1.8.3.html#changes > > [2] http://www.ibm.com/developerworks/linux/linux390/distribution_hints.html -- HTH Steffen Maier Linux on System z 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 [email protected] 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 [email protected] 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/
