Bug 185830

I was unable to reproduce this issue.
If you could try to, that would be good, and provide the 
/tmp/anaconda.log after occurance.

There was another report where Anaconda nuked a /etc/resolv.conf file.
Which, seems highly unlikely since /etc/resolv.conf is modified by hand or by
dhclient(8) on a host system.

They could be related, may not be.

Created attachment 126323 [details]
anaconda log from instance of bug

/tmp/anaconda.log from a run that invoked this error.

yes, it's 100% reproducable.  3 times in a row.  And after pouring over the
anaconda code for the last few hours, I think anaconda is just lightyears away
from being remotely safe to run on a host system that you care about not
corrupting.  I think I'm going to start investing time into generating my base
system with vmware or xen, rather than falling into this category 

"
# let people be stupid
## # don't let folks do anything stupid on !s390
## if (not flags.test and os.getpid() > 90 and flags.setupFilesystems and
##     not iutil.getArch() == "s390"):
##     sys.stderr.write(
##         "You're running me on a live system! that's incredibly stupid.\n")
##     sys.exit(1)

"

Also, here are some /var/log/messages from the host system.  Yes, this daemon is
running on the host system.  Somehow I doubt the 3 times this behaviour
happening at the same point in a kadischi(anaconda) run, was a coincidence.

Mar 18 15:38:25 rig avahi-daemon[2068]: Withdrawing address record for
192.168.1.203 on eth0.
Mar 18 15:38:25 rig avahi-daemon[2068]: Interface eth0.IPv4 no longer relevant
for mDNS.
Mar 18 15:38:26 rig avahi-daemon[2068]: New relevant interface eth0.IPv4 for mDNS.
Mar 18 15:38:26 rig avahi-daemon[2068]: Joining mDNS multicast group on
interface eth0.IPv4 with address 192.168.1.105.
Mar 18 15:38:26 rig avahi-daemon[2068]: IP_ADD_MEMBERSHIP failed: Address
already in use
Mar 18 15:38:26 rig avahi-daemon[2068]: Registering new address record for
192.168.1.105 on eth0.

Ok, I was a bit tired/frustrated last night.  I should note that the anaconda
let people be stupid line doesn't directly apply to kadischi, as

flags.setupFilesystems is false for us

But the comment about running anaconda on a live system being incredibly stupid
is a case where the author had the forethought to emphasize a point that should
have been emphasized.

My question is:  what is the assumption with anaconda --rootpath.  Should any
aspect of the system, other than the contents of the rootpath directory be
effected by anaconda?  If that is the assumption, and I think it is, then this
bug is an example of something that slipped through the cracks.  And I suspect
there may still be others.  I'm curious, could some selinux policy hacker come
up with a way to restrict anacondas priveleges to only being able to modify
files under rootpath?  I.e. if it ever tries to touch any other files, or
hardware, it gets slapped down by the MCP (sorry, I watched tron recently).

I'm trying to reproduce this, and simply can't.
I have several machines here also with static IP addresses.
Also using kickstart with any options other than the current host system.

I would suggest filing a bz entry under Anaconda and be sure to reference this
bug number there also, likewise that one here as they are related.

note, that anaconda is also resetting the timezone, which I confirmed from
skunk's post on fedora-livecd.

Here is the terminal and anaconda.log output and specifically exactly where the
tails on a remote machine hung because the build machine's ip address changed. 
Note also the evidence of the timezone bug-

terminal output -

Installing xorg-x11-drv-siliconmotion-1.3.1.5-1.1...  Done [467/479]
Installing xorg-x11-drv-v4l-0.0.1.5-1.1...  Done [468/479]
Installing xorg-

/tmp/anaconda.log output -

06:50:11 DEBUG   : ignoring openjade>docbook-dtds in whiteout
06:50:28 DEBUG   : ignoring nautilus>nautilus-cd-burner in whiteout
06:50:41 INFO    : moving (1) to step install
06:50:41 INFO    : moving (1) to step enablefilesystems
06:50:41 INFO    : moving (1) to step migratefilesystems
06:50:41 INFO    : moving (1) to step setuptime
04:50:41 INFO    : moving (1) to step preinstallconfig
04:50:41 INFO    : moving (1) to step installpackages
04:50:41 INFO    : Preparing to install packages

a couple other quick things I noticed.  Being paranoid I did an ls -altr on the
host system after the kadischi build.

/etc/resolv.conf changed, obviously due to picking up a dynamic nameserver when
it went to dhcp (the /etc/init.d/network restart failed to recover my orig
resolv.conf).

/etc/mtab changed, but I'll assume that was do to some chroot
mounting/unmounting of proc.

But *** importantly, I noticed these peculiar entries in my /etc

lrwxrwxrwx  1 root root      27 Mar 12 10:46 protocol -> ../mnt/runtime/etc/protocol
lrwxrwxrwx  1 root root      22 Mar 12 10:46 joe -> ../mnt/runtime/etc/joe
-

And of course /etc/localtime was also modified as par the timezone bug.

Maybe this needs to be reassigned to anaconda-maintenance.

Unfortunately I cannot find any traces of this behavior on three different
systems of varying hardware types, and FC4/FC5.

These should be fixed in anaconda CVS.