لطفا منتظر باشید ...
Testing Your New Kickstart Media
Testing your kickstart boot media is fairly simple. Pop in the bootdisk.img floppy or boot.iso CD, verify that the machine BIOS is set to boot off that media, that your networking hardware is all connected, and that you're on a DHCP LAN (if you're doing nonstatic IP network loads), and power up.
Floppy Installs
Remember, if you're using the bootdisk.img and the network, you're going to have the driver disk in hand.If you're using a stock bootdisk.img -based floppy, before you get any drivers loaded up you will still need to tell the program from where to get its ks.cfg file. In this example, we manually point it to the web share that we've created when it gives up the boot prompt:
boot: linux ks=http:// example.com/instalIs/ks-server.cfg ksdevice=eth0
You will then have to manually feed it the drvnet driver floppy so it can see the network and go to the ks.cfg file that you pointed it to.If you're running a custom build (automated) floppy and configured your boot floppy correctly, it should default to the proper URL for the ks.cfg (even though you may not see it), load the syslinux boot environment, and then prompt you for your driver disk(s). At this time you'll need to start feeding it floppies for whatever hardware you need access to during the install (usually just the drvnet disk).Regardless of the type of floppy install you're going with (manual or automatic), you will need to insert the pcmcia.img disk (if you have a PCMCIA-based network card) and/or your drvnet.img disk for network drivers. Also, if you are installing any block device or mass storage devices such as SCSI drives or RAID controllers or the like, you'll also want the dvrblock.img floppy handy.After these drivers are all loaded and if you're running a customized/automated bootdisk.img floppy, the Anaconda installer should take off and start following your kickstart config file and scripts. No more intervention should be required.
| Note | If the automation aspect of the installer stops somewhere and it starts prompting you for questions that are supposed to be automated (such as the keyboard, mouse, partition layout, and so on), this indicates that there is a problem in your kickstart config file. It's probably a typo, or maybe you left something commented out that shouldn't be (the clearpart or part lines are common mistakes). Go back and check your install script line by line. |
CD Installs
CD installs are a bit nicer if you ask me. If you've set up your own custom boot.iso CD with the preconfigured ks.cfg network pointers, then this is really a fire-and-forget operation. Just be sure not to walk away and forget about it if you have configured the kickstart to reboot when it's done. Doing so would put the machine into a perpetual install-reboot-install-reboot loop that will most likely get you a visit from your NOC (network operation center) wanting to know who's been DoSing the network and eating up the network bandwidth all day. This type of event usually lands one a colorful nickname with your cohorts as well.If you are using a stock boot.iso-based CD image, you will still have to give only one piece of information at the initial boot : prompt:
boot: linux ks=http://example.com/installs/ks-server.cfg ksdevice=eth0
| Tip | If your install does stop, hang, or start asking you questions that should be automated, use the virtual terminals detailed in Table 2-3 to look at the various parts of the install mechanism. After the install has begun, CTRL+ALT+F2 will give you a root bash prompt so you can see the hard drive where the files are being installed, poke around the kernel modules, config files, and so on. Just be aware that this shell is a very sparse minimalist implementation and is for basic troubleshooting only-no man pages or advanced functionality. However, you can do things like FTP out, download packages, and affect changes on the system. Just be careful. ALT+F3 gets you the install log, ALT+F4 all kernel messaging, and ALT+F5 all partitioning and formatting information. These can really help you when tracking down problems (and some times fix them) during your first few install troubleshooting sessions. Above all, take your time and read the logs to help you troubleshoot problems in your ks.cfg file. It usually takes several attempts to come up with a perfect install script. |
You are now armed with all the information that you need to kickstart your own desktop, workstation, server, or customized systems automatically and from any network enabled PC.
