Bug 205137

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'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

We have a pretty new Shiny LiveDVD installer in Fedora 28 now it's all good thanks pnasrat for your help.