1

After using e2resize and repartitioning an ext4 fs within a luks container, I'm getting some peculiar results:

# e2fsck /dev/mapper/a 
e2fsck 1.44.1 (24-Mar-2018)
The filesystem size (according to the superblock) is 356487715 blocks
The physical size of the device is 356487205 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

# fdisk -l /dev/sdc
Disk /dev/sdc: 2.7 TiB, 3000558944256 bytes, 732558336 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xe520dd91

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdc1             256 356487972 356487717  1.3T 83 Linux


Disk /dev/mapper/a: 1.3 TiB, 1460171591680 bytes, 356487205 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Resizing the filesystem again does not work either:

# e2fsck -f /dev/mapper/a 
e2fsck 1.44.1 (24-Mar-2018)
The filesystem size (according to the superblock) is 356487715 blocks
The physical size of the device is 356487205 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? no
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
/dev/mapper/a: 145786/89128960 files (4.8% non-contiguous), 354794507/356487715 blocks

# resize2fs /dev/mapper/a 
resize2fs 1.44.1 (24-Mar-2018)
Resizing the filesystem on /dev/mapper/a to 356487205 (4k) blocks.
resize2fs: Attempt to read block from filesystem resulted in short read while trying to resize /dev/mapper/a
Please run 'e2fsck -fy /dev/mapper/a' to fix the filesystem
after the aborted resize operation.

Somehow the mapped drive's sector count is now smaller than that of the fs? The difference is just short of 2MB (2MB is the size of the luks header, I believe?)

As it is now, I can't mount the fs. But if I go through with e2fsck it reports no errors.

So where is this length set. Can one change it somehow to the "correct" value?

  • Did you enlarge the filesystem or shrink it? I'd try resize2fs /dev/mapper/a without specifying the new size, to make the filesystem size match the device size. Or explicitly resize2fs /dev/mapper/a 356487205. – telcoM Apr 24 '18 at 13:45
  • Seems like you forgot to take the LUKS header/offset into account when shrinking your LUKS partition. (There may be an offset even when using external header. Check luksDump for the data offset.) Filesystems really hate that, best option may be to make the partition larger again (temporarily until the issue is sorted). – frostschutz Apr 24 '18 at 13:55
  • I shrunk it. resize2fs doesn't work. I'll update the question – lash Apr 24 '18 at 13:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.