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?
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
