Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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

Summary: fsck.gfs2 should honour the filesystem format
Product: Red Hat Enterprise Linux 7 Reporter: Andreas Gruenbacher <agruenba>
Component: gfs2-utilsAssignee: Andrew Price <anprice>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.6CC: cluster-maint, gfs2-maint, jpayne, rhandlin
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gfs2-utils-3.1.10-9.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1622050 (view as bug list) Environment:
Last Closed: 2018-10-30 11:37:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1622050    
Attachments:
Description Flags
Proposed patch (RHEL7 version) none

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