From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080416 Fedora/2.0.0.14-1.fc8 Firefox/2.0.0.14 Description of problem: I tried using preupgrade to upgrade from FC8 -> F9. (I had previously done a yum upgrade; yum clean all; preupgrade as root.) Anaconda started up. When I got to the screen where it asked me to select between a fresh install or upgrading my existing FC8 installation, I selected the latter, then clicked on the "Next" button. The "Next" button immediately became gray, but then the system seemed to go silent. I could still move around the mouse pointer, but there was no further response from the system. The hard drive was not spinning. I left it for 5 minutes or so but still got no indication of progress and no feedback and no sign that it was doing anything. Thinking that things had frozen, I rebooted at that point. That was a mistake. Anaconda hosed my system: it seems that it had replaced /etc/fstab with a 0-byte file, so when I went to reboot into my prior FC8 installation, that failed miserably. Replacing /etc/fstab with its proper contents has allowed me to boot again but this was not a fun experience. Suggestion: If this kind of silent semi-freeze is expected, then modify Anaconda/preupgrade's UI to provide some indication that progress is happening and give a progress bar showing how long one should wait. In any case, it seems like setting up things so that rebooting in the middle of an install is unnecessarily hazardous to user data. For obvious reasons, I have not tried to reproduce this! (The bugzilla requires me to enter enter some reproducability, but ignore that -- no way I am going to try to reproduce this blindly and put my data at risk.) Version-Release number of selected component (if applicable): preupgrade-0.9.3-3.fc8 How reproducible: Always Steps to Reproduce: 1. Run preupgrade 2. Reboot 3. Follow instructions in summary above Actual Results: /etc/fstab corrupted, system unbootable! Expected Results: /etc/fstab should be left undisturbed until Anaconda is ready to put new contents in it, and then the change should be done in an atomic transaction. Moreover, Anaconda/preupgrade should provide progress bars indicating progress so that it's clear when it has or hasn't hung/frozen. Additional info: # rpm -q anaconda anaconda-11.3.0.50-2
Checking whether this has been fixed (wondering whether I can trust preupgrade again in the future).
Changing components, since preupgrade does not modify fstab at any point.
What's your partition/disk layout like? Unless you had something *really* strange in fstab, I'm thinking this is probably a combination of two things: 1) Bad UI preupgrade gave anaconda enough info to skip most of the prompts.. except the 'Upgrade which system?' one. So when you hit 'Next' there, it went into a bunch of long-running code and didn't give you any feedback about what it was doing. You (understandably) thought it had hung, and rebooted the system. 2) Delay in updating fstab You're absolutely right; fstab should be updated atomically (and the original fstab should be saved, for safety's sake). In Fedora 10, anaconda gives much better feedback about what it's doing - it gives progress windows for pretty much every long-running part of the upgrade process. Furthermore preupgrade-1.0.0 directs it to perform the upgrade (almost) completely automatically, so there's none of this "Click Next and nothing seems to happen" stuff. So I think the UI issues are solved, but I don't know if anaconda is updating fstab atomically and/or keeping a backup. Would definitely like to see the latter in F11, at least.
Thanks for the comments. That makes sense. My fstab is a bit weird but not totally outlandish: /dev/sda5 ext3 / /dev/sda6 ext3 /usr /dev/sda7 ext3 /var /dev/sda8 swap /dev/sda9 ext3 /opt /dev/sda10 ext3 /scratch /dev/sdb5 ext3 /home.old and in particular /boot is on /, not on a separate partition of its own (something that I recall has caused issues in other contexts in the past), so I suspect that you have accurately explained it.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
F10 anaconda does make a backup copy of the fstab before writing a new one, so you'll be able to recover that. The real question here is what was happening in that long pause. Delays of that length are definitely not expected, which is why there's no UI feedback going on there. It seems to me there may be some sort of strange hardware probing delay going on, but we don't really have any way of determining that without being able to reproduce the problem. James, Will - ever seen anything like the very long delay in upgrades like is described in the initial comment?
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.