Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 527343 [details] The logs in /tmp during installation
Your filesystem must be clean for the install to start. We won't install to a dirty filesystem.
I accidentally press Return and the bug gets posted prematurely? Annoying. Here's what I meant to type. ----- I have a machine that has Fedora Core 14 installed on it. When I try to upgrade to Fedora Core 15, I get a dialog that tells me I have "Dirty file systems", and lists my Linux installation's root filesystem (i.e. /dev/sdb3) as dirty. It's not dirty. It's fine. I can boot it and all is well. This bug has existed since at least FC 10. See Bug 557989 for that story. Comment 14 of Bug 557989 contains a method for working around it, involving a rebuild of install.img . I can't use that method now, since install.img is not in /boot/upgrade, and I have no idea where it is now. I'm more than happy to provide additional information, or run test scripts or whatever, to identify the problem. I've attached the logs that were in /tmp during installation. Here's my filesystem layout (from "df"): Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb3 182821076 48591728 124788440 29% / tmpfs 512996 112 512884 1% /dev/shm /dev/sdb1 1050640 119586 875718 13% /boot /dev/sdb5 58813116 4663808 51112188 9% /home /dev/sdb6 49688052 53276 47070004 1% /tmp /dev/sda1 256991696 234778100 22213596 92% /data
Ah, I see. Have you ever re-installed from scratch or has this fs been carried forward by upgrades?
Also, please attach logfiles as individual plain/text files to make it easier for us to examine them.
Created attachment 527346 [details] anaconda.log (one of the logs I found in /tmp during installation)
Created attachment 527347 [details] program.log (one of the logs I found in /tmp during installation)
Created attachment 527348 [details] storage.log (one of the logs I found in /tmp during installation)
Created attachment 527349 [details] syslog (one of the logs I found in /tmp during installation)
Created attachment 527350 [details] X.log (one of the logs I found in /tmp during installation)
Back in Bug 557989, I botched an FC 13 upgrade and had to install FC12 from scratch. The same bug happened when I tried to upgrade from FC12 to FC13. So it'll happen when trying to upgrade a system that was previously a clean reinstallation. I vastly prefer to upgrade over reinstalling. Restoring all of my previous settings, non-core packages, custom-built packages, etc. takes forever. Also, preupgrade generates about half the network traffic of downloading a new ISO. I've also attached the logfiles individually.
*** Bug 744955 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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
Still happens when upgrading from FC16 to FC17. Until such time as this bug actually gets fixed, here's the latest workaround instructions: Run preupgrade as usual unsquashfs /boot/upgrade/squashfs.img mkdir rootfs mount -o loop squashfs-root/LiveOS/rootfs.img rootfs vi rootfs/usr/lib/python2.7/site-packages/pyanaconda/upgrade.py (change "allowDirty = 0" to "allowDirty = 1") umount rootfs rmdir rootfs rm -f /boot/upgrade/squashfs.img mksquashfs squashfs-root /boot/upgrade/squashfs.img rm -rf squashfs-root However, I also recently upgraded a machine from FC14 to FC16, where there appears to be no such workaround. On a hunch, I diked out the mount of my /tmp partition in /etc/fstab before rebooting into preupgrade...and it worked! So there seems to be some issue with the installer not understanding that there's a separate /tmp partition. Maybe this will help you track down the problem? This has been going on since Fedora Core 10...I'd really like to see this fixed.
anaconda is now completely out of the upgrade game, being replaced by fedup. If you continue to see this problem with upgrading to F18 or F19, please feel free to file a new bug against the new component. Thanks.