Bug#454926: e2fsprogs: get "primary superblock features different from backup at each check/reboot
giggz
Version: 1.40.3-1
Severity: normal
Hi,
Since the yesterday upgrade of e2fs* i get this message when the pc
checks my filesystem :
"primary superblock features different from backup, check forced"
This appear on all the ext partitions that I check.
What can I do to avoid that ?
Is there a bug or is it because my system comes from woody and I
change 2 flags of my partitions by myself with tune2fs ?
Regards,
Guillaume
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.23.9-3 (PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages e2fsprogs depends on:
ii e2fslibs 1.40.3-1 ext2 filesystem libraries
ii libblkid1 1.40.3-1 block device id library
ii libc6 2.7-4 GNU C Library: Shared libraries
ii libcomerr2 1.40.3-1 common error description library
ii libss2 1.40.3-1 command-line interface parsing lib
ii libuuid1 1.40.3-1 universally unique id library
e2fsprogs recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Theodore Tso
> Package: e2fsprogs
> Version: 1.40.3-1
> Severity: normal
>
> checks my filesystem :
> "primary superblock features different from backup, check forced"
> This appear on all the ext partitions that I check.
>
> What can I do to avoid that ?
> Is there a bug or is it because my system comes from woody and I
> change 2 flags of my partitions by myself with tune2fs ?
This is a one-time occurence. In order to make the usage of the
backup superblocks more robust, we now make sure that when the primary
superblock values change, that they get backed up in the backup
superblocks.
This become especially a problem with the usage of online resize
operations, which change the number of blocks in the filesystem in the
primary superblock, but *not* in the backup superblocks. However, I
didn't want to just automatically backup the data to the primary
superblock to the backup superblocks, since the information in the
primary superblock could be incorrect, and you don't want to blow away
the information in the backup superblocks in that case.
Hence, in the situation where the primary and superblocks contain
different values for certain key configuration parameters for the
filesystem (i.e., the filesystmem features bitmasks, the number of
blocks and number of inodes, etc.), e2fsck forces a check, and then
once it is sure everything is clean, it will copy the changes to the
backup superblock.
So it should only do this *once*; after that, the backup superblocks
will be in synch with the primary superblock, and then you shouldn't
see that message again.
Are you seeing more than once, after a filesystem check has been
successfully completed? If you are that's a bug, and it would be good
if you could send me the output of these two commands:
dumpe2fs -h /dev/sdXXX
(to print out the information of the primary superblock)
dumpe2fs -ob32768 -oB4096 -h /dev/sdXXX
(to print out the information of the backup superblock)
(or if you have a 1k block filesystem, replace the first two arguments
with "-ob8193 -oB1024"; and of course, replace /dev/sdXXX with the
device on which your filesystem is stored).
If you are only seeing that message once, then it's normal operation
and there is no bug.
Regards,
- Ted
giggzounet
Theodore Tso a écrit :
Yes after a forced check it doesn't appear anymore. But I change the
number of count with 'tune2fs -C' to force a check after a reboot and in
this case I see the message again. If I change the max count to 2 or 3,
and then I reboot several time I don't see any message again. So it is a
normal behavior.
> Are you seeing more than once, after a filesystem check has been
> successfully completed? If you are that's a bug, and it would be good
> if you could send me the output of these two commands:
>
> dumpe2fs -h /dev/sdXXX
> (to print out the information of the primary superblock)
>
> dumpe2fs -ob32768 -oB4096 -h /dev/sdXXX
> (to print out the information of the backup superblock)
>
> (or if you have a 1k block filesystem, replace the first two arguments
> with "-ob8193 -oB1024"; and of course, replace /dev/sdXXX with the
> device on which your filesystem is stored).
I don't give the results of these 2 command lines because (as you
explain to me) it's not a bug. So you can close the bug also.
>
> If you are only seeing that message once, then it's normal operation
> and there is no bug.
>
> Regards,
>
Cheers,
Guillaume
Theodore Tso
> Yes after a forced check it doesn't appear anymore. But I change the
> number of count with 'tune2fs -C' to force a check after a reboot and in
> this case I see the message again. If I change the max count to 2 or 3,
> and then I reboot several time I don't see any message again. So it is a
> normal behavior.
Huh? Really? This is what I see:
<tytso.root@closure> {/home/tytso}, level 2
541# tune2fs -C 100 /dev/sda1
tune2fs 1.40.3 (05-Dec-2007)
Setting current mount count to 100
<tytso.root@closure> {/home/tytso}, level 2
542# e2fsck -p /dev/sda1
/dev/sda1 has been mounted 100 times without being checked, check forced.
/dev/sda1: 53/122624 files (15.1% non-contiguous), 84162/244983 blocks
You're seeing the "XXX times without being checked" message, not the
"primary superblock features different from backup superblock"
message, right?
Giggz
> On Sat, Dec 08, 2007 at 07:33:28PM +0100, giggzounet wrote:
>
>> Yes after a forced check it doesn't appear anymore. But I change the
>> number of count with 'tune2fs -C' to force a check after a reboot and in
>> this case I see the message again. If I change the max count to 2 or 3,
>> and then I reboot several time I don't see any message again. So it is a
>> normal behavior.
>>
>
> Huh? Really? This is what I see:
>
> <tytso.root@closure> {/home/tytso}, level 2
> 541# tune2fs -C 100 /dev/sda1
> tune2fs 1.40.3 (05-Dec-2007)
> Setting current mount count to 100
> <tytso.root@closure> {/home/tytso}, level 2
> 542# e2fsck -p /dev/sda1
> /dev/sda1 has been mounted 100 times without being checked, check forced.
> /dev/sda1: 53/122624 files (15.1% non-contiguous), 84162/244983 blocks
>
> You're seeing the "XXX times without being checked" message, not the
> "primary superblock features different from backup superblock"
> message, right?
>
> - Ted
>
>
'tune2fs -C 100 /dev/hda1', then I reboot I get the "primary superblock
features different from backup superblock" message ( :( ). Then fsck
died with exit 1 . So in the case of root the computer reboot and I
don't see the message again. For others partitions fsck died with error
1 too and the boot continues. Than at next reboot I don't see anything
again.
I will test it again at night to verify and to give you more
informations if it is necessary.
Thx for your attention
Regards,
Guillaume
Theodore Tso
> I'm at work. I can't test it. But if I remember correctly, when I do
> 'tune2fs -C 100 /dev/hda1', then I reboot I get the "primary superblock
> features different from backup superblock" message ( :( ). Then fsck died
> with exit 1.
Fsck "dieing" with exit 1 is normal. That just means that the
filesystem has been modified ("filesystem errors are corrected") and
this isn't an error condition. Note also that the logs from the
current boot are available at /var/log/fsck/checkfs and
/var/log/fsck/checkroot. So you can see what happened at the last reboot.
Unfortunately the init scripts are buggy here. When fsck exits with
an exit code of 1 or 3, it shouldn't use usb the init script helper
function log_action_end_msg (since it prints a red "failed") message.
Instead they should use log_warning_msg to indicate that a full
filesystem check had happened and some non-trivial change (such
backing up the filesystem superblock) had taken place.
I've checked again, though, and both experimentally and by looking at
the sources, if the *only* change you had made was changing the mount
count via tune2fs -C, you shouldn't be seeing the change. The only
things which will trigger a superblock backup are changes in the
superblock feature bitmaps (i.e., tune2fs -O, tune2fs -j, or tune2fs
-s), or changing the number of blocks or inodes (doing an on-line
resize), or changing the uuid (via tune2fs -U).
giggzounet
Theodore Tso a écrit :
I'm at home and I have tested (there is a problem):
so I'm under X I do (/dev/hda6 is mounted, it's my home):
18:54 root@debian /home/giggz/Aide # tune2fs -l /dev/hda6
tune2fs 1.40.3 (05-Dec-2007)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: a514636f-6d5d-4709-8b7e-cb632bca6aa1
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal dir_index filetype needs_recovery
sparse_super
Filesystem flags: signed directory hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 524288
Block count: 1024135
Reserved block count: 30724
Free blocks: 559580
Free inodes: 471505
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Mon Sep 27 19:16:54 2004
Last mount time: Mon Dec 10 18:41:59 2007
Last write time: Mon Dec 10 18:41:59 2007
Mount count: 9
Maximum mount count: 20
Last checked: Sat Dec 8 19:52:47 2007
Check interval: 15552000 (6 months)
Next check after: Thu Jun 5 20:52:47 2008
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: ed5a0da0-92b5-41db-9616-a60f12d2fc8c
Journal backup: inode blocks
So I change the maximum count :
18:59 root@debian /home/giggz/Aide # tune2fs -C 100 /dev/hda6
tune2fs 1.40.3 (05-Dec-2007)
Initialisation du nombre courant de montages à 100
then I do a 'tune2fs -l /dev/hda6' to verify.
18:59 root@debian /home/giggz/Aide # tune2fs -l /dev/hda6
tune2fs 1.40.3 (05-Dec-2007)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: a514636f-6d5d-4709-8b7e-cb632bca6aa1
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal dir_index filetype needs_recovery
sparse_super
Filesystem flags: signed directory hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 524288
Block count: 1024135
Reserved block count: 30724
Free blocks: 559578
Free inodes: 471503
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Mon Sep 27 19:16:54 2004
Last mount time: Mon Dec 10 18:41:59 2007
Last write time: Mon Dec 10 18:59:14 2007
Mount count: 100
Maximum mount count: 20
Last checked: Sat Dec 8 19:52:47 2007
Check interval: 15552000 (6 months)
Next check after: Thu Jun 5 20:52:47 2008
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: ed5a0da0-92b5-41db-9616-a60f12d2fc8c
Journal backup: inode blocks
And I reboot. And I get that :
19:04 giggz@debian ~ % cat /var/log/fsck/checkfs
Log of fsck -C -V -R -A -a
Mon Dec 10 19:01:31 2007
fsck 1.40.3 (05-Dec-2007)
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /home] fsck.ext3 -a -C0 /dev/hda6
/dev/hda6 primary superblock features different from backup, check forced.
/dev/hda6: 52781/524288 files (4.7% non-contiguous), 464551/1024135 blocks
[/sbin/fsck.ext3 (1) -- /donnees] fsck.ext3 -a -C0 /dev/hda4
DONNEES: clean, 6768/3071168 files, 1643181/3070423 blocks
fsck died with exit status 1
Mon Dec 10 19:01:58 2007
----------------
So there is a problem. After this, If I reboot I don't have any problem.
My system is quite old. I'm under SID since woody. Last yest I did this
changes on my partitions because I read that this flag was enabled yet
by default :
tune2fs -O dir_index /dev/hda6
fsck -fD -C0 /dev/hda6
Could this change have a relation with my problem ?
Thx a lot
Guillaume
Matthias Richter
with exit code 3.
I can boot normally _once_ afterwards, but the filesystem is marked as
"needs_recovery"and on the next reboot the check will be forced again.
# diff dump_orig dump_backup
6c6
< Filesystem features: has_journal filetype needs_recovery sparse_super
---
> Filesystem features: has_journal filetype sparse_super
8c8
< Filesystem state: clean
---
> Filesystem state: not clean
24,26c24,26
< Last mount time: Tue Dec 11 08:41:18 2007
< Last write time: Tue Dec 11 08:41:18 2007
< Mount count: 1
---
> Last mount time: Mon Dec 10 20:26:13 2007
> Last write time: Tue Dec 11 08:36:17 2007
> Mount count: 0
36d35
< First orphan inode: 821409
So, obviously, something doesn't get updated here and things loop: The
check is forced, fsck dies, I boot normally once, the check is forced,
fsck dies ...
Matthias
Theodore Tso
> Unfortunately the problem doesn't occur only once here and fsck dies
> with exit code 3.
Exit code 3 is normal. Read the man page; that just means that the
filesystem was modified and it was the root filesystem, so the system
should reboot. So that part is OK....
> I can boot normally _once_ afterwards, but the filesystem is marked as
> "needs_recovery"and on the next reboot the check will be forced again.
Ah, OK. So you're not doing a clean shutdown (hence the "heeds
recovery") and that's confusing e2fsck into thinking it needs to do a
full check so it can backup the superblock. Oops. That's a bug.
I'll take a look at it, and get a fix out quickly.
- Ted