From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461;
Q312461; .NET CLR 1.0.3705)
Description of problem:
anaconda crashes after selecting to update the boot loader during an upgrade
from 7.0 to 7.3. Anaconda begins reading the package info. to determine what
needs to be updated, but fails a within a few seconds with an unhandled
exception. The final result after the python error messages in the failure pop-
up window is: "RuntimeError: /bin/sh can not be run". (a dump is attached)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. attempt to upgrade a RH 7.0 i686 system to RH 7.3
2. reboot system with RH 7.3 disk 1 (for i386 arch) in cdrom
3. type enter (for GUI mode) or type text (for text mode) either will reproduce
4. at the welcome screen hit next
5. choose English lang, hit next
6. choose 101 key generic keyboard, US English, Enable dead keys
7. choose generic 3 button mouse PS/2
8. choose upgrade, hit next
9. do NOT customize packages for the upgrade
10. no ext3 migration of /dev/hda1 - / or /dev/hda5 - /var
11. choose to update boot loader
pop-up appears stating: "reading package info"
Actual Results: (pop-up windows appaears)
An unhandled exception has occured. This is most likely a bug...
options within the failure window include (debug) (save to floppy) the dump is
Expected Results: normally, the upgrade should continue after reading in the
necessary packages to update but anaconda crashes and the whole update attempt
The original RH 7.0 system is in its previous fully functional state after the
upgrade failure. No damage done to the original system.
The system is a standard Dell Dimension XPS D266 with 128MB of RAM, a WD Caviar
4.3 GB harddrive, with a 266MHz P-II, with an Intel chipset.
Created attachment 68467 [details]
dump of failure (pop-up window) plus mahcine and package info.
First guess is there were read errors from your CD - it looks like the error log
you attached was truncated. Could you verify there is not more to the file?
I downloaded another copy of the RH 7.3 Disk 1 ISO and burned a new CD.
I tried to upgrade same system using the exact same steps as mentioned above
and reproduced the problem with the new CD. I saved the system's state on
another floppy and both the original dump and the new dump are identical in
size, so I don't think anything is missing from the original attachment (system
state dump) to this bug report.
When I Alt-F2 after the upgrade failure and type "ps" at the installer's shell
prompt (sh-2.05#), I get the following message:
" ps:relocation error: /mnt/sysimage/lib/libnss_compat.so.2: sysmbol
_nss_files_parse_pwent, version GLIBC_2.0 not defined in the file libc.so.6
with link time reference
I get the same message when I "ls -al", but NOT when I "ls" or "cd" or "pwd"
from this shell.
I will try another CD-ROM drive next and report the outcome.
same results with another CD-ROM drive and the freshly burned CD.
I figured I'd try a BIOS update too, but I got the same results. I'm not sure
what else to try to get this system to upgrade to RH 7.3.
The motherboard chipset is an Intel FW82371AB (just in case this is needed).
I also removed one of our proprietary pieces of hardware that was in one of the
PCI slots, but the same upgrade failure remains.
Could you please try a hard drive based upgrade instead? Just put the ISO images
on a hard drive partition choose the 'Hard Drive' option when you boot the
After the BIOS upgrade, the harddisk geometry seems to have changed and this
caused the original installation of RH 7.0 to fail to boot. My boot sector
(lilo) no longer loads passed the first "L" in LILO (then prints 80 80 80 ...
to the screen). I attempted to reload LILO multiple times (it appears to
work), but it continues to fail at the first "L" upon reboot.
So I began a fresh install of RedHat 7.0, which subsequently failed in the same
manner as the RH 7.3 upgrade attempts failed. (I thought that was very
interesting.) Then looking at the hardware detection from the install I noticed
that the harddisk info for /dev/hda looked normal except that CHS was = 0/0/0.
This should not be. I can only guess that something similar was happening
during my original upgrade attempts when tyring to upgrade with the original
Finally, as a last resort (which I should have tried sooner), I reset the BIOS
to "Setup Defaults" (in an attempt to fix my CHS detection (it worked!)) and
tried a fresh install of RH 7.0, which then installed flawlessly. Then the
upgrade of 7.0 to 7.3 worked properly too.
After comparing the "Setup Defaults" with the original BIOS settings, I am
unable to find any obvious significant changes to the settings other
than "Power Management" now being enabled.
I can only guess that a setting in the orginal BIOS was wrong and even after
the BIOS upgrade that setting remained (which I find unusual) until I
chose "Setup Defaults".
If you have any questions please email me.
I'm closing this bug report, as NOT A BUG.
To the best of my knowledge this is NOT A BUG in anaconda (other than a poorly
Thanks for your help.
I'm updating one last time since I have found the source of this error message
with the help of a friend/coworker.
Anaconda crashes when /bin/sh on the harddisk containg the root (/) partition
is a pointer (soft link). For some developement reasons involving different
functionalities in different versions of BASH, /bin/sh is a symbolic link
to /usr/local/bin/bash on some of our development machines.
Apparently, during an upgrade, Anaconda attempts to use /bin/sh from the
mounted harddisk (that will be upgraded) rather than using 'sh' from the
installer CD. I believe this is a bug in Anaconda and feel that unless other
good reasons are given, Anaconda should be using 'sh' from the
installer/upgrade CD and not from the harddisk of the RedHat box that is about
to be upgraded.
At a minimum, please fix Anaconda to do some kind of check for /bin/sh and a
valid BASH version and handle the error '/bin/sh not found' that is thrown in
the Anaconda python script that is running during an install so that this can
be tracked down and corrected by the sys admin doing the upgrade.
I'm reopening the bug, so that someone can fix/update this part of anaconda to
handle the problems I experienced.
Thank You for your help.
Added /bin/sh to the list of things we check as being relative symlinks in CVS
So, in Red Hat Linux 7.0, the version of /bin/sh is owned by bash-2.04-11. In
bash-2.04-11, /bin/sh *is* a symbolic link.
[root@i386-70 /root]# cat /etc/redhat-release
Red Hat Linux release 7.0 (Guinness)
[root@i386-70 /root]# rpm -qf /bin/sh
[root@i386-70 /root]# rpm -V bash
[root@i386-70 /root]# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jul 27 07:49 /bin/sh -> bash
If the above hypothesis is correct, then every 7.0->7.3 upgrade should die,
which is certainly not the case.
I'm going to assume for the moment that the problem occurs when /bin/sh is
symlinked to a file that is not on the root partition.
In RH 7.0 /bin/sh *is* a symbolic link to /bin/bash. On my test system, it is
a symbolic link to /usr/local/bin/bash (this is what makes anaconda crash). No
hypothesis was stated to indicate a belief that the problem lies in /bin/sh
being a symlink. A statement of concern was made that no checking or error
handling was being done to be sure /bin/sh was available to anaconda. One
suggestion was that the shell anaconda uses be from the CD rather than from the
root partition (if this is possible and within reason to implement).
Your assumption for the moment that the problem occurs when /bin/sh is
symlinked to a file that is not on the root partition is a correct assumption.
I forgot to mention in my last post that on the systems we had anconda crash
during an upgrade, those systems had only a single linux partition.
(/usr/local/bin/ was NOT on a separate partition)
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 16635024 6876784 8913224 44% /
none 192348 0 192348 0% /dev/shm
So /usr/local/bin/bash was on the root partition. If I remember correctly when
I switched screens to the installer shell, /usr/local/ did NOT exist under the
installer image mount point. I'm not sure if this info helps since I can't
remember the finer details about the problems I ran into during the upgrade
The only other theory I have (but have doubts about) is that the differing
versions of bash have something to do with anaconda crashing. One of the
anaconda crash messages states that /bin/sh not found, so I doubt the bash
version has a part in this problem.
[levin@plucky levin]$ whereis bash
bash: /bin/bash /usr/lib/bash /usr/local/bin/bash /usr/share/man/man1/bash.1.gz
[levin@plucky levin]$ /bin/bash --version
GNU bash, version 2.05a.0(1)-release (i686-pc-linux-gnu)
Copyright 2001 Free Software Foundation, Inc.
[levin@plucky levin]$ /usr/local/bin/bash --version
GNU bash, version 2.03.0(1)-release (i686-pc-linux-gnu)
Copyright 1998 Free Software Foundation, Inc.
Ok, I guess the normal symlink doesn't cause a problem because it is relative
(/bin/sh -> bash) and it's broken when the root partition is mounted under
/mnt/sysimage, whereas I imagine your symlink is an absolute path (/bin/sh ->
/usr/local/bin/bash) which will be broken by this.
The latest installer catches this problem and pops up an informative dialog.
The upgrade will not proceed, but at least the operator is told why.