building and installing a new kernel makes my system unbootable

[Robert P. J. Day]

On Mon, 5 Jul 2010, Chan Chung Hang Christopher wrote:

> Robert P. J. Day wrote:
> >   some strange things happening here -- for the first time, after
> > i configured and built a new kernel, i ran "make deb-pkg" to turn
> > it into a .deb package file, then used "dpkg" to install that,
> > after which i still apparently had to run the appropriate
> > incantations of "update-initramfs" and "update-grub", then i
> > rebooted.
> >
> >   the boot process is clearly trying to boot the new kernel
> > (2.6.35-rc4+), only to fail with an error trying to mount the root
> > filesystem.  no problem, thinks i, i'll just reboot, drop into
> > GRUB and select the earlier, working kernel ... except that
> > nothing i do will get me to GRUB -- not SHIFT, ESC or TAB.  when i
> > installed my ner kernels manually, SHIFT always worked, but now, i
> > have no idea what's changed.
>
> sounds like stage1 not being able to load stage2

> >   i suspect i'll boot off of the CD and poke around, but i'm open
> > to suggestions -- why would this have happened?  and is there
> > *something* that will get me to GRUB?
>
> reinstall grub.

  i'm not sure why that would solve the problem since i can certainly
boot any of my *older* kernels, suggesting that GRUB itself is fine.
it's just building a new kernel from the canonical kernel source tree
that gives me an unbootable system -- to the point where i can't even
stop in GRUB during the boot process to select an earlier, working
kernel.

  to recap, here's the recipe that seems to have worked fine for me so
far:

  * "git pull" the canonical source tree (currently at 2.6.35-rc4)
  * copy good config starting point from /boot

  $ yes '' | make oldconfig    [to bring .config up to date]
  $ make
  $ sudo make modules_install
  $ sudo make install
  $ sudo update-initramfs -c -k 2.6.35-rc4+
  $ sudo update-grub

i can visually verify that all of the above seems to install the right
things in the right places and, until now, it seems to have worked
fine.  so why the sudden failure?

  the end result of the above is a kernel panic trying to mount the
root FS, so maybe GRUB really is borked somehow and, as i wrote
earlier, the only way i can recover is to boot to rescue mode and
manually remove those entries from /boot/grub/grub.cfg.

  is any part of my recipe above suspect?  it's just odd that it seems
to have worked so well until now.  is there some kind of validation
command i can run before rebooting that will perform some kind of
sanity check on the current GRUB setup?

rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Top-notch, inexpensive online Linux/OSS/kernel courses
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================