On Wed, Jan 4, 2012 at 8:22 AM, Denniston, Todd A CIV NAVSURFWARCENDIV
Crane <todd.denniston@xxxxxxxx> wrote:
>>> > It's a very common problem. Another way is to have a %post script in KS
>> > or after initial startup as a VM, that fixes the file based on what the
>> > VM properties are.
>>
>> It happens in real hardware too if you move a disk to a different
>> chassis, clone a drive, restore a backup to similar hardware, etc.
>>
>> Where is the best documentation on what triggers the rules to be
>> rewritten, how the bios location works, etc.?
>
> I gave up on tricking UDEV, it was easier to work with the system with my clones.
> `system-config-network-cmd -e` yields a text file that, you can have either a firstboot script or the booting sysadm,
> `system-config-network-cmd -i -c -f file.txt` will pull back in and reconfigure the system after ifdown'ing eth0.
> For good measure I also blanked (and restorecon'd) resolv.conf and hosts prior to pulling in the file.
>
Thanks, but does that control the device naming order? My boxes
generally have 4 to 6 NICs, with at least 2 active. Every time I
touch something the system wants to change the names around. With
5.x, once the MAC addresses were known and in the ifcfg-* files the
names generally were stable unless something triggered kudzu to run
and replace them. With 6.x even that is not reliable. I need
something that will tie the ip config to a certain physical nic and
keep it there. Sometimes I know the MAC addresses ahead of time when
cloning. Should I expect substituting them into this file to nail
things down or is udev still involved separately?
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
