Questions[anaconda](server)

http://isoredirect.centos.org/centos/8/isos/x86_64/

What's the difference between CentOS-8.1.1911-x86_64-boot.iso and CentOS-8.1.1911-x86_64-dvd1.iso?

I imagine the DVD is an installer which let's you choose which packages to install during initial installation. I might offer live boot, not sure.

The one that with -boot I imagine is a Live CD (or USB) to try the OS or maintenance/rescue of an existing system. Does this one also provide an installer for a minimal system so I don't have to use 7GB bandwidth and disk space? Where can I get such an ISO, I don't see a minimal intaller, just "-boot"

I've been playing around with Kickstart on RHEL 6.2, and that involves re-mastering the install ISO. I've noticed something strange, though. If I issue the following command once (where diskFiles is the directory I've kept the DVD files)...

mkisofs -o file.iso -b isolinux/isolinux.img -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -R -J -v -T diskFiles/

...I can't create a working ISO again unless I use a fresh copy of the DVD files. Errors can range from isolinux failing to boot to Anaconda not finding the RHEL install image. So, here's my questions:

1. Are the isolinux files within my diskFiles directory getting modified when I create the ISO?
2. If so, what files should I replace whenever I try creating another ISO? I know copying the entire DVD over again works, but it seems unnecessary.
3. If not, is there something I might be missing in the process that would explain this?

Essentially, my question is this: How is mkisofs doing its magic, and what does it do to the boot image in the process?

I need to make a driver disk for anaconda. This disk would contain an updated module for the network card of a somewhat recent laptop and the goal is to get a network install of CentOS 6.2 working. I am using cobbler so even the kickstart file itself is on the network. I don't mind if the installation is not completely unattended and I don't mind sticking a USB stick with the driver disk image during the install and manually selecting the correct item, but I do want to keep everything else on the network (kernel image, initrd, kickstart file, RPM repositories).

I already got the updated driver built, and I even have a "kmod" RPM built with the help of /usr/lib/rpm/redhat/kmodtool. Unfortunately I have found absolutely no documentation on what a driver disk looks like.

http://www.phil.muni.cz/~letty/linuxfaq/pracovni/driver-disk-howto is the only link I could find, and it describes the struggle of someone who did the same thing I did - downloaded driver disks and tried to explore them. Unfortunately the format in CentOS 6 seems to have changed and the best I could do is to get anaconda to tell me that: "Driver disk is invalid for this release of CentOS.". The log itself says "cannot find /tmp/drivers/rpms/x86_64/repodata" and until now I have not seen a driver disk with "repodata" on it.

Currently diving into the anaconda source code but I hope someone can point me in the right direction.

Basically I want an ARGV like usage on the PXE command line, but I can't see any documentation to do this.

basically I want to pass something like

scientific-linux-6 HOSTNAME VLAN

then in %pre hit some APIs to get the networking info I need to append it to the KS config. This part is easy, if I have the parameters.

Finally in %post I want to kick off a chef run and boot strap to chef server. This also needs to know hostname / domain name ( basically have hostname -f not blow up ), but this shouldn't be too bad if I can complete the above. Sadly, this was my original goal, but then it failed when I realized I didn't have the hostname set yet.

Here is what I have learned so far.

$ cat linux-install/msgs/param.msg 



                        09Kernel Parameter Help07

Some kernel parameters can be specified on the command line and will be
passed to the running kernel.  This does not include options to modules
such as ethernet cards or devices such as CD-ROM drives.

To pass an option to the kernel, use the following format:
     0flinux <options>07
If a different installation mode is desired, enter it after the option(s).

For example, to install on a system with 128MB of RAM using expert mode, 
type the following:
     0flinux mem=128M expert07

To pass options to modules, you will need to use the expert mode to disable
PCI autoprobing.  When the installation asks for your device type that needs
an option or parameter passed to it, there will be a place to type those
in at that time. 

Sweet!? So that means on PXE I can go like...

scientific-linux-6 linux ARGV_APPEND

Right?

Then getting things into %pre and %post I found This presentation and a few other mentions

Stick this at the top of the %pre section, and it will take anything of the form var=value
from /proc/cmdline and turn it into a variable you can use directly

set -- `cat /proc/cmdline`

for I in $*; do case "$I" in *=*) eval $I;; esac; done

So that means I can say

scientific-linux-6 linux HOSTNAME=foo.example.com, VLAN=ddd

Right?

Then in %pre That means I can

Hit my API to get IP, mask, gateway and then change network to something like

network --bootproto=static --ip=10.0.2.15 --netmask=255.255.255.0
 --gateway=10.0.2.254 --nameserver=10.0.2.1

As described Here

Then that sets up us in %post for our chef-client run.

My question is. Does it sound like this will work? Is there a better way? Surely someone else has done this before?

Update ( Solution implemented based on answer )

On the PXE command line I ended up passing options

$ hotbox linux prefix_varname="foo" prefix_another_var="bar"

( everything after linux is put on /proc/cmdline . hotbox was the PXE label. ) Then in %post I parsed /proc/cmdline (in Ruby) looking for all the variables that matched /prefix_*/ and turned them into a hash. This lead to passing it off the chef for further configuration based on the results of a web request.

Note: Razor wasn't around when I did all this. I personally wasn't satisfied with razor, and we are still using more or less the above method.

When doing a default install of RHEL5 and higher (at least - don't recall if it has done it longer), Anaconda will setup your drives into a logical volume group - even if there is only one drive.

What is the purpose/reasoning behind using LVM atop a single drive? I understand why you would want to over RAIDed drives or across multiple disks of [potentially] different sizes, but not if there is only one disk.

Is it merely to provide for the opportunity to add additional space down the road if you happen to change your mind about how much space a given machine should have assigned to it?