Bug 448322 - sys-unconfig doesn't reset NIC name mappings
sys-unconfig doesn't reset NIC name mappings
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-25 17:19 EDT by Carl Roth
Modified: 2014-03-16 23:14 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-16 16:10:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Carl Roth 2008-05-25 17:19:21 EDT
Description of problem:

The sys-unconfig tool is supposed to unconfigure the system so that it can be
reconfigured cleanly on the next boot cycle.  One important configuration step
missed by this process (sys-unconfig and rc.sysinig) is the persistent state
generated by the udev rules:


As a side note, I was quite surprised to find persistent hardware state lurking
in the udev rules area.

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

This may be a topic for disagreement, but IMHO the sys-unconfig tool should
reset the NIC device name mappings.  Opinions?

Additional info:
Comment 1 Bill Nottingham 2008-05-27 11:01:30 EDT
Well, the obvious issue is at the time sys-unconfig is run, the rules have
already *taken effect*. So you'd need to reboot without the rules to have a
fully clean system.
Comment 2 Carl Roth 2008-05-27 16:03:22 EDT
Um, isn't that the point of sys-unconfig?  I want the tool to unconfigure the
machine completely, so that the next reboot will start with a fresh hardware and
software profile.

My specific situation is that I'm deploying a system image built in a VM
(qemu+kickstart).  When the system image is transferred to a physical machine, I
don't want to have remnants of the qemu VM hardware settings lying around.
Comment 3 Bill Nottingham 2008-05-27 16:12:24 EDT
Maybe I'm not clear. You touch /.unconfigured, you ship off the image, and you
reboot. On that reboot:

- It resets the password. Once you continue, you have the new password.
- It resets the keyboard. Once you continue, you have a new keyboard map.
- It removes the udev persistent rules. Once you continue... you have your
  new devices still named something that explicitly avoids conflicting with
  the old persistent rules, and you either:
  1) have them change on the next boot
  2) have them stuck as eth2, eth3, etc.
Comment 4 Carl Roth 2008-05-27 16:40:57 EDT
It would be nice to accomplish this without the extra reboot...  I can see from
rc.sysinit that udev gets started before the .unconfigure check is done, making
this more difficult.

In my own testing I'm using a homebrew script that scribbles in /etc before the
sys-unconfig reboot; this makes sys-unconfig process more than just a trivial
'touch' command.

Other non-linux systems I've worked with followed this approach -- the
'sys-unconfig' script was a one-way trip that neutered the machine until it
could be reconfigured at the next boot.
Comment 5 Bill Nottingham 2008-05-27 16:56:52 EDT
Actually, I wonder if long term it's best to just nuke the state, and reenable

Note You need to log in before you can comment on or make changes to this bug.