linux-ext4 - [Bug 200371] Unable to Mount… EXT4: First Meta block group too large

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 29 Jun 2018 23:20:17 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 200371] Unable to Mount… EXT4: First Meta block group too large

https://bugzilla.kernel.org/show_bug.cgi?id=200371

Theodore Tso (tytso@....edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |tytso@....edu
         Resolution|---                         |PATCH_ALREADY_AVAILABLE

--- Comment #1 from Theodore Tso (tytso@....edu) ---
So I'm really interested in how the file system got to that state.  If you have
the history of how the file system was resized up until now, that would be
really useful.

In any case, the file system really is corrupted, although the good news is
that should be a relatively simple thing to fix; you just need to upgrade to a
non-prehistoric version of e2fsprogs.

It looks like you are using RHEL 7 kernel and e2fsprogs.  As such, you should
really be getting support from Red Hat --- and they may very well tell you that
using a file system this big isn't something Red Hat doesn't support.  Given
that they are using super-ancient versions of the kernel and e2fsprogs
(possibly with some bug fixes and features backported), that might be quite
fair.  But because they do backport code, it's really not something that
upstream developers can really support.  This is why Red Hat customers pay the
Big Buckets to Red Hat.  :-)

In any case, e2fsck from e2fsprogs 1.44.2 should be able to repair it.  Using
it may void your Red Hat support contract, though --- in which case the right
answer is to file a bug with Red Hat and ask them to fix it.

# (MKE2FS_FIRST_META_BG=1152 mke2fs -t ext4 -O meta_bg,^resize_inode -b 4k
/tmp/foo.img 2297954304)
mke2fs 1.44.2 (14-May-2018)
Creating regular file /tmp/foo.img
Creating filesystem with 2297954304 4k blocks and 287244288 inodes
Filesystem UUID: 02abae05-96a0-4cbe-85fe-3c2d0c97cf4e
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000, 214990848, 512000000, 550731776, 644972544, 1934917632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done       

# mount /tmp/foo.img /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop1, missing
codepage or helper program, or other error.

# dmesg | tail -2
[110950.298537] EXT4-fs (loop1): mounted filesystem with ordered data mode.
Opts: (null)
[111476.144952] EXT4-fs (loop1): first meta block group too large: 1152 (group
descriptor block count 1096)

# e2fsck -f /tmp/foo.img
e2fsck 1.44.2 (14-May-2018)
First_meta_bg is too big.  (1152, max value 1096).  Clear<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(1097--1152)
Fix<y>? yes
Free blocks count wrong for group #0 (27482, counted=27538).
Fix<y>? yes
Free blocks count wrong for group #1 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #3 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #5 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #7 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #9 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #25 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #27 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #49 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #81 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #125 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #243 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #343 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #625 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #729 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #2187 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #2401 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #3125 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #6561 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #15625 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #16807 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #19683 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong for group #59049 (31615, counted=31671).
Fix<y>? yes
Free blocks count wrong (2279572611, counted=2279573899).
Fix<y>? yes

/tmp/foo.img: ***** FILE SYSTEM WAS MODIFIED *****
/tmp/foo.img: 11/287244288 files (0.0% non-contiguous), 18380405/2297954304
blocks

# mount /tmp/foo.img /mnt

# df /mnt
Filesystem      1K-blocks  Used  Available Use% Mounted on
/dev/loop1     9118295620    24 8658688352   1% /mnt

-- 
You are receiving this mail because:
You are watching the assignee of the bug.