On Mon, Sep 29, 2003 at 11:02:21AM +0200, Martin Newiger wrote: > Hi, > do you make only fresh installs or upgrade-installs as well? In case you > make only fresh installs, the boot order in BIOS must be something like: > 1) rem. device > 2) HD > 3) CD/DVD > If there is no system on the HD, the install system will be started from > CD. After install and reboot the freshly installed system will be > started from HD. we re-kickstart some machines frequently. Also we want the ability to re-kickstart the machine remotely (to make sure we have a clean machine to work from). With a lot of our servers (DNS/Mail being prime examples) we have all of the config tweaks done in %post (using generated KS config files). so we can kickstart the boxes pretty much at one time and after install they come up and are put right into service. So to answer your direct initial question, I guess the former (frsh only). But on a given physical machine we will do many "fresh installs" (aka nuke the machine and lay down a clean OS) over its lifetime. We really like the ability to know exactly how a machine is set up and that we can reproduce its setup (both for making anyother machine in a cluster and for backup/restore purposes). Best Regards, Steve > >-----Ursprüngliche Nachricht----- > >Von: Steven Roberts [SMTP:strobert-redhat@xxxxxxxxxxxx] > > > >the approach we take (using floppies instead of cd's but the concept is > >the same) is this: > > > > - on the initial install have the BIOS set for floppy boot. > > - as the machine is rebooting change to hard drive boot > > - create an entry in /etc/lilo.conf to allow booting from floppy > > - create a 'nuke' script in root's home dir that changes lilo to boot > >from floppy and reboots the system > > (chmod 400 so it has to be invoked with a /bin/sh /root/nuke to help > >prevent > > accidental re-install) > > > >So the first install (ever on the new machine) have to watch to change > >the BIOS > >but subsequent re-installs can be unattended/remote. > > > >And yes still using LILO, on the list to migrate away from but since > >our > >standard non RHEL deployment is RH7.3 (since it is compatible with > >AS2.1 and ES2.1) not a major issue for us yet. > > > >Regards, > >Steven Roberts
