Red Hat Bugzilla – Bug 54934
Installer claims filesystems not unmounted cleanly
Last modified: 2007-04-18 12:37:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
Description of problem:
Once I click the Next button of the install screen where there is the
checkbox "Customize packages to be upgraded" (or something like that), I
get an error message window that says "One or more of the filesystems for
your Linux system was not unmounted cleanly. Please boot your Linux
installation, let the filesystems be checked, and shut down cleanly to
upgrade." Once I click Ok, the installer shuts down for reboot. I have
verified several times that there are no filesystems at that point that are
uncleanly unmounted. This happens both in normal upgrade and expert mode
Version-Release number of selected component (if applicable):
I'm upgrading a Redhat 7.1 system. Disks and filesystems are
Device Boot Start End Blocks Id System
/dev/hda1 * 1 3824 30716248+ c Win95 FAT32 (LBA)
/dev/hda2 3825 9728 47423880 f Win95 Ext'd (LBA)
/dev/hdb1 * 1 17 136521 83 Linux
/dev/hdb2 18 1770 14080972+ 83 Linux
/dev/hdb3 1771 1821 409657+ 82 Linux swap
/dev/hdb4 1822 1869 385560 83 Linux
/dev/hdd1 1 1232 9896008+ 83 Linux
All linux partitions have ext2 filesystem. hda1 has FAT. Maybe the fact
hda2 is an extended partition but there are no logical partitions inside it
confuses the installer?
I filled hda2's extended partition with a logical partition and created a FAT32
filesystem on it, but that didn't change the behaviour of the installer.
Can you attach the /etc/fstab file from your 7.1 system?
The /etc/fstab is:
LABEL=/ / ext2 defaults 1 1
LABEL=/boot /boot ext2 defaults 1 2
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
none /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
/dev/hdb3 swap swap defaults 0 0
#/dev/hdb4 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0
/mnt/loop0 iso9660 defaults,noauto 1 3
/nauris nfs defaults,soft,rsize=8192,wsize=8192 0 0
/dev/fd0 /mnt/dos/a msdos owner,defaults,noauto 0 0
/data ext2 defaults,user 0 0
/mnt/dos/f vfat defaults,user,uid=500,umask=0002,utf8 0 0
/mnt/dos/g vfat defaults,user,uid=500,umask=0002,utf8 0 0
Created attachment 34721 [details]
file /etc/fstab from the RH 7.1 system being upgraded
Bugzilla wrapped the lines of my previous comment, so I also created an
attachment containing the same data.
Created attachment 34765 [details]
Hmmm...I'm thinking that the installer is getting confused by your /etc/fstab
file for some reason. Try this: back up your existing fstab file and then try
the one I just attached instead. I just commented out some partitions that you
won't need during the upgrade process. You can restore the original after the
install. Does this help?
Yes, that fixed it. I narrowed it down to
/data ext2 defaults,user 0 0
Commenting out that line from the original fstab makes installation proceed past
the point it stops at otherwise.
Very odd. Are you sure that partition was not unmounted cleanly? I can think
of no other reason for the installer to fail on it...
At least the Redhat 7.1 system never complained about that filesystem.
However when I did e2fsck in the shell console of Redhat 7.2 installation,
e2fsck said that the filesystem is not unmounted cleanly, and started checking
it. After that, the problem went away, and Redhat 7.2 installer no longer
considers the filesystem not cleanly unmounted, even in subsequent installs.
So from Anaconda's point of view, there apparently was no bug in Anaconda. It
would seem to me, instead, that RH71 and RH72 ext2 code has a different idea of
when a filesystem is clean. Or maybe RH71 did consider the filesystem unclean
but never told about it.
Well, the partitioning and disk detection code did change between 7.1 and 7.2.
We switched from libfdisk to GNU/parted, so that may account for the difference
in behavior, although that seems unlikely. Anyway, I'm going to close this
report now since things seem to be working now. Thanks for your report.