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 1616389 - fsck.gfs2 should honour the filesystem format
Summary: fsck.gfs2 should honour the filesystem format
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gfs2-utils
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Andrew Price
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1622050
TreeView+ depends on / blocked
 
Reported: 2018-08-15 18:57 UTC by Andreas Gruenbacher
Modified: 2018-10-30 11:37 UTC (History)
4 users (show)

Fixed In Version: gfs2-utils-3.1.10-9.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1622050 (view as bug list)
Environment:
Last Closed: 2018-10-30 11:37:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Proposed patch (RHEL7 version) (3.92 KB, patch)
2018-08-17 12:18 UTC, Andrew Price 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3272 0 None None None 2018-10-30 11:37:42 UTC

Description Andreas Gruenbacher 2018-08-15 18:57:00 UTC 
The format of a gfs2 filesystem (sb_fs_format) is defined as GFS2_FORMAT_FS, value 1801.  We are planning to introduce a new filesystem format in RHEL8 for introducing features which are not backwards compatible.

Right now, the kernel will refuse to mount filesystems with a sb_fs_format other than 1801.  However, fsck.gfs2 ignores sb_fs_format, and will happily "repair" filesystems that have a different format.  (It won't reset sb_fs_format to 1801, either.)

So once as we introduce a new format, current versions of fsck.gfs2 will destroy such filesystems.  To prevent that to some degree, we should fix fsck.gfs2 in RHEL7: that way, at least updating from an up-to-date version of RHEL7 to RHEL8 will be safe.

Steps to Reproduce:
1. mkfs.gfs2 -O -p lock_nolock /dev/scratch
2. gfs2_edit -p sb field sb_fs_format 1802 /dev/scratch
3. mount /dev/scratch /mnt/scratch  # this will fail
4. fsck.gfs2 /dev/scratch  # this will succeed, but it should fail
Comment 1 Andrew Price 2018-08-16 11:10:20 UTC 
What behaviour do we want when fsck.gfs2 encounters sb_fs_format == 1802? Options:

- Report that the fs format is unsupported and exit non-zero
- Reset the field to 1801, continue checking
- Assume the superblock is corrupted as it's an unknown format, repair
Comment 2 Andreas Gruenbacher 2018-08-16 13:48:40 UTC 
Report that the fs format is unsupported and exit non-zero.  We really want to avoid destroying the new format.

Perhaps we want to mention that the fs format can be forced back to 1801 with:
  gfs2_edit -p sb field sb_fs_format 1801 /dev/scratch
Comment 3 Andrew Price 2018-08-17 12:18:59 UTC 
Created attachment 1476607 [details]
Proposed patch (RHEL7 version)

commit f91cd7bfb37c6e2dbe120b131f1292746cd94cba
Author: Andrew Price <anprice>
Date:   Fri Aug 17 12:49:24 2018 +0100

    fsck.gfs2: Don't check fs formats we don't recognise
    
    Currently fsck.gfs2 will ignore sb_fs_format but in order to support
    future formats we need to make sure it doesn't try to check filesystems
    with formats we don't recognise yet.
    
    Tests included.
Comment 6 Justin Payne 2018-09-14 15:48:30 UTC 
[root@host-135 ~]# rpm -q gfs2-utils
gfs2-utils-3.1.10-9.el7.x86_64
[root@host-135 ~]# mkfs.gfs2 -O -p lock_nolock /dev/sda1
This will destroy any data on /dev/sda1
Discarding device contents (may take a while on large devices): Done
Adding journals: Done 
Building resource groups: Done     
Creating quota file: Done
Writing superblock and syncing: Done
Device:                    /dev/sda1
Block size:                4096
Device size:               200.00 GB (52428790 blocks)
Filesystem size:           200.00 GB (52428788 blocks)
Journals:                  1
Journal size:              128MB
Resource groups:           801
Locking protocol:          "lock_nolock"
Lock table:                ""
UUID:                      9888eefb-db41-411a-ad88-44e730e83aeb
[root@host-135 ~]# gfs2_edit -p sb field sb_fs_format 1802 /dev/sda1
1802
[root@host-135 ~]# mount /dev/sda1 /mnt/test
mount: /dev/sda1 is write-protected, mounting read-only
[346163.785382] GFS2: fsid=: Unknown on-disk format, unable to mount
[346163.786958] GFS2: gfs2 mount does not exist
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
[root@host-135 ~]# fsck.gfs2 /dev/sda1
Initializing fsck
Unsupported gfs2 format found: 1802
A newer fsck.gfs2 is required to check this file system.
Comment 8 errata-xmlrpc 2018-10-30 11:37:31 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3272
Note You need to log in before you can comment on or make changes to this bug.