<div>Solved the problem by adding "biosdevname=0" to the kickstart kernel options, which disables the NIC renaming. The second problem is still unsolved, but it's not a show stopper.</div><div> </div><div>-Tomi<br>
<br></div><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Tomi Salmi</b> <span dir="ltr"><<a href="mailto:tomisalmi123@gmail.com">tomisalmi123@gmail.com</a>></span><br>
Date: 25 October 2012 09:44<br>Subject: Re-provisioning issues<br>To: <a href="mailto:spacewalk-list@redhat.com">spacewalk-list@redhat.com</a><br><br><br><div>Hi,</div><div> </div><div>I'm noticing some unexpected behaviour when re-provisioning physical Fedora 16 systems from Spacewalk 1.7. While the following problems are most likely not directly related to each other, they are a part of the same workflow.</div>

<div> </div><div>1) In my environment, most network interfaces get renamed to p5p1 or similar during the initial bare-metal install, which works flawlessly. However, re-provisioning a system from Spacewalk causes Cobbler to add an additional eth0 interface to the profile with the same preferences as the original interface has. This will generate a duplicate entry in dnsmasq (managed by cobbler), which then causes dnsmasq to crash/stop.</div>

<div> </div><div>2) The webgui does not update the "deploy configuration files" and "kickstart complete" checkmarks when re-provisioning a system, while the client has finished all steps succesfully. I have added "reset_base_channel = 0" to /usr/share/rhn/config-defaults/rhn_server.conf but it should be the cause of this issue?</div>

<div> </div><div>Basically, re-provisioning a system from SW leaves me with dnsmasq stopped and a never ending kickstart task in the webgui. </div><div> </div><div>Any advice or suggestions are welcome.</div><div> </div>
<div>
Best regards,</div><div>Tomi Salmi</div>
</div><br>