Bug 49632 - Cannot upgrade from 7.0 to 7.1; "internal error" from anaconda
Cannot upgrade from 7.0 to 7.1; "internal error" from anaconda
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Brent Fox
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-22 02:26 EDT by jay
Modified: 2007-04-18 12:34 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-24 14:14:51 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)
Anaconda crash dump (9.85 KB, text/plain)
2001-07-22 02:29 EDT, jay
no flags Details

  None (edit)
Description jay 2001-07-22 02:26:44 EDT
Description of Problem:
During text-mode upgrade with driver disk (advansys module, SCSI CD-R)
anaconda eixted with an internal error, providing a dump file and saying
that I should report this problem. 

How Reproducible:
100%

Steps to Reproduce:
1. Insert boot disk.  
2. Reboot; type linux text <RETURN>
3. Select UK keyboard, insert driver disk when prompted
4. Select option to update existing installation
5. Wait 

Actual Results:
Fatal upgrade error (and assisted reboot).   Dump file (see attached)

Expected Results:
Successful upgrade

Additional Information:
See attached.
Comment 1 jay 2001-07-22 02:29:02 EDT
Created attachment 24468 [details]
Anaconda crash dump
Comment 2 Brent Fox 2001-07-24 11:40:14 EDT
We have seen this problem before, but we never figured out why it happens.  The
installer is trying to remove the anaconda-rebuilddb that it uses during the
upgrade process, but it's not finding the file.  The only thing I can think of
is that /mnt/sysimage has been unmounted for some reason.  We have added code so
that the installer won't crash if it can't find the file...it just ignores the
error.  That should avoid the problem in future releases, but it doesn't explain
 why the file is getting lost in the first place.  Is /var a symlink on your
system by any chance?
Comment 3 jay 2001-07-24 14:12:58 EDT
No, /var was a separate ext2 filesystem on the same IDE disk as the root 
filesystem.  

I'm pretty certain that /mnt/sysimage and /mnt/sysimage/var were still mounted 
at this stage, I think I looked in another VC.   However, I'm not absolutely 
certai - I could have been looking after the reboot.

Might I suggest tht in future versions of the program, the results of something 
like "ls -lR /var/lib" be included in the crash dump...  This may help you 
diagnose the problem. 
Comment 4 jay 2001-07-24 14:14:46 EDT
When I said it was 100% reproducible, I mean that I tried the upgrade, and got 
this error the first time.  I then freed up extra space in /, /var and /usr.  
After that, it didn't happen again. 
Comment 5 Brent Fox 2001-08-10 00:23:50 EDT
We have put a try/except loop around this statement that should at least catch
the error and go on.  I'm not sure why it can't delete the temporary database,
but it should at least handle the error without crashing.

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