Bug 57166 - Report dirty drives in dialog when doing upgrade
Summary: Report dirty drives in dialog when doing upgrade
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-06 09:45 UTC by Dimitri Papadopoulos
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-05-25 14:51:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/etc/fstab after Red Hat 7.2 installation (930 bytes, text/plain)
2002-01-16 19:07 UTC, Dimitri Papadopoulos
no flags Details
fsset.py with debugging info about dirty filesystems (51.86 KB, text/plain)
2002-01-16 19:40 UTC, Michael Fulbright
no flags Details

Description Dimitri Papadopoulos 2001-12-06 09:45:21 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; SunOS 5.8 sun4u)

Description of problem:
I am trying to upgrade from Red Hat 7.1 to Red Hat 7.2. The upgrade fails
consistently. A dialog pops up and displays this message:
"One or more of the filesystems for your Linux sytsem was not unmounted
cleanly. Please boot your Linux installation, let the filesystems be
checked, and shut down cleanly to upgrade."
All filesystmes were unmounted cleanly, I checked that multiple times.
Note that my PC has a Jaz disk drive. It could be related.

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

How reproducible:

Steps to Reproduce:
1. Take a PC (probably one with a Jaz drive).
2. Install Red Hat 7.1
3. Upgrade to Red Hat 7.2


Additional info:

This is what appears on the 4th console (Ctrl+Alt+F4) when the upgrade
process fails:
<6>Device not ready. Make sure there is a disk in the drive.
<4>sdb : READ CAPACITY failed.
<4>sdb : status = 1, mesage = 00, host = 0, driver = 28
<4>Current sd00:00: sns = 70 2
<4>ASC=3a ASCQ= 0
<4>Raw sense data: 0x70 0x02 [...]
<4>sdb : block size assumed to be 512 bytes, disk size 1GB.
<6> sdb: I/O error: dev 08:10, sector 0
<4> unable to read partition table
<4>EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended

Comment 1 Jeremy Katz 2001-12-12 20:22:21 UTC
If you don't have a disk in the Jaz drive does it succeed?

Comment 2 Dimitri Papadopoulos 2001-12-19 22:19:53 UTC
No, it does not suceed.

I tried with and without a Jaz disk in the drive, I rebooted multiple times, ran
No result...

The error messages in 4th console are normal. They are typical of a Jaz drive
a Jaz disk inside.

Comment 3 Michael Fulbright 2002-01-15 21:36:24 UTC
Please attach your /etc/fstab file.

Comment 4 Dimitri Papadopoulos 2002-01-16 19:05:32 UTC
This seems to be fixed in Red Hat 7.2.

Anyway, here is the /etc/fstab, it shouldn't have changed
since I was using Red Hat 7.1, although of course I can't
tell for sure.

Comment 5 Dimitri Papadopoulos 2002-01-16 19:07:09 UTC
Created attachment 42616 [details]
/etc/fstab after Red Hat 7.2 installation

Comment 6 Dimitri Papadopoulos 2002-01-16 19:11:26 UTC
Do not take the sentence "This seems to be fixed in Red Hat 7.2"
into account, sorry. I thought this was a report about another bug.

Again /etc/fstab should not have changed since Red Hat 7.1. I had
saved my disk before upgrading to Red Hat 7.2 and copied/pasted
the saved 7.1 system files to modify my 7.2 system files.

Comment 7 Michael Fulbright 2002-01-16 19:39:47 UTC
Would you please put the 'fsset.py' attached file on a ext2 floppy and boot the
installers with 'updates' on the commandline, like 'linux updates', insert the
floppy when asked, and when you get the message about dirty filesystems please
hit CNTL-ALT-F3 and look for a message like:

FS on <devicename> is dirty - cannot continue

and tell me what that message contains for <devicename>?

Comment 8 Michael Fulbright 2002-01-16 19:40:27 UTC
Created attachment 42617 [details]
fsset.py with debugging info about dirty filesystems

Comment 9 Dimitri Papadopoulos 2002-01-16 21:52:53 UTC
My error... sorry for the noise.

The message from fsset.py is:
	FS on hda3 is dirty - cannot continue
So one file system was corrupted after all:
	# fsck /dev/hda3
	Parallelizing fsck version 1.23 (15-Aug-2001)
	e2fsck 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09
	/dev/hda3 was not cleanly unmounted, check forced.

Note however that /dev/hda3 is an old disk I don't use anymore now
that I have SCSI disks. I had Red Hat 6.2 installed on it years ago
and I hadn't actually mounted it for months. It's not even in
In short I wasn't even aware it still exists... 

Sorry again. Nevertheless the error message could be made more explicit
by specifying the disk that has a problem. If not in the popup dialog,
at least output a message in the 3rd console so that one knows which
file system has the problem with Ctrl+Alt+F3. The new fsset.py file
is actually perfect.

Thank you for your time.

Best Regards,

Comment 10 Brent Fox 2002-01-17 15:49:46 UTC
msf, you can close this one if it's fixed.  Do you want to change the error

Comment 11 Jeremy Katz 2002-03-14 21:48:22 UTC
The device which is dirty is getting logged to tty3 now, which is somewhat better

Comment 12 Michael Fulbright 2002-04-10 21:56:20 UTC
A complete fix will be done in a future release.

Comment 13 Jeremy Katz 2002-05-07 00:35:50 UTC
Added new wording to dialog in CVS so that you get

"The following devices were not cleanly unmounted.


Comment 14 Michael Fulbright 2002-12-20 17:38:25 UTC
Time tracking values updated

Comment 15 Brent Fox 2003-05-25 14:51:41 UTC
I'm going through Bugzilla closing some bugs that have been marked as Modified
for some period of time.  I believe that most of these issues have been fixed,
so I'm resolving these bugs as Rawhide.  If the bug you are seeing still exists,
please reopen this report and mark it as Reopened.

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