On Tue, Jul 24, 2018 at 05:00:04PM +0200, Jaco Kroon wrote: > I'm busy trying to write a patch for e2fsck that would allow it to (on > top of the referenced series by Jan) enable fsck to at least clear the > filesystem from other errors where currently if I hack the inode count > to ~0U fsck, tune2fs and friends fail. Can you run dumpe2fs on the file system and make sure the last block group is not used? It probably shouldn't be in use if you just converted the file system. The simplest way to get your file system working again would be to just drop the last block group. To do that, look at the starting number of the last block group, and use debugfs set the number blocks in the superblock. So if the last block group looks like this: Group 524287: (Blocks 17179836416-17179869183) csum 0x90d9 [INODE_UNINIT] Block bitmap at 17179344911 (bg #524272 + 15), csum 0xdd9ecdea Inode bitmap at 17179344927 (bg #524272 + 31), csum 0x00000000 Inode table at 17179346848-17179346975 (bg #524272 + 1952) 32768 free blocks, 2048 free inodes, 0 directories, 2048 unused inodes Free blocks: 17179836416-17179869183 Free inodes: 1073739777-1073741824 Then you would do this: debugfs -w /tmp/exp/exp debugfs: ssv blocks_count 17179836416 You can then set the inodes_count to be (<new_blocks_count> / 32768) * <inodes_per_group> Inodes per group is reported by dumpe2fs -h. This might be simpler than trying to make e2fsprogs be able to deal with it. Cheers, - Ted
