ACPI administration advocacy advocacy advocacy opinion alsa amarok apache apple apt aptitude audio audo authentication automount avi awk bash BIOS boot business cache calendar calibre censorship commandline computerscience console cron cut database date debian degree design desktop development disk dpkg dvd economics education emacs email europe exim faad ffmpeg files firefox firewall flash foss freedom ftp fun fuse git gnumeric grep growisofs grub gtkpod hardware hardware html idiocy images installation ip iphone ipod iptables iso itunes ivman kde kernel keyboard knoppix lame laptop latex linux locale lockin longlines m4a microsoft mimetypes minitab mount mp3 mp4 mplayer multimedia music mysql network nfs nfs4 nmap openbox openoffice opinion opinion partition pdf perl php politics postgresql printing privacy programming rant remote rhythmbox rss rsync rxvt scp script scripting scsi security sed server shell siteadmin sitenews sitesoftware skype skype slackware sound sox spam spreadsheet ssh statistics subversion sudo svk swap t23 t43 terminal text thinkpad thunderbird time timezone ubuntu udev upgrade usb usbmount users uuid versioncontrol vfat video vnc windows wine wordpress wordprocessing X40 xwindows xwindows youtube
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:
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
upgrade-grub-from-legacyto 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/sdaand everything worked.
Thanks to the wonderful people at SuperGrub!!!
Handy Kernel Building script
http://paste2.org/p/873811
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.