User cancel of fsck gives: "fsck.ext4: Inode bitmap not loaded while setting block group checksum"
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
e2fsprogs |
Fix Released
|
Undecided
|
Unassigned | ||
e2fsprogs (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Lucid |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: e2fsprogs
"Parents": Bug #571707 and Bug #577331
PROBLEM
Whenever fsck is cancelled by user, this error message is given:
"fsck.ext4: Inode bitmap not loaded while setting block group checksum info"
And the exit status of fsck is 8
(This leads to plymouth/mountall reporting "Serious errors" on the filesystem in question when fsck is cancelled during boot, and acting accordingly.)
TEST CASE
1. Force a fsck at boot time
$ sudo touch /forcefsck
2. Reboot your system
3. When the 'Checking filesystem' prompt is displayed press 'C' to cancel
4. Finish the boot sequence
5. Check the content of /var/log/boot.log
VERIFICATION-DONE
The boot.log contains
-----
fsck from util-linux-ng 2.17.2
User cancelled filesystem checks
/dev/sda1: e2fsck canceled.
mountall: fsck / [235] terminated with status 32
-----
VERIFICATION-FAILED
The boot.log contains
-----
fsck from util-linux-ng 2.17.2
User cancelled filesystem checks
/dev/sda1: e2fsck canceled.
fsck.ext4: Inode bitmap not loaded while setting block group checksum info
mountall: fsck / [234] terminated with status 8
mountall: Unrecoverable fsck error: /
-----
OBSERVATIONS
Seen on both lucid and maverick in virtualbox, and confirmed by Benjamin Kay on lucid non-virtual ( https:/
Same error is seen when running from maintenance shell on boot, or liveCD.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: e2fsprogs 1.41.11-1ubuntu2
ProcVersionSign
Uname: Linux 2.6.34-2-generic i686
Architecture: i386
Date: Tue May 18 02:24:53 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
ProcEnviron:
LANG=en_GB.utf8
SHELL=/bin/bash
SourcePackage: e2fsprogs
description: | updated |
Changed in e2fsprogs: | |
status: | New → Fix Released |
tags: | added: patch |
Changed in e2fsprogs (Ubuntu): | |
status: | Confirmed → Fix Released |
tags: | added: testcase |
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