Missing any tricks to minimize bloat [of absolute-minimal kickstart-based static boot media caused by new “noloader” anaconda architecture] ?

[Spike White]

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=http://143.166.6.45/redhat/RHEL6/64/install

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:  https://gist.github.com/pauljeff/4b9ad551cb6c35870d7c



Am I missing any tricks?


BTW, I’m able to spin a “minimal LiveCD”
https://projects.centos.org/trac/livecd/wiki/CreateImage  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/kickstart-list/attachments/20140905/b40e9ae7/attachment.htm>