Mailinglist Archive: opensuse-bugs (6665 mails)
|< Previous||Next >|
[Bug 729667] New: grub error after each kernel-update: "Error 16: Inconsistent filesystem structure"
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Thu, 10 Nov 2011 18:34:56 +0000
- Message-id: <email@example.com/>
Summary: grub error after each kernel-update: "Error 16:
Inconsistent filesystem structure"
Product: openSUSE 11.4
OS/Version: openSUSE 11.4
Priority: P5 - None
Found By: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101
I'm running 4 32bit machines with openSUSE 11.4 and each time there is a kernel
update, at least one or two of those (different ones each time) refuse to
(re)boot afterwards. Grub shows its menu for a few seconds and then
immediately says "Error 16: Inconsistent filesystem structure". On each
machine, the boot partition is ~80MiB ext2. fsck.ext2 (from LiveCD) says
everything's OK. Recreating the boot partition with mkfs.ext2 fixes the
problem until the next update arrives.
A bit more details.
(This is mostly a copy from
Here's what I did/observed this Tuesday:
* "zypper update", which (besides other stuff) listed kernel-default. I
* After this is done, I did "shutdown -r now" to reboot.
* Grub shows its menu (text mode only, I don't have the graphical bootsplash
installed). After 3 sec or so timeout, it tries to boot as always, but
immediately says "Error 16: Inconsistent filesystem structure".
Unfortunately, this problem occurs only randomly. I'm running 4 64bit machines
and 4 32bit machines. Up to now it happened only on 32bit machines and at every
kernel-update, it occurs on 1 or 2 of my machines. To fix this, I have to boot
from external media and recreate the broken boot-partition (i.e. copy files to
some temporary place and do a "mkfs.ext2 /dev/sda1", then copy back on the new
filesystem). Then I mount everything, chroot in my to-be-fixed system and run
"grub-install". After that I can boot from harddisk again.
The filesystem which is inconsistent according to grub is ok according to
fsck.ext2. I checked this before rewriting the filesystem with mkfs.ext2. The
system where it happened yesterday contains only one harddisk with two
partitions: sda1 is /boot, ext2, 80MiB; sda2 is a luks-encrypted lvm container.
Partition table is gpt, grub is installed in the mbr (I think). The way I
installed these systems I a bit unorthodox: I basically set up the partitioning
scheme by hand and mounted everything, then did a "zypper -R /mnt/root install
..". While this might contribute to the triggering of this behavior, it still
believe there is an underlying bug that is causing this mess. I have no other
explanation for this to happen only randomly, but not always.
In the last months I always just "fixed" this as fast as possible to move on.
On Tuesday I made a copy of /dev/sda1 ("cat /dev/sda1 > file") right after
booting my rescue system. I also updated two other 32bit machines without
problems. Another 32bit machine is still awaiting the kernel update (I did not
"zypper update" yet).
Sadly, I don't see an obvious way to reliably reproduce the problem (without
waiting for the next kernel update). I can share my boot-partition-image with
you which I created before fixing it, also log-files and other data. But since
all 4 32bit machines are production systems my ability to do experimentation
with them is limited. But if it would be helpful I can try to collect more
data when updating my remaining not-updated machine.
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
|< Previous||Next >|