Bug 448322 - sys-unconfig doesn't reset NIC name mappings
Summary: sys-unconfig doesn't reset NIC name mappings
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
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:

  /etc/udev/rules.d/70-persistent-cd.rules
  /etc/udev/rules.d/70-persistent-net.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):

initscripts-8.76.2-1.x86_64
udev-120-5.20080421git.fc9.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
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
  or
  2) have them stuck as eth2, eth3, etc.
b

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
firstboot.


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