I’m in a situation where I want to enlarge the default size of an ext4 filesystem used by the firmware.

The problem is resize2fs is doing extra things like clearing some filesystems features and relocating the journal to the beginning of the device’s partition (as a result my device keep crashing before mounting anything and as I don’t know how to access the kernel console before adb can be launched, I‘ve no ideas how to access it or tune the console= kernel parameter for having the console printed on the device’s display).

As this is for enlarging, normally no relocation is needed. So how to use debugfs to change the size along with (maybe if needed) the number of free inodes? I mean which field of set_super_value I should set and which numbers to pick?

More importantly, how do I set the group descriptor checksums?

  • What about... removing the journal, resizing the filesystem, adding the journal back in again?
    – roaima
    Apr 1, 2020 at 17:20
  • what filesystem features does it clear?
    – ilkkachu
    Apr 1, 2020 at 19:25
  • 1
    @roaima same problem as using resize2fs directly. The device is mountable under standard Linux but the ᴏᴇᴍ’s Linux kernel (or something else in the userland) doesn’t like it. It might as well be something like a magic value looked up at boot time making userspace refusing to mount the partition. Since this for enlarging why not just modify the integer containing the size directly through debugfs ? Apr 1, 2020 at 22:07
  • @likkachu some features about journaling, but I don’t know the full extents. In order to know more, I would need to find a way to at least put the console on the display instead of the vendor’s logo (since it doesn’t reach the point where it starts writing the kernel’s log to the device). Apr 1, 2020 at 22:08
  • I don't know the innards, so it was only a suggestion
    – roaima
    Apr 1, 2020 at 22:09

1 Answer 1


Unless your filesystem is very small (< 128MB) then you can't just change an integer in the superblock to resize the filesystem. There are other metadata structures that need to be updated for the filesystem to be useful. That said, you might be able to update the s_blocks_count field in the superblock with the debugfs "set_super_value" (ssv) command and then run e2fsck to have it try and rebuild the missing metadata itself.

The ability to do this depends heavily on how much you are resizing the filesystem, and whether the "resize_inode" feature was enabled at the time the filesystem was formatted. Otherwise, the missing metadata that e2fsck rebuilds may be overlapping with other important filesystem contents and may cause some other problems.

The best way to verify if this works is to make an image of the whole filesystem and test on that.

  • Correct. how do I set other values in structures? Both e2fsck and resize2fs being part of e2fsprogs, I doubt it would work. Yes, the resize_inode feature is enabled. Apr 2, 2020 at 17:00
  • Did you actually test my suggestion? I tested it with "debugfs -w -R 'ssv blocks_count <new_count>' <device>" and then ran "e2fsck -fy -b0 <device>" and despite some expected errors (superblock corrupt, group descriptors corrupt, inode count bad), by e2fsck it appears to work. This was a test filesystem resizing from 1GB to 2GB, so YMMV. I would suggest doing this on a filesystem image to verify that it is working properly, and so that you don't lose your data.
    – LustreOne
    Apr 3, 2020 at 20:56
  • Yes, but looks like it changes things too much for my device (loop reboot even after restoring the original size that same way). Apr 4, 2020 at 0:03

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.