[Bug 1103187] Re: automatic updates tend to reboot and die into grub rescue

Fri Jan 25 16:57:38 UTC 2013

Thanks for your time and suggestions.  I think, we are closer to narrowing the source of the problem.  The phenomenon appears on other box as well, and I did also a fresh install with XFS root containing the /boot/ tree.  The deterministically repeatable phenomenon is:

        take a 12.10 with XFS root partition containing the /boot/ tree

        dpkg-reconfigure grub-pc ; sync

        reboot (either by command, or by menu)

        diverse error messages + grub rescue + /boot/ is partially
accessible

        boot UBUNTU 12.10 pendrive + choose "try Ubuntu" + open a
terminal

        sudo -s; mkdir foo; mount [the XFS root partition] foo; umount
foo

        reboot into the "original" Ubuntu is NOW successful

Key information, that in "try Ubuntu" the xfs_check of my XFS root
partition told, that "error: the filesystem has valuable metadata
changes in a log which needs to be replayed.  Mount the filesystem to
replay the log".

This gave me the idea, that not "the boot into my Ubuntu by using
SYSRESCCD" itself is important, but the sideeffect of it, that namely
the root partition is mounted, and hence the pending changes are
discharged, and hence the intention of the "dpkg-reconfigure grub-pc"
and the reality in the physical blocks on the drive get into coherence
with each other, and hence all the later reboots will be successful!

That's why I gave up booting my Ubuntu with the help of SYSRESCCD, but
simply to get somehow (say with "try Ubuntu") into a living linux, and
issue a mount concerning the partition in question.  And it does work,
everywhere of my 3 boxes, and even on the fresh install YOU SUGGESTED
ME.  Hence the problem is somewhere around the temporary incoherency due
to the delayed feautures of the journaled filesystem in question.

Yet another error message: ELF sections outside core.

It is not clear, how much the "dpkg-reconfigure grub-pc" is responsible,
since it perhaps should be prepared for journaled filesystems.

To put /boot/ tree into a NON-root partitions appears to be a reliable
work around.  Probably because the shut down process can bring down a
NON-root partition coheretntly, even if there are delayed transactions
in it's journal.

In the case of the root partition, perhaps as a final stage, the shut
down process should migrate to a ram rooted system, and then it can
bring down the original root partition the same way as all the other
NON-root partitions.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1103187

Title:
  automatic updates tend to reboot and die into grub rescue

Status in “grub2” package in Ubuntu:
  Incomplete

Bug description:

  On 3 essentially different Ubuntu 12.10 installations

          bios or uefi boot,
          linux is alone or other system is along,
          legacy or guid partiton table

  it is a regularly appearing issue since 12.10, that if the automatic
  update touches a package which has some impact on the boot,

  then the next reboot get stock at either the grub rescue prompt, or
  booting the new kernel hangs at the missing initial ram disk, the
  latter is typical after kernel update, even just after the virgin
  installation of a fresh Ubuntu.

  Grub rescue prompt is the much harder situation, I either type in the
  correct grub commands to boot the previous kernel, or I use a "boot an
  existing linux from a partition" menu of a SYSRESC pen drive.

  Never really clear, what was wrong and what really helped.

  Here is a list of my manual struggling and accidental solution
  methods:

  (1) Sometimes I do nothing, except for booting once more the system by
  hand or by SYSRESC pen, and surprisingly the next time the system
  boots, asif there was no kind of problem before.   THIS happens more
  frequently on the combination below, and less frequently on the other
  2 combinations:

          bios boot + other system along + legacy partition table

  (2) More frequent in general is that remove/reinstall grub2, and/or
  remove/reinstall new kernel, and/or simply grub-install and update-
  grub helps, but usually NOT IN ONE STEP, however even after a logical
  and defensive

          grub-install /dev/sda

  the situation likes to become worse, usually changes between the two
  possibilities below:

          "error: invalid arch-independant ELF magic."

          "error: ELF header smaller than expected."

  and naturally I have the grub rescue prompt.   This time, just before
  this error report, the solution appeared to be the

          removal of memtest86+ and reinstall of it,

  as first there was a normal grub menu, but memtest was missing from it
  and the boot was unsuccessful, and after the usual kernel and grub
  tampering I got the invalid arch-independant ELF magic, furter usual
  tampering bought the ELF header smaller than expected, and finally my
  desperate trial was the removal of the memtest against it's
  dependencies, ... and it helped this time.

  This kind of struggling is more frequent on the 2 combination below:

          bios boot + linux alone + legacy partition table

          uefi boot + linux alone + either legacy or guid partition
  table (the both yields the error)

  The latter uefi shows the problem most stable, even if I reinstall the
  12.10 back to bios, from scratch.

  I work with computers since 1972, and with linux 1994, but I still has
  no firm idea which package is buggy.

  My guess is that not the grub itself is buggy, but the other packages
  have a buggy configuration relation to grub.

  I suggest to rate this bug serious, if we take serious the #1 main
  bug, see this site.

  I spread linux among my students at the university since the 90's,
  however if their system can become unavailable due to an automatic
  update, then some of then will give up learning linux.

  I understand that a usual other bug can be serious and hard.  But if I
  suggest the someone to switch to linux, and he/she can lost even the
  booting opportunity, then it is scary for most of the average users,
  and usually they have no enough skills to tackle the situtation, even
  to rescue their own personal files back to a proprietary system.

  That's why I suggest to rate this bug serious.  Serious in the
  consequencies in public relations.

  The version of the all the packages I use are the most up to date due
  to my policy to update as frequent as possible.

  ProblemType: Bug
  DistroRelease: Ubuntu 12.10
  Package: grub2 (not installed)
  Uname: Linux 3.2.34-std312-amd64 x86_64
  NonfreeKernelModules: raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear radeon r8169 mii usb_storage ttm drm_kms_helper drm i2c_algo_bit i2c_core wmi
  ApportVersion: 2.6.1-0ubuntu10
  Architecture: amd64
  Date: Tue Jan 22 21:28:32 2013
  InstallationDate: Installed on 2012-10-19 (95 days ago)
  InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
  MarkForUpload: True
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: grub2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1103187/+subscriptions