Ceci est une ancienne révision du document !
New Linux flavours emerge all the time. Ubuntu, Debian, Linux Mint, Bodhi Linux, SnowLinux, antiX, … regularly come with new releases. Overwhelming! As if this wasn’t enough, most distributions offer a further choice between several pre-installed desktops and default programs. Common desktop managers include Gnome, Cinnamon, Unity, XFCE, LXDE and Enlightenment. This wealth is a joy for open source protagonists. Still, we need practical ways to be able to enjoy and compare multiple distributions. A common approach is to run a live session (from DVD or USB stick), or to run a second operating system within some mystical ‘virtual machine’, but none of these ways allow you to fully assess what the behaviour, speed and stability would be when the distro is installed on and booted directly from the hard disk of your pc! Multiple installed distributions on your hard disk to choose from, would allow you to try out different candidate distributions in a ‘real life’ situation, and over a much longer time than a live session.
Lately, I figured out an approach, and I was compelled to share that knowledge with other FCM readers. The answer is in customizing GRUB, the Grand Unified Bootloader.
When my PC boots, the first thing that appears after BIOS is a GRUB menu in which multiple installed operating systems are displayed to choose from (nine in my case). Many of us know about ‘dual booting’ Windows and one Linux distribution: it is a default option which is offered when you install Ubuntu or another Linux distribution on a Windows-only machine. After installation and restart, you will get a GRUB menu from which you can choose which operating system (OS) to boot: Ubuntu or Windows. If you don’t see the GRUB menu (e.g. you have only Ubuntu on your hard disk), press Shift during boot to unhide it. GRUB can do more for you than offering a dual-booting menu, and multibooting is what we are going to achieve in this four-parts-series! In this first part, let us discover the general purpose and behaviour of GRUB.
With GRUB, I mean version 2 (GRUB2), which is the version packaged with most Linux distributions (i.e. grub-pc package version 1.97 and later!). From Ubuntu 12.10 on, version 2.00 of grub-pc is installed.
GRUB is a bootloader, which by default will be installed on the Master Boot Record (MBR) of your hard disk. What a mouthful. The MBR is the first sector of your hard disk (512 bytes), and, as such, it is the first thing that is read from the hard disk when booting. Its contents do NOT appear within your file system(s) on the hard disk, and therefore they cannot be read by a file manager application (we don't need to, either). It is the logical place for the bootloader, which is an in-between small operating system. The BIOS transfers its control of the PC to the bootloader when booting from the hard disk. The bootloader is essentially responsible for correctly transferring the control of your machine to an operating system. Bootloaders other than GRUB exist as well, like LiLo for example.
A bootloader like GRUB contains pointers to one or more OSs on your hard disk, as each OS is installed on a separate partition of the hard disk (or another hard disk). Usually, when more than one OS is installed, GRUB offers a menu from which an OS can be selected at startup. If you don't interfere, its default selection is booted after 10 seconds. Furthermore, GRUB is able to keep track of several installed versions of the kernel in a Linux distribution (something which dual-booters will be familiar with). Each installed kernel (within one and the same OS) will appear as a separate line in the GRUB menu (or in a submenu). In this way, it is still possible to “fall back” to a previous kernel version in case things don’t work as expected with a newly installed kernel. Of course, GRUB does not store all of its information within the small MBR sector: on installation it has been configured to look for needed modules and configuration settings in the /boot/grub folder on a Linux partition.
So far we have a general idea of what GRUB is responsible for. However, starting right away by installing Linux distributions A, B, C and D on partitions 1, 2, 3 and 4 will lead to trouble in the longer term. Let’s see why.
Each time you install a new distribution, the GRUB that is already present on the MBR is overwritten because the new distribution re-installs GRUB from its own grub-pc package. This new GRUB is told to look for its configuration file grub.cfg in the /boot/grub directory of the newly installed Linux distro. No problem so far, because this configuration file is filled with pointers to all operating systems present on your hard disk. So you will eventually get an up-to-date GRUB menu after you installed your last Linux distribution (let’s assume that is distro D). Let’s also suppose you have done some final tuning of this GRUB configuration to make the GRUB menu look awesome (e.g. with a nice background, beautiful text colours, default OS preset, etc.). Will things work as you would like? Yes – for now. However, the grub.cfg file that GRUB (on the MBR) relies on, is controlled solely by distribution D (which you installed on partition 4). Will a kernel update in distribution C be reflected in the GRUB menu? No, because distribution D is unaware of that kernel update. What happens when the grub-pc package is updated in distro A, B or C – or when you replace A with a new distro E? The MBR will be overwritten with GRUB… from distro A (or E), B or C (which does not refer to /boot/grub/grub.cfg on partition 4 but to the one on partition 1, 2 or 3). So… goodbye nice background and other tunings that were present in the old grub configuration file! What if you replace distro D and overwrite GRUB? Same thing.
To conclude, it is only by actively updating the grub.cfg from within distro D - by running the 'sudo update-grub' command - that kernel or OS changes elsewhere on your hard disk will be detected and reflected in the GRUB menu. So that makes you very dependent on distro D. Not an ideal situation when you like to change your Linux installations every once in a while.
My purpose with this article series is to give you a better understanding of how GRUB works, and to demonstrate a more advanced option than a GRUB installation governed by one of the Linux distributions: we will achieve an independent bootloader on the MBR. By that I mean a GRUB installation which will not be affected by your replacements of one Linux distribution by another, and over which you have control yourself!
Next time, we will dive into some internals of GRUB!