Bug 70560 - Anaconda crashes when attempting to upgrade a RH 7.0 system to RH 7.3
Anaconda crashes when attempting to upgrade a RH 7.0 system to RH 7.3
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-02 10:47 EDT by Shanan Levin
Modified: 2007-04-18 12:45 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-08-19 16:20:23 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)
dump of failure (pop-up window) plus mahcine and package info. (49.65 KB, text/plain)
2002-08-02 10:49 EDT, Shanan Levin
no flags Details

  None (edit)
Description Shanan Levin 2002-08-02 10:47:37 EDT
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):


How reproducible:
Always

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 
this bug.
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)

FAILURE:
An unhandled exception has occured. This is most likely a bug...

options within the failure window include (debug) (save to floppy) the dump is 
attached

Expected Results:  normally, the upgrade should continue after reading in the 
necessary packages to update but anaconda crashes and the whole update attempt 
fails.

Additional info:

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.
Comment 1 Shanan Levin 2002-08-02 10:49:03 EDT
Created attachment 68467 [details]
dump of failure (pop-up window) plus mahcine and package info.
Comment 2 Michael Fulbright 2002-08-02 12:31:47 EDT
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?
Comment 3 Shanan Levin 2002-08-02 15:24:39 EDT
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.
Comment 4 Shanan Levin 2002-08-02 16:32:19 EDT
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.
Comment 5 Michael Fulbright 2002-08-05 12:08:55 EDT
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
installer.
Comment 6 Shanan Levin 2002-08-07 11:44:18 EDT
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 
BIOS. 

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 
handled exception).

Thanks for your help.
Comment 7 Shanan Levin 2002-08-12 13:57:08 EDT
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.
Comment 8 Jeremy Katz 2002-08-14 18:04:50 EDT
Added /bin/sh to the list of things we check as being relative symlinks in CVS
Comment 9 Mike McLean 2002-08-19 11:01:12 EDT
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
bash-2.04-11
[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.
Comment 10 Shanan Levin 2002-08-19 11:57:41 EDT
mikem,
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.
Comment 11 Shanan Levin 2002-08-19 12:26:22 EDT
mikem,
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 
failures.

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.
Comment 12 Mike McLean 2002-08-19 16:20:18 EDT
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.
Comment 13 Mike McLean 2002-08-19 16:51:00 EDT
CLOSED->RAWHIDE

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.

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