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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
