Jump to content






Photo
- - - - -

MBR

Posted by notKlaatu , 04 March 2008 · 172 views

MBR Some notes about Linux installs. Through a series of troublesome installations, I have discovered a few important things about the Master Boot Record. (I've also found out some cool things about kernels and how they relate to file systems, but more on that later.) The Master Boot Record (MBR) is written on the very edge of the harddrive; it is the first thing to load when you turn on a machine that you have installed Linux onto. It prompts you for what system you would like to boot into. There are two boot loaders that are used; there is LiLo (Linux Loader) and there is GRUB (Grand Unified Bootloader). Both do the same thing and are pretty easy to configure via a text editor and some config files. So far every distro that I have installed (and there have been many) have been able to auto-configure a boot loader. The last few days being the exception, the auto-configuration function usually works really well. Ubuntu, for instance, detected that I had Slackware 11 on my first partition, and when it created a GRUB menu, it reflected this accurately and I never had any problem access either my Slackware or Ubuntu partition. And the same is true when I installed Slackware 12; it auto-detected Ubuntu on my second partition and over-wrote the Ubuntu GRUB with a little LiLo menu that accurately enabled me to boot into either Slack12 or Ubuntu. The problem arose after I tried to install freeBSD onto a third partition. Whether it was a user error or whether it was BSD not playing nice with Linux, my experiment with BSD was disastrous. BSD cursed my system, crippling it beyond being bootable. And recovering from this turned out to be an all day thing, and the problems that I had while trying to reconstruct my system stemmed entirely from the bootloaders. ______________Symptoms and Side Effects_______________ The freeBSD install went fine on the surface. It, like all the Linux distros I've tried, had the option to install a boot loader. I theorize that perhaps letting it install a boot loader was my real error. Otherwise, it seemed like I'd done a successful installation, but when I rebooted, the computer froze and the keyboard just gave error beeps when I typed. So I re-installed Slackware and then re-installed Ubuntu, clearing off the BSD partition entirely (and throwing the installation CD-R into my kitchen trash for good measure). The quirky thing about the always friendly Ubuntu is that it doesn't allow you to choose whether or not you want to install GRUB. It just does it. Normally I'd be fine with this, but after a few re-installs, I started to realise that some weird stuff was happening in the MBR. It's easiest to sum it up by comparing it to Mac OS X. If we were going to do a complete reinstall of OS X on a system, we would instert the OS installation disc, we'd wipe the harddrive completely, and click INSTALL. No problems. Everything is erased and everything is freshly installed as if the harddrive had just come out of the factory. The way I was installing, and the only way I know how to so far, was trying to (in a user-friendly fashion) keep track of the systems I had on that computer. So each time I re-installed something -- even if I was drastically re-partitioning the drive -- the MBR was being auto-detected, and whatever was written to it was added to the new bootloader. So, I'd re-install Slackware 12 and then Ubuntu. I'd reboot and I'd find that there were four Ubuntu versions listed and two Slackwares. I'd reinstall again and there'd be a different four Ubuntus and two more Slackwares. I'd re-partition and install again and there would be two Ubuntus but four Slackwares. All day I ran this vicious circle. The key, at last, was with Slackware. It has the option, when installing, to do an "Expert" LiLo installation. I ventured into that menu and it was there that I was able to force a new LiLo header to be written, I was able to manually add the partitions that I wanted to appear in the LiLo menu, and all seemed well. Of course, it wasn't. But it almost was. Because then I tried one more time to install Ubuntu, and it tried one more time to be helpful and install an auto-configured GRUB. _______________Root File Systems________________ Forcing a new LiLo header to be created solved my Slackware problems but for some reason Ubuntu would not load properly. It would boot, but then give me strange errors and finally boot into a crippled version of its usually robust OS. Apparently, what was happening, as I would find out later, was that Ubuntu was attempting to load its OS using the Slackware kernel. Not a big deal, except that the Slackware kernel was newer than the Ubuntu default kernel, and some of the automatic things that Ubuntu does really really well just weren't happening with the Slackware bare-bones default kernel. I tried repairing this from the Ubuntu side of things and messed it up worse, to the point that Slackware 12 broke down during its bootup and went into kernel panic. The solution, finally, was a magic trick involving the loading of a file system using a kernel from an installation disc. The *nix file system begins with / It is called the ROOT of the file system. And from the root everything cascades down in a family-tree kind of format, with certain folders being default and having certain functionality. As long as you can get into the root folder and establish that it's the path from which everything else should flow, you're basically in that system soundly and securely. But obviously in order for the computer to run properly, there has to be a healthy kernel running. Turns out that if you have a good installation CD or rescue CD, you can get the computer up and running by booting off of the CD. The computer loads the CD's kernel. Then, you can tell the computer to boot into the file system of your choice....while still using the CD's kernel. It looks something like this: % hugesmp-s root=/dev/sda1 rdinit= ro Something like that. Where hugesmp-s is the kernel, root=/dev/sda1 is the drive partition of my file system, and rdinit=ro has something to do with login items but I'm not sure what... all I know is it works. So I was able to sneak into my Slackware partition by distracting the computer with the installer kernel, and once I was there I could log in as root, open up my bootloader configuration file, and make the necessary corrections. It only took about three lines of text to fix it. Ubuntu was trying to load off of a Slackware kernel, and the Slackware menu selection was being pointed toward the wrong partition, or something like that. I don't recall exactly. But all I had to do was correct the file paths according to what I knew to be true, save the config file, and then run % lilo so that the computer would update the MBR. Then I rebooted again. And everything was fine. At last. ____________Lessons Learned______________ The MBR lies just outside of the normal file system. It will not necessarily be erased with a fresh install because even a fresh install assumes, in a very migration-assistant-user-friendly way that you want to keep track of the other bootable systems on that computer. There are, presumably, two ways to get around this: 1. Learn how to properly format an entire hard drive under Linux so that the fresh install is truly a fresh install. 2. Early on - not after thirty desperate re-installs of different distros and different bootloaders - force Slackware to generate completely new LiLo headers (ie, use Expert settings and configure this yoruself), or install Ubuntu or other distros from the command line rather than via some user-friendly automagical way. ______________Caveat_________________ Having said all of this, it seems like this whole thing was basically a freak incident stemming from a botched install of BSD. I don't think that normally the auto-configuration of bootloaders is a problem.




December 2014

S M T W T F S
 123456
78910111213
14151617181920
212223242526 27
28293031   

Recent Entries

Recent Comments

Search My Blog

BinRev is hosted by the great people at Lunarpages!