GrUB hanging problem
I'm currently in the middle of a project designed to get rid of all the IDE hardware in Scrat, as it's just not very efficient. Recently, I acquired an Ultra160 SCSI hard drive, which is currently doing very nicely as the only hard drive in the system. However, things weren't always this rosy...
The first thing I did when I got the new drive was similar to every other time I've wanted to move a system onto a new drive rather than just add it as a second (third, fourth...) drive. Firstly, partition the drive sensibly, then secondly copy the data across. This part went well, just as expected. In fact, it went better than normal - the Linux kernel seemed to accept the new partition table straight away. This is a huge problem I normally have with the kernel - why can't it reread a partition table on a disk that's never been mounted? Anyway, I'm digressing.
The next stage was to remove the IDE hard drives, boot up a suitable copy of GrUB from a removable medium (SCSI CD drive, in this case), and use GrUB to install itself onto the target hard drive. Fine. It sees the hard drive, notices the parition and is able to locate its stage 1.5 and stage 2 files on the drive. So it installs itself and returns success. Great. Or so I thought.
After ejecting the CD and rebooting, there was evidently a problem. The SCSI BIOS kicked in after the system BIOS, just as normal, and identified the three devices connected to that particular controller. The system then presents it's status summary and a rather long PCI device listing, tries and fails to boot four CD drives (no CDs in them, so the failure is expected), and then promptly freezes at the point that GrUB should be doing its stuff.
Anyway, after much fiddling and finding out that all other bootloaders I tried, such as LILO and the Debian MBR, worked perfectly. In fact, installing LILO and GrUB on seperate partitions and using LILO to chainload GrUB worked up until the chainloading stage, and then the system just froze, no output at all.
Looking at the GrUB FAQ, it seems that the older BIOSes on my trusty Adaptec 2940UW SCSI card had some serious problem with Int13 (like they said they were doing it, but didn't. Now that's an impressive bug from someone as well known as Adaptec). That didn't seem to be the problem, though, as that freezes either after writing "GRUB", or after trying any disk access from the command line or a menu. As it happens, the v2.20 BIOS I'm using at the moment seems to do Int13 correctly.
After comparing md5sums with my mate, one thing struck me - although we had the latest Debian GrUB packages installed, they weren't being used. For nearly obvious reasons, they put their files elsewhere and let you upgrade your bootoader as and when you're ready. Great. It turns out that I've been using an ancient version of GrUB.
Copying the files to from /usr/lib/grub/i386-pc to /boot/grub and re-issuing setup from the GrUB CD worked a treat. GrUB booted and failed to boot the kernel as expected. Tweaking the menu to point out that it should be looking at the new parition rather than the old one sorted this problem, and eveything has been working great since. Hopefully, if anyone else runs into this problem, this page will save some of the time I had to spend working out what had happened. Obvious, when you think about it, isn't it?