<div dir="ltr">All, We do [kickstart-based essentially unattended] static, DHCP and PXE Linux imaging at work. But 90% is static builds. My focus below is on kickstart-based static builds. Because attaching virtual media to our remote server consoles is *so* slow, I slim down the static boot media to the bare minimum. 40 MB, as of RHEL 6.5. That's largely just the vmlinuz + initrd.img (Even 40 MB is slow.) From ~RHEL3 up to RHEL 6.5, that meant I only have to drop a vmlinuz, initrd.img and syslinux.cfg on my USB boot image. (For convenience, I use a FAT32 fs, but ext2/3 would work also). The RHEL 6.5 syslinux.cfg looks like this: LABEL rhel65_x86_64 MENU label ^RHEL 6.5/64 (prod build) MENU INDENT 3 KERNEL /boot/rhel/6.5/x86_64/vmlinuz APPEND initrd=/boot/rhel/6.5/x86_64/initrd.img nofb ramdisk_size=10000 ks=hd:LABEL=MINIBOOT:/ks.cfg So the provisioning engineer will craft 30 - 40 ks.cfg files (via ks.cfg web builder page). Each called ks-<server>.cfg. Crack open the USB boot media, deposit all in top directory, button back up. Will use same boot media for all 30 – 40 servers that provisioner builds that day. ks-<server>.cfg has these two relevant lines: url --url=<a href="http://143.166.6.45/redhat/RHEL6/64/install">http://143.166.6.45/redhat/RHEL6/64/install</a> network --bootproto=static --ip=10.194.53.143 --netmask=255.255.255.0 --gateway=10.194.53.1 --nameserver=143.166.33.44 --hostname=hiutest03.<domain> That is, each ks-<server>.cfg is unique for each server. But the boot media is generic for all servers and all provisioners. Apparently, this worked with static builds because the loader of the old anaconda architecture “pre-parsed” the network and url line of the ks.cfg. Anaconda’s loader brought the network up, then went to the specified URL to pull the stage2 image, etc. It all worked. BTW, depending on server model & role, the public interface is on different NICs. Since I didn’t specify the specific network interface in the network line above in the ks.cfg, the old anaconda would pop up a list of possible NICs. The provisioner would select the one that’s public for this role & model of server. Also when the old anaconda couldn’t find the specified “ks.cfg” it popped up a screen asking for the name. So the provisioner replaced “ks.cfg” with “ks-<server>.cfg”. I’m guessing the new “noloader” anaconda re-architecture starting in Fedora 17 is what now disallows this absolute minimal kickstart boot media. I know it doesn’t work in RHEL7.0 (which is ~Fedora 19). For static builds, it appears that now it requires either: • all static IP info must be specified in the kernel boot options via ip=<ip>::<gw>:<nm>:<hostname>:<iface> • or stage 2 bootloader must be included in static-based boot media. And kernel boot options must specify via: inst.stage2=hd:/MINIBOOT/squashfs.img (or LiveOS.iso) That is: 1. Either each boot media must be unique. (Which means the provisioners can't spin 1 media w/ 30-40 ks.cfg files and attach to 30-40 servers). Would look like this: LABEL rhel65_x86_64 MENU label ^RHEL 7.0/64 (prod build) MENU INDENT 3 KERNEL /boot/rhel/6.5/x86_64/vmlinuz APPEND initrd=/boot/rhel/6.5/x86_64/initrd.img nofb ramdisk_size=10000 ks=hd:LABEL=MINIBOOT:/ks.cfg ip==<ip>::<gw>:<nm>:<hostname>:<iface> Or 2. The boot media must have squashfs.img embedded. I.e., instead of 40 MB boot media, it's now 300 MB. (Which means it'll be much slower to pull image.) It'd look like this: LABEL rhel65_x86_64 MENU label ^RHEL 7.0/64 (prod build) MENU INDENT 3 KERNEL /boot/rhel/6.5/x86_64/vmlinuz APPEND initrd=/boot/rhel/6.5/x86_64/initrd.img nofb ramdisk_size=10000 ks=hd:LABEL=MINIBOOT:/ks.cfg inst.stage2=hd:LABEL=MINIBOOT:/squashfs.img It’d be like this: <a href="https://gist.github.com/pauljeff/4b9ad551cb6c35870d7c">https://gist.github.com/pauljeff/4b9ad551cb6c35870d7c</a> Am I missing any tricks? BTW, I’m able to spin a “minimal LiveCD” <a href="https://projects.centos.org/trac/livecd/wiki/CreateImage">https://projects.centos.org/trac/livecd/wiki/CreateImage</a> and embed that squashfs.img or LiveCD.iso. So then it’s only 200 MB total. That’s still quite slow to transfer to remote consoles. For completeness: · PXE builds are unaffected. (Worst case, I could do ks.device=bootif in the pxelinux.cfg.) · DHCP builds will be similarly affected. Since vmlinuz/initrd.img is now completely non-interactive, it doesn’t pop up a screen with list of NICs and ask which one to use to acquire DHCP address (like RHEL 6.5 did). (All NICs will have link, so "ks.device=link" isn't viable.) Also – on somewhat-related topic, we are *very* excited by the “minimal” install option offered by this new anaconda architecture. Previously, we’d “security-harden” the RHEL 5/6 builds by removing over 100 RPMs. It’s always easier to build up -- add RPMs to an “@minimal” build -- than to work out all the dependencies to remove RPMs from an “@base” build. As you can tell, we’re huge into kickstart so removing “individual package selection” in anaconda doesn’t hurt us a bit. (But then, we’re atypical -- an enterprise customer first and Fedora hobbyists only in our spare time.) Spike</div>