Bug 205137 - No such file or directory error when installing from LiveCD
No such file or directory error when installing from LiveCD
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
Depends On:
  Show dependency treegraph
Reported: 2006-09-04 12:32 EDT by Jasper O. Hartline
Modified: 2008-05-06 20:48 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 20:48:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Anaconda remote exception dump log (40.33 KB, text/plain)
2006-09-04 12:32 EDT, Jasper O. Hartline
no flags Details

  None (edit)
Description Jasper O. Hartline 2006-09-04 12:32:39 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.

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):

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/
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.
Comment 1 Jasper O. Hartline 2006-09-04 12:32:39 EDT
Created attachment 135504 [details]
Anaconda remote exception dump log
Comment 2 Jasper O. Hartline 2006-09-14 10:40:04 EDT
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
Comment 3 Jasper O. Hartline 2006-09-15 11:35:37 EDT
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?
Comment 4 Paul Nasrat 2006-09-19 09:08:56 EDT
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?
Comment 5 Jasper O. Hartline 2006-09-19 10:06:04 EDT
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 @@
             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"
-            os.execv (path, ("syslogd", root, log))
+            try:
+                os.execv (path, ("syslogd", root, log))
+            except:
+                pass

     def stop(self):
         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
is great.

If any information provided here is incomplete please let me know.

Comment 6 Paul Nasrat 2006-09-19 11:51:14 EDT
An image would be helpful in trying to debug. Do you get the option to drop into
pdb as with a standard anaconda install?
Comment 7 Jasper O. Hartline 2006-09-19 15:16:51 EDT
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:

User: root
Password: livecd

The syntax is simple: kadischi <repository URL>
The repository can be local or remote.
Comment 8 Jasper O. Hartline 2006-09-19 15:18:52 EDT
Oops. The URL was wrong, here is the correct URL:

Comment 9 Jasper O. Hartline 2006-09-23 09:16:48 EDT
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?
Comment 10 Jasper O. Hartline 2006-09-28 07:02:43 EDT
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?
Comment 11 Paul Nasrat 2006-09-28 07:44:49 EDT
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. 
Comment 12 Red Hat Bugzilla 2007-08-21 01:25:31 EDT
User pnasrat@redhat.com's account has been closed
Comment 13 Bug Zapper 2008-04-03 14:07:47 EDT
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.
Comment 14 Bug Zapper 2008-05-06 20:48:47 EDT
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:

Note You need to log in before you can comment on or make changes to this bug.