Bug 54934 - Installer claims filesystems not unmounted cleanly
Summary: Installer claims filesystems not unmounted cleanly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-10-23 12:34 UTC by Samuli Kärkkäinen
Modified: 2007-04-18 16:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-10-24 08:17:23 UTC
Embargoed:


Attachments (Terms of Use)
file /etc/fstab from the RH 7.1 system being upgraded (1.13 KB, text/plain)
2001-10-23 13:13 UTC, Samuli Kärkkäinen
no flags Details
/etc/fstab file (1.14 KB, text/plain)
2001-10-23 17:53 UTC, Brent Fox
no flags Details

Description Samuli Kärkkäinen 2001-10-23 12:34:03 UTC
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
upgrade.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Additional info:

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?

Comment 1 Samuli Kärkkäinen 2001-10-23 12:53:05 UTC
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.


Comment 2 Brent Fox 2001-10-23 13:01:50 UTC
Can you attach the /etc/fstab file from your 7.1 system?

Comment 3 Samuli Kärkkäinen 2001-10-23 13:10:54 UTC
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
/dev/loop0
	/mnt/loop0		iso9660	defaults,noauto	1 3
#nauris:/
	/nauris			nfs	defaults,soft,rsize=8192,wsize=8192	0 0
//localhost/homes
/home/skarkkai/nauris
smb
sockopt=TCP_NODELAY,sockopt=IPTOS_LOWDELAY,SO_SNDBUF=262144,SO_RCVBUF=262144,user,username=skarkkai,password=xxxxxxxx,port=13139
0 0
/dev/fd0                /mnt/dos/a		msdos   owner,defaults,noauto 0 0
/dev/hdd1
	/data			ext2	defaults,user 0 0
/dev/hda1
	/mnt/dos/f		vfat	defaults,user,uid=500,umask=0002,utf8 0 0
#/dev/hda2
	/mnt/dos/g		vfat	defaults,user,uid=500,umask=0002,utf8 0 0



Comment 4 Samuli Kärkkäinen 2001-10-23 13:13:13 UTC
Created attachment 34721 [details]
file /etc/fstab from the RH 7.1 system being upgraded

Comment 5 Samuli Kärkkäinen 2001-10-23 13:15:15 UTC
Bugzilla wrapped the lines of my previous comment, so I also created an
attachment containing the same data.


Comment 6 Brent Fox 2001-10-23 17:53:45 UTC
Created attachment 34765 [details]
/etc/fstab file

Comment 7 Brent Fox 2001-10-23 18:07:04 UTC
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?

Comment 8 Samuli Kärkkäinen 2001-10-23 21:03:24 UTC
Yes, that fixed it. I narrowed it down to

/dev/hdd1
	/data			ext2	defaults,user 0 0

Commenting out that line from the original fstab makes installation proceed past
the point it stops at otherwise.


Comment 9 Brent Fox 2001-10-23 21:08:03 UTC
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...

Comment 10 Samuli Kärkkäinen 2001-10-24 08:17:18 UTC
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.

Comment 11 Brent Fox 2001-10-24 13:35:33 UTC
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.


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