Re: [sisuite-users] SALI: ping failure?
Chris, I think I found the reason why the ping_test fails. During the development of SALI we configured our dhcp server to tell SALI where the image server is. What happens is that the IMAGESERVER is always been overridden by the udhcp configuration. Even when the value IMAGESERVER is empty. What should be happening is that the value of IMAGESERVER must only be set when empty. Today I shall fix this and implement this in the 1.3.1 release of SALI. On 2010-09-28 01:42, Chris Pepper wrote: On 9/27/10 8:46 AM, Dennis Stam wrote: Greg, Thanks for pointing that out. That could be the problem. By default SALI does not wait for fetching a DHCP lease. But you can add the variable ETHER_SLEEP. https://subtrac.sara.nl/oss/sali/wiki/SaliUsage/Installationparameters#ETHER_SLEEPsec Regards, Dennis On 2010-09-27 14:20, Fiumara, Gregory wrote: On Sep 25, 2010, at 10:14 AM, Chris Pepper wrote: No, it's getting a lease. Otherwise it wouldn't be able to download the code and wouldn't be trying to ping IMAGESERVER, but I do see it in the log. I have seen cases with clients getting a DHCP lease at the start of the PXE boot, but when the SystemImager scripts start running and request another DHCP lease, the request fails. In that case, the nodes were connected to a newly configured Cisco switch that had spanning tree enabled, which imposed a delay, preventing a lease, and ultimately making the ping test fail. Not saying that's your situation, but I have seen it. Thanks. I added ETHER_SLEEP=30 to /var/lib/tftpboot/pxelinux.cfg/default in case that helps, but I don't think that's my problem -- I'd expect a failure to connect rather than a syntax error if it was giving the correct argument, and I was already seeing the DHCP server hand out a lease again after SALI's components are fetched. Chris Without ETHER_SLEEP: Sep 27 11:55:39 lux dhcpd: DHCPDISCOVER from 1c:c1:de:f0:8d:88 via eth1 Sep 27 11:55:39 lux dhcpd: DHCPOFFER on 10.0.2.114 to 1c:c1:de:f0:8d:88 via eth1 Sep 27 11:55:41 lux dhcpd: DHCPREQUEST for 10.0.2.114 (10.0.2.10) from 1c:c1:de:f0:8d:88 via eth1 Sep 27 11:55:41 lux dhcpd: DHCPACK on 10.0.2.114 to 1c:c1:de:f0:8d:88 via eth1 Sep 27 11:55:41 lux xinetd[6320]: START: tftp pid=13135 from=10.0.2.114 Sep 27 11:55:41 lux in.tftpd[13136]: RRQ from 10.0.2.114 filename pxelinux.bin Sep 27 11:55:41 lux in.tftpd[13136]: tftp: client does not accept options Sep 27 12:05:17 lux in.tftpd[13286]: RRQ from 10.0.2.114 filename pxelinux.bin Sep 27 12:05:17 lux in.tftpd[13287]: RRQ from 10.0.2.114 filename pxelinux.cfg/01-1c-c1-de-f0-8d-88 Sep 27 12:05:17 lux in.tftpd[13288]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A000272 Sep 27 12:05:17 lux in.tftpd[13289]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A00027 Sep 27 12:05:17 lux in.tftpd[13290]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A0002 Sep 27 12:05:17 lux in.tftpd[13291]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A000 Sep 27 12:05:17 lux in.tftpd[13292]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A00 Sep 27 12:05:17 lux in.tftpd[13293]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A0 Sep 27 12:05:17 lux in.tftpd[13294]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A Sep 27 12:05:17 lux in.tftpd[13295]: RRQ from 10.0.2.114 filename pxelinux.cfg/0 Sep 27 12:05:17 lux in.tftpd[13296]: RRQ from 10.0.2.114 filename pxelinux.cfg/default Sep 27 12:05:17 lux in.tftpd[13297]: RRQ from 10.0.2.114 filename sali-kernel Sep 27 12:05:17 lux in.tftpd[13298]: RRQ from 10.0.2.114 filename /sali-initrd Sep 27 12:05:45 lux dhcpd: uid lease 10.0.2.199 for client 1c:c1:de:f0:8d:88 is duplicate on 10.0.2/24 Sep 27 12:05:45 lux dhcpd: DHCPDISCOVER from 1c:c1:de:f0:8d:88 via eth1 Sep 27 12:05:45 lux dhcpd: DHCPOFFER on 10.0.2.114 to 1c:c1:de:f0:8d:88 via eth1 Sep 27 12:05:45 lux dhcpd: uid lease 10.0.2.199 for client 1c:c1:de:f0:8d:88 is duplicate on 10.0.2/24 Sep 27 12:05:45 lux dhcpd: DHCPREQUEST for 10.0.2.114 (10.0.2.10) from 1c:c1:de:f0:8d:88 via eth1 Sep 27 12:05:45 lux dhcpd: DHCPACK on 10.0.2.114 to 1c:c1:de:f0:8d:88 via eth1 ETHER_SLEEP added SALI updated: [r...@lux tftpboot]# tail -4 pxelinux.cfg/default label sali kernel sali-kernel append load_ramdisk=1 prompt_ramdisk=0 initrd=/sali-initrd root=/dev/ram rw ramdisk_size=103819 IMAGESERVER=10.0.2.10 ETHER_SLEEP=30 SCRIPTNAME=l01.201009.master # console=ttyS0,9600n8 [r...@lux tftpboot]# md5sum sali-* e9267c3b22ce40008ea3f3a644cfdfc9 sali-initrd 82909d598ec8de55f6feb2e679ab858d sali-kernel But apparently IMAGESERVER still isn't being passed to the ping command. Chris -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
Re: [sisuite-users] SALI: ping failure?
Chris, I just implemented the fix in SALI 1.3.2. Download link: ftp://ftp.sara.nl/pub/sali/sali-1.3.2.tar.gz On 2010-09-28 08:05, Dennis Stam wrote: Chris, I think I found the reason why the ping_test fails. During the development of SALI we configured our dhcp server to tell SALI where the image server is. What happens is that the IMAGESERVER is always been overridden by the udhcp configuration. Even when the value IMAGESERVER is empty. What should be happening is that the value of IMAGESERVER must only be set when empty. Today I shall fix this and implement this in the 1.3.1 release of SALI. On 2010-09-28 01:42, Chris Pepper wrote: On 9/27/10 8:46 AM, Dennis Stam wrote: Greg, Thanks for pointing that out. That could be the problem. By default SALI does not wait for fetching a DHCP lease. But you can add the variable ETHER_SLEEP. https://subtrac.sara.nl/oss/sali/wiki/SaliUsage/Installationparameters#ETHER_SLEEPsec Regards, Dennis On 2010-09-27 14:20, Fiumara, Gregory wrote: On Sep 25, 2010, at 10:14 AM, Chris Pepper wrote: No, it's getting a lease. Otherwise it wouldn't be able to download the code and wouldn't be trying to ping IMAGESERVER, but I do see it in the log. I have seen cases with clients getting a DHCP lease at the start of the PXE boot, but when the SystemImager scripts start running and request another DHCP lease, the request fails. In that case, the nodes were connected to a newly configured Cisco switch that had spanning tree enabled, which imposed a delay, preventing a lease, and ultimately making the ping test fail. Not saying that's your situation, but I have seen it. Thanks. I added ETHER_SLEEP=30 to /var/lib/tftpboot/pxelinux.cfg/default in case that helps, but I don't think that's my problem -- I'd expect a failure to connect rather than a syntax error if it was giving the correct argument, and I was already seeing the DHCP server hand out a lease again after SALI's components are fetched. Chris Without ETHER_SLEEP: Sep 27 11:55:39 lux dhcpd: DHCPDISCOVER from 1c:c1:de:f0:8d:88 via eth1 Sep 27 11:55:39 lux dhcpd: DHCPOFFER on 10.0.2.114 to 1c:c1:de:f0:8d:88 via eth1 Sep 27 11:55:41 lux dhcpd: DHCPREQUEST for 10.0.2.114 (10.0.2.10) from 1c:c1:de:f0:8d:88 via eth1 Sep 27 11:55:41 lux dhcpd: DHCPACK on 10.0.2.114 to 1c:c1:de:f0:8d:88 via eth1 Sep 27 11:55:41 lux xinetd[6320]: START: tftp pid=13135 from=10.0.2.114 Sep 27 11:55:41 lux in.tftpd[13136]: RRQ from 10.0.2.114 filename pxelinux.bin Sep 27 11:55:41 lux in.tftpd[13136]: tftp: client does not accept options Sep 27 12:05:17 lux in.tftpd[13286]: RRQ from 10.0.2.114 filename pxelinux.bin Sep 27 12:05:17 lux in.tftpd[13287]: RRQ from 10.0.2.114 filename pxelinux.cfg/01-1c-c1-de-f0-8d-88 Sep 27 12:05:17 lux in.tftpd[13288]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A000272 Sep 27 12:05:17 lux in.tftpd[13289]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A00027 Sep 27 12:05:17 lux in.tftpd[13290]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A0002 Sep 27 12:05:17 lux in.tftpd[13291]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A000 Sep 27 12:05:17 lux in.tftpd[13292]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A00 Sep 27 12:05:17 lux in.tftpd[13293]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A0 Sep 27 12:05:17 lux in.tftpd[13294]: RRQ from 10.0.2.114 filename pxelinux.cfg/0A Sep 27 12:05:17 lux in.tftpd[13295]: RRQ from 10.0.2.114 filename pxelinux.cfg/0 Sep 27 12:05:17 lux in.tftpd[13296]: RRQ from 10.0.2.114 filename pxelinux.cfg/default Sep 27 12:05:17 lux in.tftpd[13297]: RRQ from 10.0.2.114 filename sali-kernel Sep 27 12:05:17 lux in.tftpd[13298]: RRQ from 10.0.2.114 filename /sali-initrd Sep 27 12:05:45 lux dhcpd: uid lease 10.0.2.199 for client 1c:c1:de:f0:8d:88 is duplicate on 10.0.2/24 Sep 27 12:05:45 lux dhcpd: DHCPDISCOVER from 1c:c1:de:f0:8d:88 via eth1 Sep 27 12:05:45 lux dhcpd: DHCPOFFER on 10.0.2.114 to 1c:c1:de:f0:8d:88 via eth1 Sep 27 12:05:45 lux dhcpd: uid lease 10.0.2.199 for client 1c:c1:de:f0:8d:88 is duplicate on 10.0.2/24 Sep 27 12:05:45 lux dhcpd: DHCPREQUEST for 10.0.2.114 (10.0.2.10) from 1c:c1:de:f0:8d:88 via eth1 Sep 27 12:05:45 lux dhcpd: DHCPACK on 10.0.2.114 to 1c:c1:de:f0:8d:88 via eth1 ETHER_SLEEP added SALI updated: [r...@lux tftpboot]# tail -4 pxelinux.cfg/default label sali kernel sali-kernel append load_ramdisk=1 prompt_ramdisk=0 initrd=/sali-initrd root=/dev/ram rw ramdisk_size=103819 IMAGESERVER=10.0.2.10 ETHER_SLEEP=30 SCRIPTNAME=l01.201009.master # console=ttyS0,9600n8 [r...@lux tftpboot]# md5sum sali-* e9267c3b22ce40008ea3f3a644cfdfc9 sali-initrd 82909d598ec8de55f6feb2e679ab858d sali-kernel But apparently IMAGESERVER still isn't being passed to the ping command. Chris
[sisuite-users] ANNOUNCE: New version of SALI
1.3.2 * Added method parse_tmpfs_opts that was removed earlier. Now you can specify the size of the tmpfs mount 1.3.1 * Fixed that udhcp overrides the value IMAGESERVER even when the value is empty. Udhcp only sets the IMAGSERVER value when not given as a kernel arg. Reported by : Chris Pepper * Removed a lot of SystemImager specific files that SALI does not use now you must use ./configure first * Changed Makefile, 'make help' shows the available options * ping_test prints the value of the IMAGESERVER * added curl 7.21.1 for fetching the headers when using http/ftp protocol * update kernel 2.6.34.7 * update xfsprogs 3.1.2 * update lvm 2.2.02.73 * update mdadm 3.1.3 * update udev 161 * update aria 1.10.3 == The latest stable SALI is available from: ftp://ftp.sara.nl/pub/sali/sali.tar.gz Information, documentation and reporting bugs for the package: https://subtrac.sara.nl/oss/sali smime.p7s Description: S/MIME Cryptographic Signature -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
[sisuite-users] RFE: si_getimage record datestamp
It would be useful to have a datestamp from the last si_getimage operation so we could tell how fresh an image is. One way to handle this would be to simply 'touch' the image parent directory (inside images/) when completing si_getimage, so we could trivially tell how fresh an image is, even if none of the top-level directories on the client changed. Regards, Chris Pepper -- Chris Pepper:http://cbio.mskcc.org/ http://www.extrapepperoni.com/ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] Partitioning problem with SI 4.0.2 SALI 1.3.2
Tristam, Last month, I made the minimal changes to the SI master script (as suggested on this list) to make it work with SALI. I have considered using the new SALI masterscript, but not tried it yet. Your suggestions look a bit more radical, and I haven't looked in the SALI documentation to find out what those verbs mean yet. If possible, I'd like to patch the SI script, since I believe it's *almost* okay (it worked on PE1950s last month). If that won't fly, I'll test the SALI replacement. Is there any documentation for your suggested modifications? Did you pull them from a public source that I can read? Thanks, Chris On 9/28/10 3:44 PM, Tristam MacDonald wrote: On Tue, Sep 28, 2010 at 11:58 AM, Chris Pepper pep...@reppep.com mailto:pep...@reppep.com wrote: Dennis, Thanks, your SALI fix enabled us to pull the script from the server. Now using a SI master script modified for SALI, I'm getting warnings about partition alignment, and a partition creation failure which halts the whole process. Screenshots are at http://cbio.mskcc.org/~pepper/si/. Any suggestions? Thanks, Chris You mention modifying the script to work with SALI, but you still appear to be using the system-imager style partition script. Adapting to the SALI commands should look more like mine: # disk enumeration disk_enumerate sd hd # set disk label set_disklabel $DISK0 gpt # partition partition $DISK0 1:grub2 5000:swap::swap 2:ext4:/:root 1:ext4:/tmp:temp 0:ext4:/data:data # mount disks mount_disks -- Chris Pepper:http://cbio.mskcc.org/ http://www.extrapepperoni.com/ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] RFE: si_getimage record datestamp
Chris Pepper wrote: It would be useful to have a datestamp from the last si_getimage operation so we could tell how fresh an image is. How about: si_lsimage --verbose Ole H. Nielsen Technical University of Denmark -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] RFE: si_getimage record datestamp
On 9/28/10 4:02 PM, Ole Holm Nielsen wrote: Chris Pepper wrote: It would be useful to have a datestamp from the last si_getimage operation so we could tell how fresh an image is. How about: si_lsimage --verbose Awesome, thanks! Chris -- Chris Pepper:http://cbio.mskcc.org/ http://www.extrapepperoni.com/ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] Partitioning problem with SI 4.0.2 SALI 1.3.2
On Tue, Sep 28, 2010 at 3:50 PM, Chris Pepper pep...@reppep.com wrote: Tristam, Last month, I made the minimal changes to the SI master script (as suggested on this list) to make it work with SALI. I have considered using the new SALI masterscript, but not tried it yet. Your suggestions look a bit more radical, and I haven't looked in the SALI documentation to find out what those verbs mean yet. If possible, I'd like to patch the SI script, since I believe it's *almost* okay (it worked on PE1950s last month). If that won't fly, I'll test the SALI replacement. Is there any documentation for your suggested modifications? Did you pull them from a public source that I can read? The (semi-complete) official documentation is on the SALI wiki ( https://subtrac.sara.nl/oss/sali/wiki/SaliUsage/Functions). Most of it I pulled from the various SALI-related posts on the mailing list, however. I realise you would prefer to continue using the old-style script, but the reason I recommend the newer method is that SALI-style functions result in a much cleaner script that is far easier to read and maintain. -- Tristam MacDonald http://swiftcoder.wordpress.com/ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
[sisuite-users] Need help with System Imager
Hello Everyone, Does any one know how to fix this issue? I have been struggling a lot to fix it: I get an error message while the system runs the post-install script: 10all.fix_swap_uuids Here is the message: setting UUID=37b17f67-1ca2-4cf4-8aa1-a809a485a629 for swap device /dev/cciss/c0d0p2... error: could not open /dev/cciss/c0d0p2 for reading: No such file or directory Killing off running processes. I was using ubuntu as both my SI server and Golden client. Before executing the Post-Install scripts, I see one more error message during the Bootloader installation. Here is the message: You shouldn't call /sbin/grub-install. Please call /usr/sbin/grub-install instead! Probin devices to guess BIOS drives. This may take a long time. Format of install_device not recognized. Usage: grub-install [OPTION] install_device I do not know if this is causing the problem and do not know how to fix it! I would appreciate if some one can give me a hand here. Thank You guys, Regards, Rupesh -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
[sisuite-users] Need help with SystemImager
Hello Everyone, Does any one know how to fix this issue? I have been struggling a lot to fix it: I get an error message while the system runs the post-install script: 10all.fix_swap_uuids Here is the message: setting UUID=37b17f67-1ca2-4cf4-8aa1-a809a485a629 for swap device /dev/cciss/c0d0p2... error: could not open /dev/cciss/c0d0p2 for reading: No such file or directory Killing off running processes. I was using ubuntu as both my SI server and Golden client. Before executing the Post-Install scripts, I see one more error message during the Bootloader installation. Here is the message: You shouldn't call /sbin/grub-install. Please call /usr/sbin/grub-install instead! Probin devices to guess BIOS drives. This may take a long time. Format of install_device not recognized. Usage: grub-install [OPTION] install_device I do not know if this is causing the problem and do not know how to fix it! I would appreciate if some one can give me a hand here. Thank You guys, Regards, Rupesh -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
