f9 grub kernel arguments and kickstart questions

[Skunk Worx]

Tim wrote:
> On Fri, 2008-06-13 at 21:54 -0700, Skunk Worx wrote:
>> I see that my f9 installs have a grub kernel argument
>> 'root=UUID={hex}'
>>
>> Could someone tell me a little about this? I've used things like 
>> root=/dev/VolGroup00/LogVol00 for seems like ages.
> 
> It's a unique ID for each partition.  The system can tell one partition
> apart from another, no matter what the volume label, or physical
> location (e.g. /dev/hda).  Meaning that you can always refer to a
> partition by it's UUID, and get the right one, no matter where it's
> connected.
> 
>> Does this impact things like disk cloning or jumbling packs between 
>> machines?
> 
> Yes.  Depending on your needs, it makes life easier, or more difficult.
> 
> If you want to move a drive about, and not have it clash with other
> drives using the same volume labels (e.g. having fights with two drives
> both labelled as /home or both as LogVol00), then UUID is a great
> benefit.
> 
> On the other hand, if you want to take /home from one box and re-use it
> as /home in another box, you'll need to rewrite the fstab file to either
> use labels, or change the UUID from the old to the new.
> 
> I can't see it being a problem if you're cloning a drive.  An exact copy
> of one drive should be an exact copy.  So a clone should work as a drop
> in replacement.
> 
> Though if you're cloning drives to turn a group of drives into an array,
> something tells me that that's going about things in the wrong way.
> 

I won't have the issue of two root drives installed in the same machine, 
and I won't be moving /home between machines.

I will definitely have the issue of installation on one machine and 
runtime on another, and the issue of N packs installed in N machines in 
some random order.

I doubt I'll have any array cloning other than the obvious...we might 
have a tower with a master drive cloned to several target drives 
simultaneously. But it will be N disks into N machines at runtime.

Sounds like I'll be fine in any case. My concern was the UUID could 
somehow be constructed from the mac address or other things, linking the 
drive to the machine, like you-know-who tends to do.

>> If so, is there a way to specify the older method in a kickstart file?
> 
> You can refer to them just the same as you did beforehand (device names,
> volume labels, or volume groups).
> 

I've always used the basic anaconda generated config from 
post-dvd-install and modified that. The anaconda/kickstart 
documentation, and the comments in the kickstart file, do not make it 
clear (at least not to me!) how to specify a root=/VolGroup00/LogVol00 
vs. a root=UUID= definition.

It's no problem to edit this after the install, just a curiosity.

Does anyone have a syntax example of how to differentiate these in a ks 
file?

>> Also I know I can 'append' things in kickstart like "vga=791
>> acpi=force reboot=b', but can I remove the 'rhgb quiet'?
> 
> "rhgb" is an *optional* graphical boot progress display.  I found
> booting quicker without the additional delay caused when this starts up.
> And others have found they've had less graphic card driver problems
> without it, too.
> 
> "quiet" is an *option* to hide some of the messages printed when the
> system starts to boot.
> 

Sorry my question was not clear...I want to *remove* the two options via 
kickstart...have them not be in the grub.conf after the network install.

I know I can append things, but these two options always seem to be 
there, forcing me to edit them out after the installation. It's no 
problem to do that, but if I can do it in kickstart it's one less change 
I have to make later.

I prefer  the older text scrolling...even if it takes a little longer to 
boot...our installs have to run on a lot of different cards and displays 
and IMHO this has been a more reliable way to see failure messages 
during the boot sequence.

Thanks,
John