Last month I tried unsuccessfully to setup GRUB on my shiny new Slamd64 box. As most devout slackware users will attest, LILO works just fine and is the default bootloader on the Slackware distro. The only reason I decided to delve into GRUB was Dann Washko of TLLTS, and also the fact I'm insanely curious. I'm of the opinion that you never stop learning, so I set out to begin preparing for a GRUB install.
As stated previously, GRUB is not the default bootloader for Slackware, but you can obtain it within /extra on any Slackware mirror. So, once I finished my slamd64 install I chose not to setup LILO configuration. I knew that I could always boot from my install CD and drop down into telinit 1 (single user), so that I could fix things if stuff broke.
As luck would have it, I was not able to get beyond stage 1.5, as the bootloader would dump me into the GRUB shell. Not so bad I thought. The dreaded error 28 - not enough memory to perform this function. Since this box has 4GB of RAM, I was somewhat confused as to why I was getting this error. After poking around and several reboots, I decided to re-install GRUB.
Actually, I began to get a different error after re-installing GRUB. This time Error 15 and it would just hang the system. Quite annoying. I spent a fair amount of time trolling #grub, #slamd64, and of course #lottalinuxlinks. Interestingly, some of the people forewarned me about grub on a 64bit platform. I was even advised to use grub2. Of course grub2 is not yet available slackware-current or any slamd64 repositories. In general, it does seem that grub is not the bootloader of choice for many slackware users. After this experience I can understand why ;-)
Finally, I booted with the slamd64 install CD and was able to get into single-user mode and then discovered that the root partition was thoroughly munged and could not be mounted without my intervention. Apparently the superblock had become corrupted, and could not be read. It is likely that I created this condition while repeatedly removing/installing grub on the MBR. Who knows the root cause (no pun intended). All I know is that I never had this sort of problem with trusty and well understood LILO. I don't care how outdated it is or its limitations. It just works when you install it. It was funny to read the comments in IRC as I was learning about GRUB. Of course, I had to setup chroot environment so that I could modify the appropriate partitions, which were obviously not mounted by the install CD. The rootfs of the install CD certainly was not area of focus here ;-) Hence chroot was required. Well beyond what grandma moses or the average user would be doing..
Back to those IRC comments -- Stuff like "Wow, do you really need to do this with a modern OS?" Yes, I am a glutton for punishment, but at the end of the day I am not a masochist. The whole point of installing grub was to learn about a new bootloader. Nothing more, nothing less. I suppose the corrupted superblock spoiled my interest in going any further.
Try as I might, I was not able to recover all of the missing superblocks. I tried '/sbin/dumpe2fs /dev/sda3', so that I could actually see the missing superblocks and the associated inode allocations. For those who run other OSes.. Think of corrupt superblock as a badly fragmented filesystem on a hard disk. Every OS offers tools to defrag a disk, well Linux offers several fairly robust tools. e2progs is one of the more complete set of tools. I was able to confirm the block size of the inode 'tune2fs -l /dev/sda3'
Another nifty trick was to backing up all of the pertinent missing superblocks temp file. Running '/sbin/mkfs.ext2 /tmp/foo' essentially backed up superblocks to a temp file called foo. For the experienced Linux user, you'll wonder why ext2fs is used in this instance, as it turns out I'm actually using ext3 filesystem, but it makes no difference.
Unfortunately, running 'e2fsck -y -b
All works well now, and I cannot honestly blame grub for the problems. However, I suppose that I confirmed the old adage, if it ain't broke don't fix it.