Red HatThis forum is for the discussion of Red Hat Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I've setup plumbing for doing Kickstart deployments with RH9, RH-ES3 and RH-ES4 from an HTTP server using a bootable CD. For each machine I insert the CD, press reset, remove the CD and 10 minutes later I'm looking at a freshly installed RedHat platform. Everything works great.
However each new round of testing must be done on a freshly installed OS so I would like to fully automate the (re)deployment process rather than having to manually visit every machine in the lab with each new build. Once a machine has been initially deployed with Linux, I would like to be able to invoke a fresh redeployment via a telnet/ssh session.
FYI, I've been told that pxeboot and/or etherboot are not options which I can pursue. Even if allowed, these solutions seem very hardware-sensitive and may potentially pose significant maintenance challenges.
I can imagine several other ways to do this, but wanted to troll for better suggestions.
1. Enable the CD as the first bootable device, reboot and at the end of the deployment disable the CD as the first bootable device. I've found no generic way to enable/disable the CD as the boot device. All of the mechanisms I've found so far only work in DOS, are vendor/model specific and usually don't work off-the-shelf with brand new hardware. Is there a generic mechanism for doing this which works well from Linux?
2. Setup a hidden DOS partition so I can invoke the Kickstart installer via Loadlin from a batch file. Then I can unhide or hide this partition as needed. I am certain that I can do this, but currently consider this tactic to be a last resort. I would rather not have to involve DOS and a FAT partition if possible.
3. Invoke the kickstart installer directly from a Linux shell. I've not found a way to do this, but this is what I hope to be able to accomplish.
It seems reasonable to believe that if I can accomplish #2 using Loadlin from DOS, then I should be able to accomplish #3 from a Linux shell. But I've been searching and experimenting for some time with no success...Is this possible? Are there other mechanisms available which I should consider for accomplishing this goal?
Even today, many machines still boot from floppy before checking HDDs. Have you tried creating a kickstart server and booting your systems from floppy? Not only does this solve your problem, but it also assists your re-deployment by centralizing the distribution.
Downsides include high network usage and the requiremnt of having a server set up specifically for the install files, but, you're not wasting near as many man hours, and a deployment can usually be accomplished much faster.
The main problem with this approach is that somebody still has to remove the floppy after the deployment or the system will simply redeploy itself over and over and over.
Along the lines you suggested, the first tactic that I mentioned was to be able to programatically diddle the boot order bits. I've already crafted a bootable CD (which is much faster than a floppy and can hold lots of extra tools for speeding and simplifying post-install logic) which does the full-blown RedHat deployment--simply insert CD, press the reset button, wait 8 minutes while nearly everything is installed via kickstart, then remove the CD and hit the reset button again. But this still requires QA folks to drive to the lab everytime that a PM hits the build button. If we can close the loop on this process, then QA staff would not need to arrive until test results are available for triage and debugging.
Using your suggestion, if I could programmatically diddle the boot order then custom logic could determine when to enable the CD and thus close the automation loop. BTW, I've looked at the extensible firmware interface (EFI) module for Linux and it holds great promise along these lines. However it needs the efivars module to be compiled into the kernel and that module is not included in shipping RedHat distros. Unfortunately, I'm required to only test on 'shipping' kernels, not custom built kernels, so until the efivars module is shipping in RedHat distros I'm unable to utilize it.