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.
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 installer.
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.
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 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.
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.
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.
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.
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.