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 couple of hours, and then clone the system from that model PC to a disk server. PCs and servers that later require that new system can then fetch it in the background from the disk server to an unused partition. After some scripted tweaks, that new 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.

Another reason for using a fetch method and not using anaconda to install a system on a particular PC is if the disk partition to be used is smaller than normal. Anaconda can be over-cautious in estimating the disk space requirements, and you may get the following message even though there is actually sufficient room: There was an error running your transaction for the following reason(s): insufficient disk space. You need more space on the following filesystems: 917M / .

A reason why anaconda is sometimes required 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 to the PC to start things off. So this could be a standard anaconda install. But also in future it could be a boot from a small system on a USB stick which does the fetch from the disk server to a designated partition.

Steps to create a model Fedora 17 image

• 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. 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 using the ks=http:// parameter. 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 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 not booted with a "bhamvanilla" kernel parameter, then 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.
    • If the system was booted with the "bhamvanilla" kernel parameter, then the above rsync command is not run but simply stored for future use in /root/install-rsync.sh; also system directories are scanned for files which use file capabilities(7) and the results stored in /root/install.cap.list for future use.

• I downloaded a network install ISO from the Fedora 17 website: page http://fedoraproject.org/en/get-fedora-options#formats, download file http://download.fedoraproject.org/pub/fedora/linux/releases/17/Fedora/x86_64/iso/Fedora-17-x86_64-netinst.iso. I wrote this to a CD (a USB stick would be just as good) using my cdcopyiso script for a network-install of Fedora 17. 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.
• I booted the model PC from this CD, specifying kernel parameters of bhamvanilla ks=http://my.web.server/path.to.my.kickstart . It automatically installed the system, with (as noted above) the grub loader written to the first sector of the designated partition. I then rebooted into the older system on this PC (which was F15) and not into the new system.
• I ran my/root/util/rsync-newdistro-daemon on this PC. It sits there waiting for rsync connections.
• I ran my /root/util/rsync-newdistro-client-f17 on the server which has the model system images. This fetches the image from the model PC. In fact it does so twice, to my images-vanilla/f17 and images-current/f17 directories, as I like to be able to be sure of what tweaks I subsequently apply to the images-current/f17 image.

-- LawrenceLowe created this topic in October 2012.