Red Hat Bugzilla – Bug 450460
Anaconda considered harmful
Last modified: 2008-06-17 17:03:57 EDT
Description of problem: Anaconda is harmful.
Version-Release number of selected component (if applicable): Whatever is on the
Fedora 9 install DVD.
How reproducible: To reproduce, that would be hard. I'd have to go back to
Fedora 7 and upgrade again. That's part of the problem - Anaconda ate my Fedora
Steps to Reproduce:
1. Scrub machine.
2. Install Fedora 7, then update.
3. Try to upgrade to Fedora 9.
It didn't go well. Well, it didn't go at all really.
Should have worked or, failing that, shouldn't have even tried.
Additional info: This is going to be kind of long and hopefully constructive.
After spending a few hours trying to recover from this a little frustration
might leak in but hopefully not too much.
Typically when I upgrade I try to avoid Anaconda. The odd install kernel,
upgrade Yum, install the packages list package, Yum update seemed to work ok.
When I have used Anaconda it's always been more delicate than maybe it should
be. Anyway this is the process as it occurred today which is followed by some
This particular machine was running a pretty updated Fedora 7. Time to take it
to 9. I was thinking I should maybe upgrade twice: 7->8->9 but then figured the
Fedora 8 DVD might be hard to locate so I'll just try 7->9. That was a mistake.
Insert Fedora 9 DVD.
Don't go scrubbing my drives. Anaconda really wants to scrub drives and, to me
anyway, that's an acknowledgment that the tool is just too delicate. I have
data and see no reason that a simple upgrade should just erase that so I told it
just leave them alone. After it reached about 600 of 900 packages it tossed an
exception and that was the end of that try. The only option was "reboot." Then
it got kind of ugly. In the past a failed upgrade generally left the old OS in
place until right at the end. Not this time. My Fedora 7 install was gone from
grub and the kernel appears to have been erased. Um, ok.
Reboot and select "Upgrade" again. "Fedora 9" was the only listed OS so that's
a sign that it already ate Fedora 7. Fine, whatever, just fix that one. It
installed 77 packages and said it was done. After a reboot it froze on the
loading HAL Daemon and never returned. I tried a couple of times and it was
Reboot and select "Install." This should be a fresh install and thus should
work but it ran into a package conflict and wouldn't install. rsyslogd and
something else. Still toast.
I grabbed the Fedora 7 DVD and booted that with "rescue mode." Walked into the
var directory and wiped out the yum, rpm, and mlocate directories.
Insert Fedora 9 DVD and select "Install" again. This time it didn't get a
package conflict and installed. It's an "install" instead of "upgrade" and thus
I'll be spending hours cleaning up but that's that.
That is what brought me to this point which is some suggestions on how Anaconda
1) Anaconda is primarily an installer. In "install" mode it should just work.
It really wants to scrub the hard disks, which is just begging to erase
people's data, and really shouldn't. If the drive is EXT3 and valid it should
install - full stop. What would that take? Pop up a message when people elect
not to have it erase all of their data and let them know the previous OS will
need to be erased. Do what I did: wipe out the RPM, YUM, and whatever other
files exist on the drive to ensure a successful install. Scrub /bin /lib/
/whatever but ensure it's going to succeed. "Install" is the one thing it
should do - everything else is optional.
2) For "Upgrade" don't be like a retarded puppy. When it saw that I had Fedora
7 it maybe should have popped up a message and told me "this is going to be
iffy. We'd recommend you upgrade to Fedora 8 first and then to Fedora 9 as that
is more likely to succeed." Then, again, go scrub the rpm, yum, and whatever
else is most likely to have it fail. Leave the old grub and kernel in place
until the end.
3) Don't try to default to erasing people's data. Scrubbing the hard disk is a
last resort and no good can come of that. Erase any rpm/yum/whatever history it
takes but just punting and blowing away valid EXT3 hard disks is a cop out for a
tool that doesn't work.
To me it appears the methodology has changed. Never before did it wipe out a
valid earlier edition until towards the end. That has changed. A sign was
when, after telling "Disk Druid" or whatever that is to just leave my drives
alone the next screen told me it would write partition data. What? I told it
not to touch my drives so that message was not good.
Again, I'll reiterate, the biggest cause of Anaconda failures on upgrades will
be old packages. Leave the files be - just wipe out the history of them.
Worked for me just fine in the end.
Did you save the exception that anaconda threw the first time?
The rsyslog thing is a package issue, not a problem with anaconda.
"Did you save the exception that anaconda threw the first time?"
Sadly no. "Save" would mean write down with pen and paper as the machine wasn't
in any state to save anything. Yes, I should have anyway but I didn't.
"The rsyslog thing is a package issue, not a problem with anaconda."
Yes, and no.
If nothing else can be gained from that long report, this should:
On an install Anaconda should not fail due to package conflicts with existing
packages on a valid drive. On an "upgrade" I can see it. Not on an install.
If a machine has an invalid package state, this one didn't but let's move on,
the easiest way to "recover" is a fresh install. Given that people have data
files they don't want to lose formatting the drive is not the best solution.
I'll reiterate, on an install to a valid drive with existing packages, two
possible solutions exist:
1) Figure out the packages on the drive causing conflict and erase them. This
would be hard.
2) Simply erase any history of any packages on the target hard drive. This
will remove any potential conflicts in packages. There may be file conflicts
but those are easier as overwrites within the RPM handle that.
Is it possible that the package conflict was within the Fedora 9 DVD? Possible
but unlikely. After I mounted the drive in rescue mode and wiped out RPM, YUM,
and MLocate's history the install went swimmingly.
I understand "upgrade" is fraught with danger. I accept that a "double upgrade"
is walking the trapeze with no net. On an "install" though it should just work.
The way to do that is nuke what it takes to make it happen. Not much needed to
be nuked. I know this as that is exactly what I did. That could be automated
and added to Anaconda.
Consider it a request for enhancement.
To the best of my knowledge, the package conflicts have not been resolved, as I
have encountered them when testing installations. I would agree with you that
the install should not fail, and I think there should be an option to skip the
conflicting package or packages (or to pick one) rather than have the only
option be to restart the installation, so I'll see what can be done about that.
As for the data loss.. I don't know whether anaconda was going to overwrite the
existing data anyway, or whether it was lost because the installation failed and
the system got confused.