Dear Maintainer,

Fortunately, this bug happened on a virtual machine,
so I can repeat the experiment if needed.

I have a virtual machine with a 1GB hdd and jessie installed on it.
The hdd has only one partition which is /dev/sda1, and formatted as ext2.

At first, I enlarge (via virtualbox "vboxmanage" command) the hdd size to 2GB.
Then boot the virtual machine.
Then enlarge the root partition to 2GB with cfdisk.
Then reboot. Everything is fine.
Then do

# resize2fs /dev/sda1

It says something like "/dev/sda1 is now 2000061 (1k) blocks long".
Then reboot. Grub says "error: unknown filesystem" and drops to rescue prompt.
(It might be bug in grub, not e2fsprogs - I'm not sure. Grub version is 2.00-22)

Can you check and see if this is completely repeatable?  And can you
do the following?

1)  Send me exactly what resize2fs reported.
2)  Send me the output of dumpe2fs /dev/sda1 before and after the resize2fs.
3)  Also please confirm that you ran resize2fs /dev/sda1 while in the
    guest partition, while the root file system was mounted on /dev/sda1.
4)  Please also send me the counts of /proc/mounts, /etc/mtab, and /etc/fstab.

Thanks,

					- Ted

Yes, it is perfectly repeatable.

resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/sda1 is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 8
The filesystem on /dev/sda1 is now 2000060 (1k) blocks long.

Attached.

Sorry, I don't understand the question well, but of course,
all operations were done in the guest, /dev/sda1 of guest was mounted as /.
Actually, there were no other partitions.

BTW, I ran e2fsck -n -f /dev/sda1 after resize and it give a lot of errors.
I may send its output too, if needed.

OK, I see what's going on.  How are you creating the root file system,
originally?  It's getting created without the resize inode being
initialized:

Filesystem features:      filetype sparse_super

With the default /etc/mke2fs.conf, the command:

mke2fs -t ext2 /tmp/foo.img 32M

creates a file system with the following filesystem features (as
displayed by dumpe2fs):

Filesystem features:      ext_attr resize_inode dir_index filetype sparse_super

So you must be doing something non-standard when you create the file
system.

Without the resize_inode, when doing an online resize, resize2fs, ends
up falling back to using the meta_bg format, resulting in the
following filesystem features:

Filesystem features:      filetype meta_bg sparse_super

Apparently graub doesn't know how to deal with meta_bg, so it calls
the file system an invalid format.

Anyway, it's partially a grub shortcoming, and partially caused by the
fact that you created the ext2 file system without the resize inode.

     	      	      	       	    	   - Ted

It didn't break the file system; it's a perfectly valid file system to
ext4 and e2fsprogs.

The fact that grub doesn't support file systems with the meta_bg
feature enabled is unfortunate, but that's a grub bug.  It wouldn't be
that hard to support meta_bg, actually; it's a relatively minor change
to the file system format, but grub is GPLv3, and e2fsprogs (because
it has kernel code it in it) is GPL-v2 only, and so grub couldn't just
use libext2fs from e2fsprogs directly.  If they did, then aside from
needing to link against a newer version of libext2fs, it would have
Just Worked.

So you can blame the FSF and GPLv3 for this bug, as well.  :-)

						- Ted

I dare reopen this, since the bug actually exists.
Lowering severity, because this only occurs for a special cases.

In summary, if the root filesystem was created with no resize inode,
and is then resized, resize2fs adds meta_bg feature to it
(the same can happen in some other cases, see ext4(5) manpage).
After that, grub cannot recognize the filesystem, and thus cannot boot.