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
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.
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
Version-Release number of selected component (if applicable):
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/
Anaconda fails right at installing packages.
Anaconda invoked from the LiveCD with Kadischi should allow a user to partition,
format, and install Fedora Core using an online repository source.
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
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:
--- 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 @@
rdev = os.stat(dev).st_rdev
- os.mknod("%s/dev/root" % (instPath,), stat.S_IFBLK | 0600, rdev)
+ os.mknod("%s/dev/root" % (instPath,), stat.S_IFBLK | 0600, rdev)
# return the "boot" device
--- 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"
- os.execv (path, ("syslogd", root, log))
+ os.execv (path, ("syslogd", root, log))
if self.pid == -1:
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
If any information provided here is incomplete please let me know.
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:
The syntax is simple: kadischi <repository URL>
The repository can be local or remote.
Oops. The URL was wrong, here is the correct URL:
The two patches shown above have been added to Anaconda in RAWHIDE as of:
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 firstname.lastname@example.org'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:
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: