Bug 448322 - sys-unconfig doesn't reset NIC name mappings
Summary: sys-unconfig doesn't reset NIC name mappings
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-05-25 21:19 UTC by Carl Roth
Modified: 2014-03-17 03:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-04-16 20:10:14 UTC

Attachments (Terms of Use)

Description Carl Roth 2008-05-25 21:19:21 UTC
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 15:01:30 UTC
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 20:03:22 UTC
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 20:12:24 UTC
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 20:40:57 UTC
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 20:56:52 UTC
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.