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 7 install. Steps to Reproduce: 1. Scrub machine. 2. Install Fedora 7, then update. 3. Try to upgrade to Fedora 9. Actual results: It didn't go well. Well, it didn't go at all really. Expected results: 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 suggestions. 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. The process: Insert Fedora 9 DVD. Reboot. "Upgrade." 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 consistent. UGH. 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 should operate. 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.