Red Hat Bugzilla – Bug 601862
ext2 filesystems are always dirty in rescue environment
Last modified: 2011-05-19 08:29:49 EDT
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:
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.
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.
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.
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.
This has been in since anaconda-13.21.88-1
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.
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