Red Hat Bugzilla – Bug 353501
Backtracking panels to correct information subsequently crashes anaconda
Last modified: 2008-01-10 11:59:51 EST
Description of problem:
Walked through the disk selection and software selections to just before the
step where one would agree to commit the changes. Since the wrong disk was
chosen as the boot disk, I backtracked to that panel, made the correction, and
then went forward. (Dis this twice before hitting the menu button to accept).
Once the menu button was depressed, Anaconda died.
Version-Release number of selected component (if applicable):
FC7 Test3 October 1 DVD release version.
Steps to Reproduce:
Can you attach the exception dump to this bug report, or at least the error
message you are getting?
I wish I could respond with an error message, but I am unable to.
And to recreate, I would have to destroy what I installed to do so.
From memory, I booted the DVD, told anaconda to own the hard disk (take
defaults, wipe the disk, including mbr install according to its algorithm and to
install grub on the same disk).
I continued with "package install selectioning", and then decided that I wanted
my own /home partition in lv.
I backtracked to just where anaconda showed the lv layout, and decided that I
needed the /home, which I selected.
In the summary screen I noted that I wanted at least 12 gigs for /home, returned
to increase the size, and all was OK.
After re-doing the package selection (in most cases, just doing a right click to
select all), I clicked on option button to commence installation.
That is where anaconda crashed on it's own and presented the bios boot up
screen. It took the system back out to that level.
I don't consider this a serious bug on which to lose sleep, as one does not do a
re-install every day.
============ Other topic start
If I was going to have anaconda improvements, it would be for next version to
fedora9, where I would like the option to fix a faulty grub installation in the
mbr, or even better, that anacron via grub, performs a backup of the existing
mbr to a /boot/mbr.timestamp file, before updating the actual mbr. And of
course via system rescue, to have the ability, to take a mbr.filestamp file and
restore it to the mbr.
I have lost many hours trying to recover damaged mbr files due to anaconda due
to my mis-understanding of what will happen based on the onscreen documentation.
========= Other topic end
In closing, this is a less then low level of priority problem, but it is
repeatable. I would not pursue it or try to duplicate what I did more than one time.
Here is some helpful information.
System is a ASUS motherboard with p4 3 gighrtz The processor is an intel P4.
The hard disk is a pata 80gig drive as /hdb or /sdb. The award bios is current
Good luck with your researching.
I believe this should be fixed in rawhide. Feel free to reopen this bug if you
continue to see problems in F9. Thanks for the bug report.