Chuck Anderson wrote:
On Fri, Nov 21, 2008 at 08:20:14AM -0600, Les Mikesell wrote:
Les Mikesell wrote:
Matej Cepl wrote:
On 2008-11-20, 07:00 GMT, Les Mikesell wrote:
Maybe - but it isn't a real solution. You still have to deal with
identifying the device before and during the labeling process. If
you can do that, you didn't really need the label.
Sorry, maybe I don't understand, but what's so difficult on the
following?
tune2fs -l /dev/sda1 |awk '/UUID/ {print $3}'
The disk may be unformatted at this point and not have a UUID.
I know it is bad form to follow up to my own posting, but I think I've
been making my argument in the wrong way so far. I'm not really against
changes in the way things are done or even the details of those changes
as long as they are exposed somehow. What I am against is hiding those
changes in anaconda or other parts of the installer process so that the
only reasonable way to build several machines is to automate the way you
interact with anaconda with another tool like cobbler, and after it is
built you can't change anything.
We need a way to do the things that only anaconda knows how to do at
times other than the initial install. For example, you want to move a
working system disk to another machine, or replace the booting disk
controller, or restore your backups onto a similar system. Or clone a
bunch of copies of the same boot/system disk and expect them to run in
different machines. It doesn't really matter how this is accomplished,
just that there is a plan for it and hopefully it doesn't involve a
human needing to know every possible thing that anaconda knows about
hardware. Could there be a way to re-run anaconda after moving a
system to new hardware and do an automatic fix-up?
I thought good disks had built-in UUIDs in the firmware (perhaps this
is only for Fibre Channel). Or you could use the serial number which
shows up under "smartctl -a" to identify physical disks. And some
fancy disk shelves have "identify disk" commands which blinks some LED
on the front of the disk.
Once you know which physical disk is the one you want, you can clone
to that disk and then reset the UUIDs or LABELs to unique values.
There are several different layers to this problem - and it isn't really
restricted to servers. Everyone needs to know that if their machine
dies they can move the system disk to a similar box or restore their
backups and keep working. So, consider the simple where you move a scsi
boot drive to a new machine that has a different scsi controller and
different ethernet adapters. You can boot in rescue mode from the
install CD and have your old partitions automatically mounted, so
obviously it is possible to figure the driver issues out - but the thing
that can figure it out won't fix things for you. So first you have to
get the right drivers to be included and get rid of the old ones by
twiddling modprobe.conf in some magic ways, build a new initrd, and
perhaps re-configure grub to use it. And if you restored from a backup,
add in making sure the partition identifiers (whatever they might be
this week) match the identifiers in /etc/fstab or you won't even get to
the point where the rescue boot will mount the system to fix it. You
also have much the same problem when adding new hardware after the
initial install or if you swap NIC or disk controller cards. Everyone
needs this basic capability. Server admins just need to be able to
repeat it predictably across a lot of machines.
Once you have the machine in bootable condition with the right drivers
connected to the available hardware, you need a way to interactively
explore the new hardware without a gui, sort of like running 'fdisk -l'
will enumerate the drives and current partitioning, but this tool has to
be adapted to any new ways of describing mountable objects. Similarly a
tool like mii-tool should enumerate your NICs and show which have link
established - and any other useful information they can detect. Then,
once you understand the setup for any hardware type you need to be able
to script it repeatably for any number of instances with a way to supply
whatever variables it might need (i.e. mac addresses, UUID's, etc.).
My objections to the changes in fedora are not so much related to any
details of a change but that they aren't encompassed by scriptable text
based tools that list and set the options or if those exist they are
fragmented into a bunch of choices that have to match whatever anaconda
did that you may not know about.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
