Red Hat Bugzilla – Bug 205137
No such file or directory error when installing from LiveCD
Last modified: 2008-05-06 20:48:49 EDT
Description of problem: While running Anaconda under Kadischi from a LiveCD built with Kadischi I get an OSError no such file or directory when trying to install a regular system. The files do in fact exist, I have checked this with ls in the /tmp/cache/anaconda-base-200609012237.i386/headers directory. This seems to be an exception occuring from an earlier "bug" possibly in Python or Anaconda somewhere. I'm not convinced the file(s) don't exist yet. :P Attached is the full anacdump.txt and looking at it reveals only that /dev/mapper couldn't be created since it exists, /var/lib couldn't be created because it exists and is mounted. None of what I can see relates directly to the error. Version-Release number of selected component (if applicable): anaconda-11.1.0.89-1 How reproducible: Build a LiveCD with Kadischi installed to it, boot the LiveCD and supply Kadischi with a URL to an online repository mirror. Steps to Reproduce: 1. kadischi http://mirrors.kernel.org/fedora/core/development/i386/os/ 2. 3. Actual results: Anaconda fails right at installing packages. Expected results: Anaconda invoked from the LiveCD with Kadischi should allow a user to partition, format, and install Fedora Core using an online repository source. Additional info: anacdump.txt attached.
Created attachment 135504 [details] Anaconda remote exception dump log
Is there any way we can work on this, perhaps rectifying the issue before Fedora Core 6 final is released, it would be really neat to have this functionality available at that time, in the least. Any ideas on where to start debugging the issue, as I have plenty of time to look.. ? J. Hartline
It has been suggested that something is removing the file after the open has occured, which wouldn't surprise me since I see two instances of Anaconda running when running under the LiveCD environment, two threads if you will, one attached to the tty1 and one not. What keeps these two threads from stepping on each other? Is it something I can fix on this side of the fence with Kadischi or perhaps with teh target LiveCD environment?
Does kadischi use vanilla anaconda or additional patches? Installs are working successfully in rawhide. I don't see kadischi in extras so I don't really have any good way of testing. Does a normal anaconda install work fine from that mirror?
Anaconda has to be patched in two places, as per the current Anaconda in RAWHIDE to even get through to start package selections and stuff, however I do not believe teh two patches are causing the error. Let me show you those now: --------------------BEGIN-------------------------- --- fsset.py.orig 2006-09-16 20:06:21.000000000 -0500 +++ fsset.py 2006-09-16 20:11:45.000000000 -0500 @@ -1285,7 +1285,10 @@ isys.makeDevInode(root.device.getDevice(), dev) rdev = os.stat(dev).st_rdev - os.mknod("%s/dev/root" % (instPath,), stat.S_IFBLK | 0600, rdev) + try: + os.mknod("%s/dev/root" % (instPath,), stat.S_IFBLK | 0600, rdev) + except: + pass # return the "boot" device def getBootDev(self): --- syslogd.py.orig 2006-09-16 20:07:19.000000000 -0500 +++ syslogd.py 2006-09-16 20:12:13.000000000 -0500 @@ -73,8 +73,11 @@ if os.access (f+"/syslogd", os.X_OK): path = f+"/syslogd" break - - os.execv (path, ("syslogd", root, log)) + + try: + os.execv (path, ("syslogd", root, log)) + except: + pass def stop(self): if self.pid == -1: ---------------------END--------------------------- Also what has to happen, since Anaconda uses utilities in /usr/sbin and not in /sbin like mke2fs, tune2fs, like on a real installed system, symlinks are placed on the LiveCD filesytsem, to symlink tools from /sbin to /usr/sbin. This allows for porper partitioning (sfdisk) and formatting (mke2fs). Kadischi is in fact not in Extras, it is in extras-devel under CVS. What I had to do was this, build a LiveCD with kadischi in it's payload, while adding the patches to Anaconda. This works well. Invoking Kadishci from the LiveCD environment of course produces the stated error, about 5 out of 6 times you will try to install to a system from the LiveCD, so it doesn't happen _everytime_ but most of the time. Kadischi is available from CVS though. A normal install, does in fact work from this mirror mirrors.kernel.org. Using the RAWHIDE repository. You mentioned you have no reliable way of testing, the best I can do is build a small image for you about 200MB large (It's small because of SquashFS) which would take you straight into the termnal and that's it. From there all you would need to do is invoke Kadischi with a mirror as an argument. This is the best I can do, I will report a URL from my personal webspace, where you can get the small about 200MB image. If you wish to use it for testing, that is great. If any information provided here is incomplete please let me know. Thanks.
An image would be helpful in trying to debug. Do you get the option to drop into pdb as with a standard anaconda install?
Yes, the option is available to drop into pdb as would a standard installation. I have created the image and have just tested it here locally, and it does exactly as expected, which is fail right as packages are to be installed. The image is just over 250MB. Here is the URL: http://autopsy.liveprojects.info/LIVE/CD/rawhide.iso http://autopsy.liveprojects.info/LIVE/CD/SHA1SUM User: root Password: livecd The syntax is simple: kadischi <repository URL> The repository can be local or remote.
Oops. The URL was wrong, here is the correct URL: http://autopsy.liveprojects.info/CD/rawhide.iso http://autopsy.liveprojects.info/CD/SHA1SUM
The two patches shown above have been added to Anaconda in RAWHIDE as of: anaconda-11.1.0.99-1 with minor modifications. So there is no need to patch if using the latest RAWHIDE Anaconda. I was able to patch python-urlgrabber grabber.py in _do_grab and only close() with new_fo.sloce() after the os.utime call is made, which produces a "Cannot open Package header" error which is different than before. This tells me the first assumptions about the file dissapearing may actually be happenning. Do we have any clue yet as to what is really happenning here at all?
Just checking again, is there any progress on this report at all? Something I can do here possibly to help in testing, apply a patch or anything? Is this issue non-fixable?
I downloaded the image and was unable to reproduce on first attempt. Higher priority issues are taking up my time, I will look at this when I get a chance.
User pnasrat@redhat.com's account has been closed
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp