-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Prem,
On Thursday June 09, 2011, Prem Kumar wrote: > hi Josh, > > significant progress ... although not fully successful. > > and very valuable tip from you!, this helped me quite a lot: "to aid > debugging enable remoteshell and removing the /sbin/reboot line at the > end" > > i want to make a note few things here that got me past a little > further in capture process, hence might be worth to see if i could > have done it better:: > > - since my primary nic was eth1, i greped-to-replace the extracted > files from initrd.img and rootimg.gz with eth1 as the primary nic. > > - make sure the node or the nodegroup being captured has appropriate > entries in the xcat table > postscripts.postscripts="syslog,remoteshell,syncfiles" or something > similar to suit individual needs. > > - it might be worth documenting the root password of the rootimg.gz > file system, unless one can replaced it with their own and re-create > the image, and then login using the root credentials when the capture > process fails at any point. worth looking is the /tmp/partimageng.log > of stateless image currently booted in. +++ not sure if this makes > sense, may be if the remoteshell is setup correctly we may not need > this? Our install ends up getting identity keys set up so that you don't have to use a password to log in. However, documenting the root password would be a good idea. > - i had to add the node being captured to my 'iptables' so that the > 'nfs' exports(managemen_node:/install) to write the image > at(/install/image/x86) is not blocked by the firewall on management > node. > > - in spite no_root_squash being enabled on management node nfs server, > 'root' account of the stateless image did not have the permissions to > write the image at /install/image/x86. it is believed that the version > of the 'nfs-client' in the stateless image, as i understand has some > issues. - workaround is to add the flag 'sec=sys' in the 'mount' > command in 'partimageng' script in folder /install/postscripts. > > - with the above adventure i got to a point where following > intermediate files were written to complete the capture process: > -rw-r--r-- 1 root root 0 Jun 9 13:18 > vcl_rhel_template.img.capturefailed -rw------- 1 root root 849 Jun 9 > 13:18 vcl_rhel_template.gz.000 -rw-r--r-- 1 root root 259 Jun 9 > 13:24 vcl_rhel_template-sda.sfdisk -rw-r--r-- 1 root root 512 Jun 9 > 13:24 vcl_rhel_template-sda.mbr -rw------- 1 root root 10485760 Jun 9 > 13:24 pi43fec6f2.tmp I need to add this to the documentation and should have mentioned it earlier. partimage can only capture a few file system types. I don't remember the exact list. I know it includes ext2/ext3 and ntfs. I also know that it cannot capture ext4 and anything involving LVM. That is part of why I included support for partimageng. If it doesn't natively know how to handle the file system, it will fall back to using dd to capture it. Search for 'usepartimageng=0' in the partimageng postscript and change it to =1 to switch to using partimageng. Is the file system to be captured either ext2 or ext3 and without having LVM invovled? > - after few seconds, the '/sbin/partimage' saving the image, fails > with a status code 1. attached is the log file /tmp/partimageng.log > for additional information. partimage is definitely lacking in error messages. It does produce a log file somewhere under /var when it runs that might be useful. We have yet to figure out the constraints, but these ASF lists seem to eat many of the attachments people try to send. You might try just pasting relevant parts inline or posting it to pastebin.com and then including the link here. Josh - -- - ------------------------------- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk3xHXAACgkQV/LQcNdtPQOQpgCdF7/paSYH4YkVuF9FBFpQmOWY NRUAn0ajFdczUmTeSLn4yiIigo6uPPOk =ZTGZ -----END PGP SIGNATURE-----
