Re: EDEV FBA disks and Cloning
Craig, > We've altered the script to identify the FBA devices, > format them with 'mkfs' and then use the 'dd' to perform > the block copy. When we try to boot the cloned copy Just some thoughts - after you dd them, but before you try to IPL, are you able to mount the new targets as file systems? If not, then that method of copying did not work (is it from FBA to FBA devices?). If so, what is the PSW that goes with the HCPGIR453W message? (I'm guessing 232 - "did not find an OS"). But perhaps it will give another hint. "Mike MacIsaac"(845) 433-7061 -- 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/
Re: EDEV FBA disks and Cloning
Hi, Craig, -- For FBA, you are correct to dispense with 'dasdfmt'. (Will detail that in a following note.) You still need to stamp a bootstrap onto the FBA disk, and the bootstrap is different for FBA than for CKD. > ... We've altered the script to > identify the FBA devices, format them with 'mkfs' and then use the 'dd' to > perform the block copy. ... Right there is a conflict. (Either that, or I have misunderstood your note.) You can 'dd' the filesystem. So if you 'dd' the filesystem as one whole chunk, why would you 'mkfs' beforehand? I presume you want to use the first (and only) partition to hold filesystems, eg: /dev/dasda1 instead of /dev/dasda. If that is correct, then I recommend that you CMS FORMAT and RESERVE the disks before copying to them. Let's say /dev/dasdx is a CKD source and /dev/dasdy is an FBA target. You should ... IPL CMS FORMAT whatever addr is /dev/dasdy RESERVE that same disk boot Linux dd if=/dev/dasdx1 of=/dev/dasdy1 If it is bootable, then also ... mount /dev/dasdy1 /mnt zipl -d /mnt umount /mnt Repeat this for all disks, except that the boot disk is the only one you will mount and 'zipl'. I am leaving out some details for brevity. Does this help? -- R; <>< Rick Troth Velocity Software http://www.velocitysoftware.com/ On Wed, Mar 2, 2011 at 12:39, Craig Collins wrote: > We're walking through the IBM doc "Sharing and Maintaining SLES11 Linux > under z/VM using DCSSs and an NSS" but using EDEV FBA devices instead of > native CKD devices. We've move to the point where we are making our first > cloned copy and are running into issues. > > The original script identifies the CKD disk mount points, then uses > 'dasdfmt' to format the destination CKD devices and 'dd' to do a block copy > from the source to the destination devices. We've altered the script to > identify the FBA devices, format them with 'mkfs' and then use the 'dd' to > perform the block copy. When we try to boot the cloned copy, we don't even > get the boot menu, it just fails with HCPGIR453W CP entered; program > interrupt loop. > > If we copy the devices from within CMS using DDR, the destination server > boots successfully following the copy. > > Does anyone successfully clone servers using scripts run from within a > running linux clone server for EDEV FBA devices? > > I'd also be interested in hearing from anyone who has used EDEV FBA devices > to generate sles11 servers which share read-only portions of the boot & root > partitions without DCSS & NSS related to what they segment off for each > server to use read-write locally. We think that's more likely the scenario > we would want to go with, but we are walking through the above named > document to get familiar with that method as a possibility. > > Craig Collins > State of WI, DOA, DET > > -- > 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/
Re: EDEV FBA disks and Cloning
There is a lot of confusion about 'dasdfmt' versus 'mkfs'. If you already know the difference, please excuse this note. The water is muddier for mainframers because in z/OS land the concept of "filesystem" and "volume" is blurred. z/OS uses the low level structure (tracks, blocks, records, even counts and keys) where most other op sys do not. CMS does not and even CP can live without it. VSE is happy there too, which is probably why VSE and CP and CMS (and Linux and AIX and Solaris) are all content to run on FBA. z/OS has an allergy to fixed block storage and requires CKD. CKD on Linux must be formatted both low level (dasdfmt) and high level (mkfs, usu also fdasd). FBA on Linux needs no low level formatting. Go directly to 'mkfs'. Do not pass "go"; do not collect $200. (but see below) CKD on CMS must be formatted both "low level" and "high level". The CMS FORMAT command handles both (for CMS minidisks). It blocks the disk (these days usually 4K) and then creates and empty CMS "EDF" filesystem. A disk which has been formatted with CMS FORMAT can be used by Linux without 'dasdfmt'. I will skip discussion of ICKDSF and CPFMTXA for this context. FBA on CMS does not require low level formatting, so CMS FORMAT silently skips that part and proceeds immediately to lay down the EDF filesystem we all know and love. By default, it writes zeros, but you can opt out of that and get instant completion. Logical blocksize can be 512, 1K, 2K or 4K, but the physical blocksize is always 512. In a word, RESERVE. If you will be using partitions (don't get me started!) then I recommend doing a CMS RESERVE. This works for CKD or FBA. The result is that /dev/dasdy1 will map byte-for-byte with the reserved file. I hope this helps. -- R; <>< Rick Troth Velocity Software http://www.velocitysoftware.com/ -- 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/
Re: EDEV FBA disks and Cloning
We created the golden image server on EDEV FBA disk as well so our clone is from EDEV FBA to EDEV FBA. I presume if we are using the CMS FORMAT/RESERVE sequence we should do so for the source golden image build as well as the clone system before copying. When we tried using dd to clone, I watched the VM console for the server and there are many block errors during the copies. This was before we rebuilt using the FORMAT/RESERVE. I'm going to try that next. We'll rebuild the golden image after formatting the disk with that method and then try the clone again. I'll update with results when we complete that work. -- 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/
Re: EDEV FBA disks and Cloning
>>> On 3/2/2011 at 03:47 PM, Richard Troth wrote: > There is a lot of confusion about 'dasdfmt' versus 'mkfs'. If you > already know the difference, please excuse this note. Rick, Do me a favor and stick this out on the wiki (after editing it a bit for style). I think this would be useful for others that might trip across it and don't know about this listserve. 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/
Re: EDEV FBA disks and Cloning
1. rebuilt the golden image, preparing the disk with CMS FORMAT & RESERVE on EDEV FBA mini-disks 2. prepared the clone system disk with CMS FORMAT & RESERVE on EDEV FBA mini-disks 3. Altered the clonerw.sh script so that it recognized the disk as FBA instead of CKD to get the device names and deleted the format section of the script. 4. ran the clonerw.sh script and through the ssh session, it gave no error messages, however on the VM guest console we received many iterations of the following messages for each device during the dd copy command executions: Buffer I/O error on device dasdc, logical block 4547 lost page write due to I/O error on dasdc end_request: I/O error, dev dasdc, sector 36400 Mar 3 08:28:14 S11CLONE kernel: end_request: I/O error, dev dasdc, sector 77016 5. tried booting the clone but expected failure due to I/O errors and as expected the boot failed 6. Under CMS, used DDR to copy each of the EDEV FBA disks from the golden image to the clone 7. Clone server booted without issue. Working on some parts of boot.findself script to set the ifcfg-eth0 ip address that don't appear to be working, but the server came up without an error. So, we have a method to make the clone, but the clonerw.sh script doesn't seem to work with this disk without further modifications that we can't figure out at this point. On Thu, Mar 3, 2011 at 10:12 AM, Mark Post wrote: > >>> On 3/2/2011 at 03:47 PM, Richard Troth wrote: > > There is a lot of confusion about 'dasdfmt' versus 'mkfs'. If you > > already know the difference, please excuse this note. > > Rick, > > Do me a favor and stick this out on the wiki (after editing it a bit for > style). I think this would be useful for others that might trip across it > and don't know about this listserve. > > > 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/
Re: EDEV FBA disks and Cloning
>>> On 3/3/2011 at 11:29 AM, Craig Collins wrote: > So, we have a method to make the clone, but the clonerw.sh script doesn't > seem to work with this disk without further modifications that we can't > figure out at this point. Are you using the "sync" option on the dd command, or issuing a manual sync command after it has finished? We had a couple of reports of that fixing this sort of thing. 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/
Re: EDEV FBA disks and Cloning
the script does have the "sync" command executing after the copy with "dd" completes -- 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/
Re: EDEV FBA disks and Cloning
FYI - the problem we were having with the boot.findself script had to do with upper/lower case matching issues when the script interrogated the sles11 parameter files searching for the source and destination server names and ip addresses. So, the script worked fine once we matched the cases to what the script expected as it scanned the parameters. -- 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/
