"GRUB Error 16: Inconsistent filesystem structure" with ReiserFS and "savedefault" option

Bug #64928 reported by Daniel Hahler on 2006-10-09
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub (Ubuntu)

Bug Description

While I was testing hibernation on my system, I sometimes got the error "GRUB Error 16: Inconsistent filesystem structure" when trying to boot the default kernel.

I also got the same error during rebooting normally, after I've resumed from hibernation.

This problem can be quite easily be fixed by using the "recovery" kernel provided in grub menu: the ReiserFS transaction logs then get replayed then.
After having hibernated before, the system will even resume normally, but when it happens after a "normal" reboot, I get the recovery root prompt only (though "init 2" should work from there).

Grub Error 16 is described as:
16 : Inconsistent filesystem structure
This error is returned by the filesystem code to denote an internal error caused by the sanity checks of the filesystem structure on disk not matching what it expects. This is usually caused by a corrupt filesystem or bugs in the code handling it in GRUB.

So, I think that there might be a problem with the hard disks not really synced or something alike during shutdown.
It did not happen always, but at least twice.

This is with Edgy.

Daniel Hahler (blueyed) on 2006-11-11
description: updated

This problem happened to my wife running amd64!Dapper. No hibernation issue - the machine apparently spontaneously rebooted, and rather than replaying the ReiserFS journal, GRUB failed with the aforementioned Error 16. Booting into an older kernel in recovery mode fixed the problem.

Kernel: 2.6.15-27-amd64-generic
Grub: 0.97-1ubuntu9

See also: https://savannah.gnu.org/bugs/?17957 for a similar bug report.

Daniel Hahler (blueyed) wrote :

The URL given by Kit seems to be the related upstream bug report.

You can workaround the problem by removing the "savedefault" lines from /boot/grub/menu.lst
Unfortunately you have to do this always after "update-grub".

Here's a patch, which allows setting if "savedefault" should get used: https://bugs.launchpad.net/ubuntu/+source/grub/+bug/66278

Rimas Kudelis (rq) wrote :

I get a very similar error after each power failure as well as after each hibernation attempt. Booting into recovery mode and then pressing ctrl+alt+del solves the problem, but this is very annoying. Especially because grub takes about a minute, or maybe even two to display its menu, and then another minute to finally boot the kernel in such case.

Martin Schaaf (mascha) on 2008-02-03
Changed in grub:
status: New → Confirmed
Martin Schaaf (mascha) wrote :

I still have this problem.

Martin Schaaf (mascha) wrote :

Removing savedefault from the menu.lst fixes the problem.

Martin Schaaf (mascha) wrote :

On the menu.lst I uploaded the savedefault is missing because I removed it to have a working system and forgott to add it again. So the entry that has the savedefault option set is:
title Ubuntu 7.10, kernel 2.6.22-14-generic
root (hd0,0)
kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=0b6c3d0a-0869-40b5-bc65-5b3c0c2d14f3 ro quiet splash locale=de_DE
initrd /boot/initrd.img-2.6.22-14-generic

Tormod Volden (tormodvolden) wrote :

Martin, you have "# savedefault=true" in your menu.lst. Set it to "false" (which is the default).

Martin Schaaf (mascha) wrote :

I have not set this by hand to true. Does this come from upgrade to gutsy?

Tormod Volden (tormodvolden) wrote :

If there's no "# savedefault=" line in menu.lst, update-grub will add one (yes, I think since Gutsy). It will set this new parameter to "false", unless it detects a "default saved" line, in which case it believes you are happily using savedefault and want to continue that way. Of course, if there's already a "# savedefault" line, it won't change it.

Fabien Toral (malibug) wrote :

One of my machine is affected by this bug, but it has the ext3 filesystem...

Jorge Castro (jorge) on 2009-03-13
Changed in grub:
importance: Undecided → Unknown
status: New → Unknown
Daniel Hahler (blueyed) wrote :

I am setting the importance to Low.
Apparently grub2 is not affected by this and there's a workaround. It should not be a problem with new installs of Ubuntu (using grub2).

Changed in grub (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Daniel Hahler (blueyed) wrote :

Closing as "Won't fix". Grub is not supported anymore and Grub2 appears to work OK.

Changed in grub (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.