Vishal Kotcherlakota's questions

So, I've been trying to get a kickstart install with Red Hat Enterprise Linux 6.2 to work, using the package repo on the DVD. As such, I've tried using the following line in my ks.cfg:

 repo --name="Red Hat Enterprise Linux"  --baseurl=cdrom:sr0 --cost=100

However, that doesn't seem to work. The installer can't find the repo, and the install fails. Have I got the repo syntax wrong?

UPDATE: It looks like I've got a more serious problem. Even if I boot without using the kickstart file, the installer reports that there is a problem with the generation of my install tree. I'm going to go ahead and run this install manually now, but it is a bummer that I can't get kickstart to work. :(

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'm trying to create a "Magic DVD" that will install and configure RHEL 6.2 just the way we want it the first time, every time.

Here's the process I've been trying to use, just to prove the concept:

Perform the install manually as intended. Allow anaconda to create /root/anaconda-ks.cfg. Copy the contents of the RHEL install DVD to a directory on my hard drive.

 mkdir -p /home/derp/RHEL/diskFiles   
 cp /media/RHEL_6.2\ i386\ Disc\ 1/* /home/derp/RHEL/diskFiles

Move /root/anaconda-ks.cfg into said directory, at the top level:

 cp /root/anaconda-ks.cfg /home/derp/RHEL/diskFiles/ks.cfg

Create a new ISO file using the appropriate commands. (Taken from this link.)

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

From this point, it should be straightforward:

• Burn the file to disk (or, in this case, connect the VM's "optical drive" to the ISO file.)
• Boot the machine.
• Cry tears of joy as the machine installs itself.

So here's the issue: My re-mastered ISO works fine booting and starting anaconda, but once it gets there, nothing happens. I'm confused as to what I've missed--it looks quite similar to an answer I found here. As I understand it, the anaconda-ks.cfg file should have executed the exact same install I performed to build the system. The only thing I added to the file was the autostep --autoscreenshot command so that I could see what it was doing.

I do notice that some of the partition commands are commented out, but I can't figure out if that's what's causing the the issue. Judging by the fact that the re-mastered ISO boots properly, I think I've screwed up the ks.cfg file and/or not specified a boot parameter I needed to. I've pasted in my ks.cfg below:

#version=DEVEL
autostep --autoscreenshot
install
cdrom
lang en_US.UTF-8
keyboard us
network --onboot no --device eth0 --noipv4 --noipv6
rootpw  --iscrypted $6$CLfKLztawb7ZJq.O$d9iWhj6/SC..72WZFOtiy6t90DfTkTGZ9xgJ/8Cy.xKVNLlv6tmqf73uxeP0mvZT481kvyQzDi7uLon5fUAAw/
firewall --service=ssh
authconfig --enableshadow --passalgo=sha512
selinux --enforcing
timezone --utc America/Los_Angeles
bootloader --location=mbr --driveorder=sda --append=" rhgb crashkernel=auto quiet"
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
#clearpart --all --drives=sda

#part /boot --fstype=ext4 --size=500
#part pv.008002 --grow --size=1

#volgroup vg_dbs01 --pesize=4096 pv.008002
#logvol /omnyx --fstype=ext4 --name=lv_omnyx --vgname=vg_dbs01 --size=81448
#logvol / --fstype=ext4 --name=lv_root --vgname=vg_dbs01 --size=8192
#logvol swap --name=lv_swap --vgname=vg_dbs01 --size=4064
#logvol /var --fstype=ext4 --name=lv_var --vgname=vg_dbs01 --size=8192

repo --name="Red Hat Enterprise Linux"  --baseurl=cdrom:sr0 --cost=100

%packages
@base
@client-mgmt-tools
@core
@debugging
@basic-desktop
@desktop-debugging
@desktop-platform
@directory-client
@fonts
@general-desktop
@graphical-admin-tools
@input-methods
@internet-applications
@internet-browser
@java-platform
@legacy-x
@network-file-system-client
@office-suite
@print-client
@remote-desktop-clients
@server-platform
@workstation-policy
@x11
mtools
pax
python-dmidecode
oddjob
sgpio
genisoimage
wodim
abrt-gui
certmonger
pam_krb5
krb5-workstation
gnome-pilot
libXmu
%end

Help would be met with much gratitude.

I'm currently using a VM running on ESXi 5.0 to dry-run installation procedures for a software product. We're trying a whole different bunch of things, so I'm making extensive use of snapshots to save my place at various points.

Now, I know a thing or two about snapshots, and I know that they're essentially deltas against the base VMDK, and over time that situation can get problematic. I'm okay with the snapshots in this specific case, since the snapshots (and the VM itself) aren't for long-term use. The VM itself is going to get blown away once we're done with the procedures.

So here's where my question actually comes in. It's more of a thought experiment, so bear with me. If I were to export an OVF backup of the VM, would I expect problems because it's got snapshot data? I'm in the habit of making sure the disk is fully consolidated with no snapshots, but I'd like to know if there's a purpose to that practice.