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-2.0.1.1-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): How reproducible: 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 install # kad: no install media setting #cdrom # kad: english/us default lang en_US.UTF-8 langsupport --default=en_US fr_FR keyboard us # 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 --startxonboot --hsync=31.5-57.0 --vsync=50-70 --defaultdesktop=GNOME # 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> rootpw secret # kad: closed firewall should provide decent initial safety #firewall --enabled --port=22:tcp firewall --enabled --port=22:tcp # default authconfig --enableshadow --enablemd5 # kad: selinux not yet happy with kadischi #selinux --enforcing selinux --disabled # kad: Kansas is the center of the world right? GoogleEarth thinks so. timezone --utc America/Chicago # kad: bootloader handled by kadischi bootloader --location=none # kad: no partitioning for livecds #clearpart --none # kad: no firstboot firstboot --disable # kad: don't wait for user interaction #halt/poweroff/reboot reboot # kad: non-interactive install # text/cmdline(or graphical if not specified) cmdline %packages @base @office # kad: experiment #%post %post --nochroot cp -v /etc/hosts /etc/hosts.buildsystem Actual results: Expected results: Additional info: 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"): ## 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.