Bug 749131 - anaconda reports unclean mount with preupgrade
Summary: anaconda reports unclean mount with preupgrade
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 16
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-26 09:49 UTC by Igor Bukanov
Modified: 2013-01-07 18:17 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-07 18:17:36 UTC
Type: ---


Attachments (Terms of Use)
progran.log (42.60 KB, text/plain)
2011-10-26 21:08 UTC, Igor Bukanov
no flags Details
anaconda.log (6.99 KB, text/plain)
2011-10-26 21:36 UTC, Igor Bukanov
no flags Details
program.log (42.60 KB, text/plain)
2011-10-26 21:37 UTC, Igor Bukanov
no flags Details
storage.log (62.41 KB, text/plain)
2011-10-26 21:38 UTC, Igor Bukanov
no flags Details
syslog (132.28 KB, text/plain)
2011-10-26 21:41 UTC, Igor Bukanov
no flags Details

Description Igor Bukanov 2011-10-26 09:49:57 UTC
Description of problem:

I tried to use preupgrade to install Fedora 16 Beta. However, when anaconda started, it refused to proceed with installation complaining that /dev/sda1 (root filesystem with ext4 on Intel SSD) was not cleanly unmounted. I tried to boot into Fedora 15 and shutdown via different ways including Gnome menu and shutdown -h now, but that has not helped.  

How reproducible:

Always.

Steps to Reproduce:
1. Install and run preupgrade on Fedora 15 to prepare for Fedora 16 Beta installation.

2. Shutdown or reboot and choose the upgrate in the grub menu.
  
Actual results:

Anaconda installer refused to run complaining about unclean mount.

Expected results:

The upgrade should run normally.

Comment 1 David Lehman 2011-10-26 16:09:48 UTC
Please collect the file /tmp/program.log from the shell on tty2 while the error message is shown on the installer's graphical screen. To get to the shell, press <ctrl>+<alt>+<f2>. From there you can use scp to transfer the file to another computer and attach it to this report. Thanks.

You also might want to try running 'e2fsck -p /dev/sda1' while you're on tty2. That should fix any problems in the filesystem, including it being marked as dirty. If that works and then the upgrade works as well you don't need to attach the program.log file here.

Comment 2 Igor Bukanov 2011-10-26 21:08:33 UTC
Created attachment 530382 [details]
progran.log

This is the requested /tmp/program.log. Running e2fsck -p /dev/sda1 does not help as it reports that the filesystem is clean.

Comment 3 David Lehman 2011-10-26 21:25:49 UTC
Can you attach the other logs, please?

 /tmp/anaconda.log
 /tmp/storage.log

If you are doing a live install:

 /var/log/messages

If not:

 /tmp/syslog


Thanks.

Comment 4 Igor Bukanov 2011-10-26 21:36:53 UTC
Created attachment 530390 [details]
anaconda.log

Comment 5 Igor Bukanov 2011-10-26 21:37:33 UTC
Created attachment 530391 [details]
program.log

Comment 6 Igor Bukanov 2011-10-26 21:38:05 UTC
Created attachment 530392 [details]
storage.log

Comment 7 Igor Bukanov 2011-10-26 21:41:38 UTC
Created attachment 530393 [details]
syslog

Comment 8 Igor Bukanov 2011-10-30 16:05:10 UTC
Apparently my /dev/sda1 has errors that are visible if I mount it with -f. I suppose anaconda discovers that. So the issue is usability one. That is, the error message should report about that and not about unclean umount.

Comment 9 Daniel Brodie 2011-11-11 08:45:47 UTC
I submitted a bug[0] that might be a duplicate, would appreciate if someone could confirm/deny.

P.S. I do not seem to have any "invisible" errors on my drive, I have mounted with -f, fsck'ed with -v, and anything else I could think of and have not encountered any errors.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=752720

Comment 10 Robert Vogelgesang 2011-11-30 01:06:29 UTC
This seems like a duplicate of the old bug #557989, at least the description matches what I remember from last year when I tried to debug #557989.

A few minutes ago I added an untested patch to bug #557989; maybe you could try this and report back if it fixes your issue.

Comment 11 Robert Vogelgesang 2011-12-09 11:04:26 UTC
I just figured I should point out here that the old bug #557989 is CLOSED WONTFIX, because it was filed against Fedora 12 which has reached EOL.  The issue was never fixed.

The patch I attached to bug #557989 was originally developed for the anaconda version of the Fedora 14 release and tested once, using a method similar to the method I described in comment 14 of bug #557989.  I have updated the patch for the current anaconda git HEAD version as of 2011-11-29.

The anaconda hacking method from bug #557989 cannot be used any longer for the installer of Fedora 16, because the stage2 installer is no longer packed in a separate image, but tacked piggyback onto the initramfs image.  I have tried, but failed so far, to find a way to separate the parts of the Fedora 16 installer initramfs image.  So, if anyone wants to use my patch, the only option seem to be to build a new installer initramfs image from scratch (which I did not try so far).

Comment 12 Chris Lumens 2013-01-07 18:17:36 UTC
For F18 we are no longer using preupgrade, which also means anaconda is no longer involved in the upgrade process at all.  Therefore, this bug report should no longer be relevant.  If you experience upgrade problems with F18, please file them either against the fedup component, or the specific package that is causing upgrade problems.  Thanks.


Note You need to log in before you can comment on or make changes to this bug.