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):
Steps to Reproduce:
This may be a topic for disagreement, but IMHO the sys-unconfig tool should
reset the NIC device name mappings. Opinions?
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.
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
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.
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.
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
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.
Actually, I wonder if long term it's best to just nuke the state, and reenable
Will be in 8.95-1