Bug 448322 - sys-unconfig doesn't reset NIC name mappings
sys-unconfig doesn't reset NIC name mappings
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2009-04-16 16:10:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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:

  /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 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
  or
  2) have them stuck as eth2, eth3, etc.
b
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
firstboot.

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