601862 – ext2 filesystems are always dirty in rescue environment

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 601862 - ext2 filesystems are always dirty in rescue environment

Summary: ext2 filesystems are always dirty in rescue environment

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	anaconda
Sub Component:
Version:	6.0
Hardware:	All
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Martin Sivák
QA Contact:	Release Test Team
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	647893
TreeView+	depends on / blocked

Reported:	2010-06-08 19:03 UTC by Jeff Bastian
Modified:	2018-11-14 19:07 UTC (History)
CC List:	3 users (show)
Fixed In Version:	anaconda-13.21.88-1
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2011-05-19 12:29:49 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
anaconda logs from rescue environment (25.90 KB, application/x-gzip) 2010-06-08 19:34 UTC, Jeff Bastian	no flags	Details
View All

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2011:0530	0	normal	SHIPPED_LIVE	anaconda bug fix and enhancement update	2011-05-18 17:44:52 UTC

Description Jeff Bastian 2010-06-08 19:03:12 UTC

Description of problem:
If you install RHEL 6.0 onto a ext2 root filesystem and then try a rescue boot, anaconda complains that the root filesystem is dirty:
--------------------------------------------------------------
                     Dirty File Systems

   The following file systems for your Linux system were not
   unmounted cleanly. Would you like to mount them anyway?
   /dev/mapper/vg_vm23-lv_root

                     [ Yes ] [ No ]
---------------------------------------------------------------

dumpe2fs verifies that it's dirty:
   bash-4.1# dumpe2fs /dev/mapper/vg_vm23-lv_root | grep state
   dumpe2fs 1.41.12 (17-May-2010)
   Filesystem state:         not clean

fsck fixes it up:
   bash-4.1# fsck -y /dev/mapper/vg_vm23-lv_root
   bash-4.1# dumpe2fs /dev/mapper/vg_vm23-lv_root | grep state
   dumpe2fs 1.41.12 (17-May-2010)
   Filesystem state:         clean

But if you reboot and try to rescue again, it's suddenly dirty again.

Rescue works fine with ext3 and ext4.


Version-Release number of selected component (if applicable):
RHEL 6.0 snapshot 6

How reproducible:
every time

Steps to Reproduce:
1. install onto ext2 / (root) filesystem
2. reboot into rescue environment
  
Actual results:
anaconda complains that root filesystem is dirty

Expected results:
root filesystem should be clean

Additional info:

Comment 1 Jeff Bastian 2010-06-08 19:31:26 UTC

Also, if you choose No at the above prompt (to not mount the dirty filesystem), it mounts it anyway.  That is, when I finally get to the shell, the root filesystem is mounted at /mnt/sysimage.


If on the previous screen I choose Skip:
--------------------------------------------------------------
                            Rescue

  The rescue environment will now attempt to find your Linux
  installation and mount it under the directory /mnt/sysimage.
  You can then make any changes required to your system.  If
  you want to proceed with this step choose 'Continue'.  You
  can also choose to mount your file systems read-only instead
  of read-write by choosing 'Read-Only'.  If you need to
  activate SAN devices choose 'Advanced'.
  
  If for some reason this process fails you can choose 'Skip'
  and this step will be skipped and you will go directly to a
  command shell.

          [Continue]  [Read-Only]  [Skip]  [Advanced]
--------------------------------------------------------------

Then it will not mount the device on /mnt/sysimage.  Furthermore, it's shown as "clean" by dumpe2fs.

Thus, something in anaconda must be dirtying the device as it mounts it.

Comment 2 Jeff Bastian 2010-06-08 19:34:21 UTC

Created attachment 422326 [details]
anaconda logs from rescue environment

Attached are the anaconda logs plus dumpe2fs output from the rescue environment where I said "No" to mounting the dirty root filesystem.

Comment 3 RHEL Program Management 2010-10-29 21:32:40 UTC

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Comment 4 Martin Sivák 2010-12-07 15:55:16 UTC

Anaconda is not dirtying the filesystem. I found out that mounted ext2 filesystem always reports dirty state (which in fact is valid info).

Our check for dirtiness is done after we mount the /mnt/sysimage filesystem in rw mode, so it obviously reports dirty state. I will look into the logic more to figure out if we could improve it to work better with this ext2 behaviour.

Comment 5 Martin Sivák 2011-01-25 14:45:50 UTC

This has been in since anaconda-13.21.88-1

Comment 8 Alexander Todorov 2011-03-10 11:38:40 UTC

With anaconda-13.21.103-1.el6.x86_64 and / on ext2 when booting in rescue mode there was no warning about dirty fs and it was mounted successfully by anaconda. dumpe2fs reports filesystem not clean.

Comment 9 errata-xmlrpc 2011-05-19 12:29:49 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0530.html

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