Installing Fedora from scratch

In our normal high-availability setup, we don't install a new operating system on every PC using the provided standard anaconda method. That would require each PC to be out of action for several hours. Rather, we install it on a single PC, that is, one that can be spared for a length of time, and then clone that installed system to a disk server. PCs and servers that later require that new system can then fetch it in the background to an unused partition. After some scripted tweaks, that system is then ready to be booted immediately. Or it can be made use of from the PC's existing system via some virtualising technique, such as full virtualisation, or application virtualisation via chroot.

The exception to this is when a fresh PC is bought or a failed disk is replaced, so we are starting with an essentially blank disk. In that case, some system or other has to be available on the PC to start things off. So this could be a standard anaconda install. But also it could be a boot from a small system on a USB stick which does the fetch to a designated partition.

Steps

• A kickstart file for Fedora 17 was created, dellpcf17.cfg. This was based on the previous Fedora release with changes so that it installs in a different partition. Things to note about this kickstart file are:
• It specifies a particular single partition for the system to be installed into. In this case it's sda8.
• The bootloader command specifies --location=partition so that the grub bootloader is installed in the first sector of this partition (sda8), not the MBR.
• The kickstart file has a %pre section which does the following:
• If necessary, it partitions the drive: it recognises the type of disk drive from a set of known types and uses sfdisk to apply a predefined set of partitions. My ptn.sh script is useful offline in creating various sorts of partitioning. There is a sda1 reserved for OEM, sda2 for master grub, sda3 reserved for Windows boot area, sda4 extended, and sda5 onwards for systems, a swap area, and a final large area for sharing between the different systems.
• The kickstart file has a %post section which does the following:
• If there is no master grub on the drive, the kickstart %post script it formats sda2 and sets it up to be a master grub area, so that there is a grub stage1 in the MBR code area which knows about a grub directory on sda2, and where that grub directory on sda2 contains the stage2, and a grub.conf. The latter simply is a list of entries for all appropriate partitions, with a chainloader to the grub stage1 on the first sector of each such partition.
• If the system was booted with a "bhamvanilla" kernel parameter, then no extra action is taken. Otherwise, the %post script does a "rsync" to a specific server to provide an "overlay" of particular files on to the system as initially installed. This overlay of files includes an updated /etc/rc.d/rc.local, and various cron jobs, so as you can guess, this easily allows the system to configure itself after first boot. The overlay is repeated hourly thereafter. Using rsync is a very efficient way of checking and if necessary updating the several hundred files which comprise the overlay.
• I used my lnmisc script to hard-link this into an unadvertised directory in my personal web files, so that it could be downloaded at boot time.
• I created a CD or USB stick for network-install of Fedora 17, downloaded from the Fedora 17 website. This could easily be done by PXE boot if this was thought necessary. But a PC or server out of the box needs to have its BIOS configured for security anyway, so it's no additional effort to install via CD or USB stick.

-- LawrenceLowe created this topic in October 2012.