User cancel of fsck gives: "fsck.ext4: Inode bitmap not loaded while setting block group checksum"

I talked with psusi (Phillip Susi) in #ubuntu-devel and he seemed to have some interesting ideas, unfortunately I had absolutely no idea what he was talking about (me not knowing the code, or any theory of filesystems at all), so I though I would post it here for reference by others.

Main points (edited):

Sounds like an assertion failure triggered by the sigint... search the code for that string.
Sounds like the canceling tries to do some cleanup in the SIGINT handler, and part of that cleanup is trying to write out the inode allocation bitmap, which an assertion check makes sure is actually loaded first and it isn't.
It may not be loaded either because it has not been loaded yet at the time of the SIGINT, or because that block group's inode allocation bitmap is uninitialized.

First thing I'd do is search the source code for the string "Inode bitmap not loaded while"
My guess is you will find an assert() with that string in it and that assertion is failing because of a race condition in which the inode allocation bitmap is not loaded yet, but should be eventually... and that could be a little tricky to fix.

But I have a feeling that probably it is not loaded because that block group's inode table is uninitialized in the first place.. meaning there are no inodes used in that block group so the allocation table is not actually valid and a flag says it is unused, assume it's all empty.

Fixing that should be as simple as putting in a check for the uninitialized flag in the code trying to flush the allocation bitmap and bail out of it is set.

/lastlog attached for completeness

Thanks for the very clear bug report. I wish all Ubuntu bug reports were this clear! :-)

The fix for this bug has been committed into the 'maint' branch of e2fsprogs, and is commit 2e6436d. This fix is in the (just-released) e2fsprogs 1.41.12.

And thanks for the fast solution!

I can confirm that the new version of e2fsprogs (1.41.12) solves this bug on my system.
___

As far as packaging goes, it seems that if one only applies the old ubuntu .diff.gz and build straight off, the resulting e2fsprogs will depend on the old version of e2fslibs (shlibdeps hiccups in some way? Force-installing worked just fine as far as testing goes).
Just thought I'd put that down here for reference just in case, although since it's already in Debian, if we pull from there it might be a non-issue.

Since this is a fairly common, and pretty ugly problem in lucid, I'll try getting an SRU in order.

On Wed, May 26, 2010 at 02:53:09AM -0000, arand wrote:
> Since this is a fairly common, and pretty ugly problem in lucid, I'll
> try getting an SRU in order.

Are you planning on taking all of 1.41.12, or just the relevant patch
from the e2fsprogs git tree?

      - Ted

For the released 10.04 I was planning on just grabbing the commit in question , since I'm not sure if a new version with more changes would go well with the updating policy.

For in-devel 10.10 I hope we'll simply merge with the new version from Debian (I was thinking I might try my luck at that, but I'll have to check if the maintainer proper has plans for it).

On Wed, May 26, 2010 at 02:03:55PM -0000, arand wrote:
> For the released 10.04 I was planning on just grabbing the commit in
> question , since I'm not sure if a new version with more changes would
> go well with the updating policy.

OK, great. 1.41.12 does fix a number of high priority bugs beyond the
commit which you've grabbed, but it does introduce one, which will be
fixed in 1.41.13 (to be released in a few days).

The unfixed bugs in Ubuntu's e2fsprogs are probably only going to
matter for server workloads, and that's OK, because the 2.6.32
kernel's ext4 is missing so many bug fixes it's really not going to be
ready for server-class workloads anyway. (Hint: take a look at all of
the ext4 patches which Red Hat rawhide has taken for 2.6.32.)

                                    - Ted

Hmm, it could be a good idea, however the server side of things is something I know nothing about, so I reckon it's completely someone else's decision to take whether the other bug-fixes are 10.04-updates material, or if indeed pulling the whole new version of e2fsprogs in 10.04 is the best way to go.

In the meantime, here is a debdiff for this particular issue, at least.

Hmm, there really should be a LP reference in there, new debdiff, removing the other.

As far as the Maverick version goes, Scott James Remnant indicated that the Ubuntu package is in fact kept in git and will be simply pulled from your (Ted's) tree, so it's not even going through Debian merging as I previously though (provided I've understood things correctly this time around...).

Hmm, that is quite obviously the wrong debdiff, remove and re-attach...

Okay, with the new version this change is in the e2fsprogs in Maverick.

I would argue that this is something that'd be worth an SRU, hence subscribing sponsors and sru teams.

Also fixing debdiff to use lucid-proposed instead.

uploaded to lucid-proposed

waiting for ubuntu-sru approval

ACK from SRU team.

Accepted e2fsprogs into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

SRU verification for Lucid:
I have reproduced the problem with e2fsprogs 1.41.11-1ubuntu2 in lucid and have verified that the version of e2fsprogs 1.41.11-1ubuntu2.1 in -proposed fixes the issue.

Marking as verification-done

Copied to lucid-updates. Closing manually due to typo in the changelog.