Productive Linux


 Subscribe via Feedburner in a reader

Enter your email address:

Delivered by FeedBurner


Don't have an account?
Sign up to
Forgot your password?

SuperGrub is a Sanity Saver
11 June 2010 @ 13:31 BST
by Paul

Thank you people at SuperGrub, you saved my computer.

Yesterday, I wanted to update my kernel to 2.6.32 because the ASUS driver for sensors, i.e. CPU temperature etc had changed, from it87 to asus_atk0110.

Also, I needed to update udev, but the Debian package manager refused to update udev with the current running kernel.

A couple of things pointed to udev problems. Once was that a scanner could only be recognised by a super user, and not anyone in the 'scanner' group. Also, any USB mass storage device was not automatically mounted.

So, I compile a kernel and reboot.

A disaster ensured and much ammusement was had at my expense.

The kernel would start booting, but as soon as the it tried to mount the root file system it would hang. This happens when the kernel can't find the root file system. There are a few reasons why this might be the case:

  • the wrong root is passed to the kernel using the root= config option.
  • because of the new udev software, the device files aren't coming up early enough or perhaps at all
  • the kernel is compiled with the wrong options, in particular with CONFIG_SYSFS_DEPRECATED enabled
  • there's a bug in the kernel
  • there's a bug in udev
  • there's a bug in mkinitramfs

It was true that in the newly compiled kernel I had not turned off the CONFIG_SYSFS_DEPRECATED option.

Fortunately, I had a live Ubuntu CD that I could boot the machine with, do some mounting, and chroot into the broken machine.

This enabled me to install a standard 2.6.32 kernel. It didn't help though and the same error came up. However, if, in the chroot jail, I updated both udev and grub, then I could boot again. This time into legacy grub which would chain into grub2.

This suggests that the problem was the way that legacy grub was passing information to the kernel.

Having determined that grub2 worked I ran

to remove grub1.

This caused an even worse problem. Grub2 now didn't even get to the menu screen, instead, I got an 'Error 15' meaning that grub couldn't find the files that it needed to startup.

Some googling suggested to me that the update from 'legacy grub' to grub2 had not gone smoothly and that the operation had left the MBR (Master Boot Record) hosed.

Fortunately, there is a simple solution to a totally wrecked MBR. That is the amazingly wonderful SuperGrub boot disk! I downloaded the iso, burned it to a CD and booted.

SuperGrub can recognise a grub install anywhere on a computer. It read grub.cfg which had been correctly configured and booted my computer.

Once I had booted, I could fix the hosed MBR by doing

sudo grub-install /dev/sda
and everything worked.

Thanks to the wonderful people at SuperGrub!!!

Handy Kernel Building script

Always check the vmlinuz/initrd links to /boot and adjust /boot/grub/grub.cfg after installing a new kernel.

Posted by anon on 2010-06-11 21:55:53.
Comments disabled