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 1711880 - [RHEL-7.7] e2image against meta_bg enabled ext4 image creates corrupts metadata on some arches
Summary: [RHEL-7.7] e2image against meta_bg enabled ext4 image creates corrupts metada...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: e2fsprogs
Version: 7.7
Hardware: ppc64
OS: Linux
medium
medium
Target Milestone: rc
: 7.7
Assignee: Lukáš Czerner
QA Contact: Boyang Xue
URL:
Whiteboard:
: 1806783 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-20 09:55 UTC by Boyang Xue
Modified: 2020-09-29 20:34 UTC (History)
2 users (show)

Fixed In Version: e2fsprogs-1.42.9-18.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-29 20:34:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:4011 0 None None None 2020-09-29 20:34:25 UTC

Description Boyang Xue 2019-05-20 09:55:56 UTC 
Description of problem:
This was unveiled by test /kernel/filesystems/ext4/1682935-dumpe2fs-meta_bg-image.
With the latest kernel (-1048.el7) and e2fsprogs (1.42.9-15.el7), this problem can be reproduced on ppc64, and can't reproduced on x86_64 and ppc64le. I'm waiting for a working s390x box to test it on.
It's not a regression, since it's seen on RHEL-7.2 onward on ppc64, with the same error.
It can't be reproduced on RHEL-8.0.0.

Step to reproduce:
#fallocate -l 256M BZ1682935.img
#mkfs.ext4 -F -O meta_bg,^resize_inode BZ1682935.img
#dumpe2fs BZ1682935.img
...
dumpe2fs 1.42.9 (28-Dec-2013)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          47be5a36-83c8-4a31-8a02-cba8d022d900
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype meta_bg extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         unsigned_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              65536
Block count:              262144
Reserved block count:     13107
Free blocks:              245668
Free inodes:              65525
First block:              1
Block size:               1024
Fragment size:            1024
Group descriptor size:    64
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2048
Inode blocks per group:   256
Flex block group size:    16
Filesystem created:       Mon May 20 07:57:58 2019
Last mount time:          n/a
Last write time:          Mon May 20 07:57:58 2019
Mount count:              0
Maximum mount count:      -1
Last checked:             Mon May 20 07:57:58 2019
Check interval:           0 (<none>)
Lifetime writes:          8 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      fe1e9cc9-a73e-437c-86e5-d33de6969993
Journal backup:           inode blocks
Journal features:         (none)
Journal size:             8M
Journal length:           8192
Journal sequence:         0x00000001
Journal start:            0


Group 0: (Blocks 1-8192) [ITABLE_ZEROED]
  Checksum 0xa581, unused inodes 2037
  Primary superblock at 1, Group descriptor at 2
  Block bitmap at 3 (+2), Inode bitmap at 19 (+18)
  Inode table at 35-290 (+34)
  4049 free blocks, 2037 free inodes, 2 directories, 2037 unused inodes
  Free blocks: 4144-8192
  Free inodes: 12-2048
...
#e2image BZ1682935.img BZ1682935.e2img
#dumpe2fs -i BZ1682935.e2img
...
dumpe2fs 1.42.9 (28-Dec-2013)
dumpe2fs: Bad magic number in super-block while trying to open BZ1682935.e2img
Couldn't find valid filesystem superblock.
...

For reference, on x86_64 and ppc64le, it previously failed as shown below on RHEL-7.6.
...
dumpe2fs 1.42.9 (28-Dec-2013)
dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open BZ1682935.e2img
Couldn't find valid filesystem superblock.
...
Which has been fixed now by the commit:
libext2fs: fix ext2fs_open2() error for meta_bg image file

BZ1682935.e2img is attached here.
It fails to dump from the image on a x86_64 box with the same versions and configurations, as well:
...
[root@hp-dl360g9-01 ~]# dumpe2fs -i BZ1682935.e2img
dumpe2fs 1.42.9 (28-Dec-2013)
dumpe2fs: Wrong magic number for Ext2 Image Header while trying to open BZ1682935.e2img
Couldn't find valid filesystem superblock.
...

Version-Release number of selected component (if applicable):
e2fsprogs-1.42.9-15.el7
kernel-3.10.0-1048.el7

How reproducible:
Always

Actual results:Description of problem:


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

e2image creates corrupted metadata on some arches

Expected results:
e2image doesn't create corrupted metadata on all arches

Additional info:
N/A
Comment 1 Lukáš Czerner 2019-05-20 10:59:38 UTC 
Hi, thanks for the report. I have not tested this but there were sevaral fixes in this area and I think the wollowing should fix it. Will backport it for the next release.

Thanks!
-Lukas


commit 8b061a641dff1a0becf645f8e6002de79b997b95
Author: Kazuya Mio <k-mio.nec.com>
Date:   Sat Mar 17 14:56:15 2018 -0400

    libext2fs: fix ext2fs_open2() error for meta_bg image file
    
    dumpe2fs/debugfs can examine the image file by using the -i option.
    However, if meta_bg feature is enabled, dumpe2fs/debugfs cannot open
    the image file.
    
    $ dumpe2fs -i test.img
    dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open test.img
    Couldn't find valid filesystem superblock.
    
    In case of specifying an image file, the location of block group descriptors
    is the same as the case of default filesystem regardless of meta_bg feature.
    So if EXT2_FLAG_IMAGE_FILE flag is set in ext2fs_open2(),
    don't use the meta_bg handling.
    
    Signed-off-by: Kazuya Mio <k-mio.nec.com>
    Signed-off-by: Theodore Ts'o <tytso>


commit 8b061a641dff1a0becf645f8e6002de79b997b95
Author: Kazuya Mio <k-mio.nec.com>
Date:   Sat Mar 17 14:56:15 2018 -0400

    libext2fs: fix ext2fs_open2() error for meta_bg image file
    
    dumpe2fs/debugfs can examine the image file by using the -i option.
    However, if meta_bg feature is enabled, dumpe2fs/debugfs cannot open
    the image file.
    
    $ dumpe2fs -i test.img
    dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open test.img
    Couldn't find valid filesystem superblock.
    
    In case of specifying an image file, the location of block group descriptors
    is the same as the case of default filesystem regardless of meta_bg feature.
    So if EXT2_FLAG_IMAGE_FILE flag is set in ext2fs_open2(),
    don't use the meta_bg handling.
    
    Signed-off-by: Kazuya Mio <k-mio.nec.com>
    Signed-off-by: Theodore Ts'o <tytso>
Comment 3 Eric Sandeen 2019-06-24 16:42:22 UTC 
Looks like more triage & analysis is needed, moving to rhel7.8
Comment 4 Eric Sandeen 2019-12-14 05:50:12 UTC 
Fixed by:

commit bfc1856029ff6851845de27114fea899bbdbccbe
Author: Lukas Czerner <lczerner>
Date:   Mon Apr 9 11:58:15 2018 -0400

    e2image: fix metadata image handling on big endian systems
    
    Currently e2image metadata image handling and creating is completely
    broken on big endian systems. It just does not care about endianness at
    all. This was uncovered With addition of i_bitmaps test, which is the
    first test that actually tests e2image metadata image.
    
    Fix it by making sure that all on-disk metadata that we write and read
    to/from the metadata image is properly converted.
    
    Signed-off-by: Lukas Czerner <lczerner>
    Signed-off-by: Theodore Ts'o <tytso>
Comment 6 Boyang Xue 2020-03-11 02:15:21 UTC 
*** Bug 1806783 has been marked as a duplicate of this bug. ***
Comment 13 Boyang Xue 2020-06-05 03:07:50 UTC 
TEST PASS.

Reproduced with e2fsprogs-1.42.9.17.el7
'''
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   /kernel/filesystems/ext4/1682935-dumpe2fs-meta_bg-image/Test
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 05:17:01 ] :: [   PASS   ] :: Command 'mkfs.ext4 -F -O meta_bg,^resize_inode BZ1682935.img' (Expected 0, got 0)
:: [ 05:17:01 ] :: [   PASS   ] :: Command 'e2image BZ1682935.img BZ1682935.e2img' (Expected 0, got 0)
:: [ 05:17:01 ] :: [   LOG    ] :: Output of 'dumpe2fs -i BZ1682935.e2img':
:: [ 05:17:01 ] :: [   LOG    ] :: --------------- OUTPUT START ---------------
:: [ 05:17:01 ] :: [   LOG    ] :: Couldn't find valid filesystem superblock.
:: [ 05:17:01 ] :: [   LOG    ] :: dumpe2fs 1.42.9 (28-Dec-2013)
:: [ 05:17:01 ] :: [   LOG    ] :: dumpe2fs: Bad magic number in super-block while trying to open BZ1682935.e2img
:: [ 05:17:01 ] :: [   LOG    ] :: ---------------  OUTPUT END  ---------------
:: [ 05:17:01 ] :: [   FAIL   ] :: Command 'dumpe2fs -i BZ1682935.e2img' (Expected 0, got 1)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 0s
::   Assertions: 2 good, 1 bad
::   RESULT: FAIL (/kernel/filesystems/ext4/1682935-dumpe2fs-meta_bg-image/Test)
'''

Verified with e2fsprogs-1.42.9.18.el7
'''
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   /kernel/filesystems/ext4/1682935-dumpe2fs-meta_bg-image/Test
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 01:59:23 ] :: [   PASS   ] :: Command 'mkfs.ext4 -F -O meta_bg,^resize_inode BZ1682935.img' (Expected 0, got 0)
:: [ 01:59:23 ] :: [   PASS   ] :: Command 'e2image BZ1682935.img BZ1682935.e2img' (Expected 0, got 0)
:: [ 01:59:24 ] :: [   PASS   ] :: Command 'dumpe2fs -i BZ1682935.e2img' (Expected 0, got 0)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 5s
::   Assertions: 3 good, 0 bad
::   RESULT: PASS (/kernel/filesystems/ext4/1682935-dumpe2fs-meta_bg-image/Test)
'''
Comment 15 errata-xmlrpc 2020-09-29 20:34:14 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 (Moderate: e2fsprogs security and bug fix update), 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/RHSA-2020:4011
Note You need to log in before you can comment on or make changes to this bug.