The system is PXE booting because:
o You set the boot order in BIOS such that PXE has a higher priority than the local hard disk. I do this all the time with IBM e-series boxes.
-or-
o Your hardisk has a corrupt/bad/unbootable system on it and PXE has been configured lower in the boot order priority. Since you boot your box by turning DHCP off on the bootserver this is not your problem :)
The end result is that (a) your system PXE boots all the time and (b) because the default behavior on your DHCP/tftp server is to serve up the SI autoinstall image your node keeps reinstalling itself.
There is probably a proper SI (netbootmon ?) way to do this but a quick way that will work is to just change the info in file that your clients are downloading during the PXE-driven TFTP process.
For you this file is probably located at /tftpboot/pxelinux.cfg/default or just look around your tftp dir for a file called 'default'.
If you turn up the verbose level of your TFTP daemon you'll see items like this in /var/log/messages on your bootserver as your client tries to bootstrap itself:
messages.4:Mar 5 18:41:20 gateway in.tftpd[32342]: RRQ from 192.0.0.15 filename /pxelinux.cfg/C000000F messages.4:Mar 5 18:41:20 gateway in.tftpd[32342]: sending NAK (1, File not found) to 192.0.0.15
messages.4:Mar 5 18:41:20 gateway in.tftpd[32343]: RRQ from 192.0.0.15 filename /pxelinux.cfg/C000000 messages.4:Mar 5 18:41:20 gateway in.tftpd[32343]: sending NAK (1, File not found) to 192.0.0.15
messages.4:Mar 5 18:41:20 gateway in.tftpd[32344]: RRQ from 192.0.0.15 filename /pxelinux.cfg/C00000 messages.4:Mar 5 18:41:20 gateway in.tftpd[32344]: sending NAK (1, File not found) to 192.0.0.15
messages.4:Mar 5 18:41:20 gateway in.tftpd[32345]: RRQ from 192.0.0.15 filename /pxelinux.cfg/C0000 messages.4:Mar 5 18:41:20 gateway in.tftpd[32345]: sending NAK (1, File not found) to 192.0.0.15
messages.4:Mar 5 18:41:20 gateway in.tftpd[32346]: RRQ from 192.0.0.15 filename /pxelinux.cfg/C000 messages.4:Mar 5 18:41:20 gateway in.tftpd[32346]: sending NAK (1, File not found) to 192.0.0.15
messages.4:Mar 5 18:41:20 gateway in.tftpd[32347]: RRQ from 192.0.0.15 filename /pxelinux.cfg/C00 messages.4:Mar 5 18:41:20 gateway in.tftpd[32347]: sending NAK (1, File not found) to 192.0.0.15
messages.4:Mar 5 18:41:20 gateway in.tftpd[32348]: RRQ from 192.0.0.15 filename /pxelinux.cfg/C0 messages.4:Mar 5 18:41:20 gateway in.tftpd[32348]: sending NAK (1, File not found) to 192.0.0.15
messages.4:Mar 5 18:41:20 gateway in.tftpd[32349]: RRQ from 192.0.0.15 filename /pxelinux.cfg/C messages.4:Mar 5 18:41:20 gateway in.tftpd[32349]: sending NAK (1, File not found) to 192.0.0.15
messages.4:Mar 5 18:41:20 gateway in.tftpd[32350]: RRQ from 192.0.0.15 filename /pxelinux.cfg/default
The PXE client tries repeatedly to download a 'custom' bootfile. The bootfiles are named via hex-encoding the dhcp-assigned IP address. The PXE-client knows its own IP address and tries to get the file that is specifically meant for it ("/pxelinux.cfg/C00000F") when it fails it tries a slightly more generic version ("C000") etc. etc.
This goes on through a bunch of iterations and finally, If all else fails, the final action is to download a file called 'default'
Whatever file your client machine is successfully downloading contains instructions to perform an SI autoinstall.
These instructions need to be changed to tell the PXE client to stop its network bootstrap attempts and move on to booting off the local disk device.
A default file for forcing a PXE client to local boot would look something like this:
default linux label linux localboot 0
A typical way people do this with clusters is to create one config file that triggers a SI autoinstall and a 2nd config file that triggers a localboot.
You can then use symlinks in your tftpboot/pxelinux.cfg/ directory to control what happens to your PXE booting machines either globally (by symlinking one of the config files to ./default) or machine-by-machine (by symlinking one of the config files to a file that corresponds to the hex-encoded IP address like /pxelinux.cfg/C00000F for 192.0.0.15)
I think the current systemimager has a net boot monitor process that is capable of toggling between localboots and network-systemimager-autoinstalls. After a successful autoinstall there is a call back to the bootserver that toggles the symlink from auto-install back to local-boot for that particular client IP address. You may wish to dig into this (perhaps the process is not running on your bootserver or it is configured badly).
Otherwise you can just do what I outlined above and create either a global default file or a machine-specific file that tells the node to localboot rather than run the SI process all over again.
-Chris
Tom Kennedy wrote:
I have installed SystemImager and have created an image from a golden-client. I am using PXE to install the golden-client image on to the target system. After the OS is installed on the targt system, the system reboots and starts down loading the image again. I have to turn off the DHCP Server and wait for PCE (lloking for an IP) to time out to get the system to boot to the newly installed image.
How can I get a system to reboot properly after the image is installed? Is there some kind of command that will tell the system to reboot to the harddirve.? Any help appreciated.
Tom
-- Chris Dagdigian, <[EMAIL PROTECTED]> BioTeam - Independent life science IT & informatics consulting Office: 617-665-6088, Mobile: 617-877-5498, Fax: 425-699-0193 PGP KeyID: 83D4310E iChat/AIM: bioteamdag Web: http://bioteam.net
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Sisuite-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-users
