Bug 448322

Summary:	sys-unconfig doesn't reset NIC name mappings
Product:	[Fedora] Fedora	Reporter:	Carl Roth <roth>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	9	CC:	iarlyy, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-04-16 20:10:14 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.

Comment 6 Bill Nottingham 2009-04-16 20:10:14 UTC

http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=f501819f31d619e982ac7eeeddb30aea226795bf

Will be in 8.95-1