Red Hat Bugzilla – Bug 185830
anaconda run under kadischi corrupts the host build system?
Last modified: 2007-11-30 17:11:27 EST
Description of problem:
While running kadischi, the network on my system (the host build system) was
reconfigured. Specifically, it has a static IP address. The kadischi kickstart
file I was using specified dhcp. During the phase where the output of my
commandline kickstart install was paused on this output
Installing openoffice.org-graphicfilter-188.8.131.52-11.2.2... Done [404/404]
Performing post install configuration...
the network got reconfigured. I noticed because I was logged in via ssh. I
then went to the console, did a /etc/init.d/network restart, and it switched
back to the static ip address and things were happy.
Version-Release number of selected component (if applicable):
Haven't tried yet, but I suspect very reproducable.
Steps to Reproduce:
1. use command like the following
kadischi -C --kickstart=/path/to/testks.cfg /mnt/fc5t3 /opt/kadisos/test.iso
2. have system configured with one ethernet, with a static ip address and able
to get a different ip via a dhcp server if it was so configured
3. use a kickstart file like the following
# kad: doing an install, not an upgrade
# kad: no install media setting
# kad: english/us default
langsupport --default=en_US fr_FR
# kad: as generic as possible
mouse --device=/dev/input/mice genericwheelusb
# kad: as generic as possible xconfig
# kad: for _now_, assume vesa video driver
# kad: for _now_, assume a respectable low end monitor
#monitor:: Generic CRT Display; Monitor 1024x768; MS_1024; 31.5-57.0; 50-70
xconfig --noprobe --driver="vesa" --resolution=1024x768 --depth=16
# kad: bug workaround, need to have an entry here for non-interactive
network --device=eth0 --bootproto=dhcp --hostname="alpha.livecd.example"
# kad: stateless install, post install and runtime scripts will deal with
# dynamic runtime hardware autoconfiguration
#device eth0 xxx --opts=""
device eth0 tulip --opts=""
# kad: not so secret root password
#rootpw --iscrypted <insert crypted pw here>
# kad: closed firewall should provide decent initial safety
#firewall --enabled --port=22:tcp
firewall --enabled --port=22:tcp
authconfig --enableshadow --enablemd5
# kad: selinux not yet happy with kadischi
# kad: Kansas is the center of the world right? GoogleEarth thinks so.
timezone --utc America/Chicago
# kad: bootloader handled by kadischi
# kad: no partitioning for livecds
# kad: no firstboot
# kad: don't wait for user interaction
# kad: non-interactive install
# text/cmdline(or graphical if not specified)
# kad: experiment
cp -v /etc/hosts /etc/hosts.buildsystem
was using a fairly default fc5t3 install, and cvs version of kadischi. I've
been following the fedora-livecd-devel list recently, and haven't noticed any
recent changes which might involve this behavior.
This seems like it is probably a bug with the way anaconda is run on the
kadischi build system. Anaconda should not be doing anything that could effect
the build host system. If kadischi could(can it?) be run as a user instead of
root, this sort of system corruption would not be possible.
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"):
## "You're running me on a live system! that's incredibly stupid.\n")
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: Withdrawing address record for
192.168.1.203 on eth0.
Mar 18 15:38:25 rig avahi-daemon: Interface eth0.IPv4 no longer relevant
Mar 18 15:38:26 rig avahi-daemon: New relevant interface eth0.IPv4 for mDNS.
Mar 18 15:38:26 rig avahi-daemon: Joining mDNS multicast group on
interface eth0.IPv4 with address 192.168.1.105.
Mar 18 15:38:26 rig avahi-daemon: IP_ADD_MEMBERSHIP failed: Address
already in use
Mar 18 15:38:26 rig avahi-daemon: 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-184.108.40.206-1.1... Done [467/479]
Installing xorg-x11-drv-v4l-0.0.1.5-1.1... Done [468/479]
/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
/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.