Bug 110394 - a reference to a "non-existent" interepreter on boot images
a reference to a "non-existent" interepreter on boot images
Status: CLOSED NOTABUG
Product: Red Hat Raw Hide
Classification: Retired
Component: anaconda (Show other bugs)
1.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-18 19:29 EST by Michal Jaegermann
Modified: 2007-04-18 12:59 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-10 11:23:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2003-11-18 19:29:34 EST
Description of problem:
Attempts to install over a network or using a CD end up with
"No such file or directory error".  After a peek at stage2.img
and netstg2.img from x86_64/Fedora/base I have a gnawing suspicion
that the problem is that 'anaconda' starts with
#!/usr/bin/python2.2
line but there is no 'python2.2' anywhere in sight on these images;
only usr/bin/python.  For all other Python files in that directory
'file' reports "a /usr/bin/python script text executable" but
not for anaconda.

Version-Release number of selected component (if applicable):
Boot images with a time stamp "Nov 18 03:36".

How reproducible:
Every time.
Comment 1 Jeremy Katz 2003-11-19 16:37:13 EST
Fixed in CVS, just working on some other changes that break trees
horribly before throwing it into rawhide.
Comment 2 Michal Jaegermann 2003-12-14 13:56:59 EST
Looking at images from "Dec 14" I can see at last
#!/usr/bin/python
in anaconda and there are even included anaconda python libraries.
There is one more catch, though.  These libraries reside in
usr/lib64/python2.3 while anaconda includes the following code:

    if os.access("/usr/lib64/python2.2/site-packages/rhpl", os.X_OK):
        libdir = "lib64"
    else:
        libdir = "lib"

This means that 'libdir' will be set to "lib" and things will
still not fly.
Comment 3 David Lawrence 2006-04-10 11:23:34 EDT
Closing due to inactivity. Please feel free to reopen this bug or refile this
bug against the latest release Fedora Core if you feel this bug is still
relevant today.

Thank you

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