starting Fedora Server SIG

Les Mikesell lesmikesell at gmail.com
Fri Nov 21 14:20:14 UTC 2008


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 at gmail.com




More information about the fedora-devel-list mailing list