Your message dated Mon, 2 Dec 2013 00:36:01 -0500 with message-id <[email protected]> and subject line Re: Fwd: Bug#731072: linux-image-3.11-2-amd64: Mounting of small ext2 file systems fails on 3.11 has caused the Debian Bug report #731072, regarding linux-image-3.11-2-amd64: Mounting of small ext2 file systems fails on 3.11 to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 731072: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731072 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: src:linux Version: 3.11.8-1 Severity: normal Dear Maintainer, due to the changed kernel configuration to disable the ext2 module and to enable CONFIG_EXT4_USE_FOR_EXT23=y the support for small ext2 file systems has been (accidently?) removed. Small file systems here are file systems with less than 1024 blocks, i.e. less than 1 to 4 MeBi depending on the block size. The change has been introduced between 3.10 and 3.11 in Debian. When trying to mount such a file system, the following error is printed: > mount: wrong fs type, bad option, bad superblock on /dev/loop0, > missing codepage or helper program, or other error > In some cases useful info is found in syslog - try > dmesg | tail or so The syslog contains the following line > EXT4-fs (loop0): bad geometry: block count 1440 exceeds size of device (1048 > blocks) This information is not helpful. While the loss of support for small file systems is unfortunate, I think the lack of information here is unacceptable. Such small file systems are still being used, e.g. on removable media or in the embedded world, thus the bug's severity can be critical for some users. I do not exactly know what the best fix of this bug is (and thus where to assign this bug), but some solutions are: - Revert the kernel configuration to support the ext2 module again - Print a warning during kernel upgrade - Print a precise error when mounting fails - Support such small file systems with the ext4-for-ext2 config For everyone else who is hit by this problem: As a workaround, an old Debian kernel (3.10 or older) or a self-compiled kernel with separate ext2 support can be used to recover the data on such file systems. > mkfs.ext4 -b 1024 DEVICE can be used to create an ext4 file system with a minimum size of 1 MeBi as an alternative. Cheers Patrick
--- End Message ---
--- Begin Message --->due to the changed kernel configuration to disable the ext2 module and >to enable >CONFIG_EXT4_USE_FOR_EXT23=y >the support for small ext2 file systems has been (accidently?) removed. >Small file systems here are file systems with less than 1024 blocks, >i.e. less than 1 to 4 MeBi depending on the block size. The change has >been introduced between 3.10 and 3.11 in Debian. It works just fine for me: <tytso.root@lambda> {/home/tytso}, level 2 501# mke2fs -t ext2 -Fq /tmp/foo.img <tytso.root@lambda> {/home/tytso}, level 2 502# mount -t ext4 -o loop /tmp/foo.img /mnt <tytso.root@lambda> {/home/tytso}, level 2 503# df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0 93 14 72 17% /mnt <tytso.root@lambda> {/home/tytso}, level 2 504# uname -a Linux lambda 3.12.0-00038-g576a451 #60 SMP Tue Nov 12 00:20:14 EST 2013 x86_64 GNU/Linux >The syslog contains the following line >> EXT4-fs (loop0): bad geometry: block count 1440 exceeds size of device (1048 >> blocks) > >This information is not helpful. While the loss of support for small file >systems is unfortunate, I think the lack of information here is unacceptable. What this means is that the file system claims to contain 1440 blocks, but loopback device thinks that it is only 1048 blocks. This is probably because the underlying file which you are mounting via the loopback device has a length which is only 1048 times the block size. (Probably 1k, so run ls -l you'll probably see that the file's i_size about 1073152 bytes.) The reason why ext4 has this safety check is because if you mounted the file system using the ext2 file system, and then tried to write to it, and the ext2 file system attempted to allocate and then write to block number 1049, it would get a block device error from the loopback device layer, and this could potentially result in data loss. Even if you decide to keep using the 3.10 kernel, and continuing using the ext2 file system (which is certainly your perogative), I'd suggest running the following command to avoid the possibility o data loss: fallocate -l $(expr 1440 \* 1024) /tmp/foo.img (where you should replace 1024 with the blocksize if it is not 1024 bytes, and you should replace /tmp/foo.img with the name of the underlying file.) This command will also solve the problem which you are seeing with Debian's 3.11 kernel. BTW, in the future, it might be useful to try a few more experiments before jumping to a conclusion, which in this case, was hopelessly wrong. Fortunately you gave enough information that it was possible to diagnose what was really going on (for which I thank you; what's most frustrating is when users jump to unnwarranted conclusions, and then don't give the data which they gathered which led them to make the jump to their proposed diagnosis.) Best regards, - Ted P.S. I will probably make a change in future kernels so that if that file system is being mounted read-only, instead of failing the mount we will print a warning message to the console. I will also try to make the message a bit clearer. If you had set up the loop device using losetup, and then run e2fsck, you would have gotten the following message which would have probably be clearer (although its proposed diagnosis isn't quite right, since the most common cause is someone who repartitions the disk without first shrinking the file system): The file system size (according to the superblock) is 1440 blocks The physical size of the device is 1048 blocks. Either the superblock or the partition table is likely to be corrupt! Abort? The reason why e2fsck then asks if you want to abort is the same reason why ext4 doesn't want to let the mount proceed --- if you continue, you are likely to do damage to the file system as well as your data. E2fsck's message is way too verbose for the kernel console log, but we can try to do something which is a bit more explanatory than "bad geometry".
--- End Message ---
