Hack and / - Break In Your Boots

New boots, new bootloaders—both take some time to get used to. In this column, find out all the uncomfortable changes in the new GRUB2 bootloader.

A few months ago, I had to replace my favorite pair of shoes: black, suede Converse One Stars (the classic style with no white rubber toe
cap, thank you). I had worn the shoes for years, but although most of the
shoe held up fine, I had completely worn down the heel. Now, I'm not one
to throw away a comfortable pair of shoes. This pair was on its
ninth or tenth Shoe-Goo repair, but it finally became hopeless.
They had to be replaced. It seemed like a simple task—after all, these shoes had been available all through my adult life, but
wouldn't you know, the moment I need another pair, Converse discontinued
the model and replaced it with a canvas version with the Chuck Taylor-esque
white rubber toe. I had to find a new shoe.

Let me tell you, once you have found the perfect sneaker, it's impossible
to find a replacement. Everything I looked at was held up to the standard
of the shoe I couldn't have. After a month or two, I finally found shoes
that were up to the task, and although I like them, I still miss my old shoes
(oh, wouldn't you know it, now that I bought a replacement, Converse
has re-released the One Stars how I like them).

I really should be used to this feeling. It seems every few years some
open-source project decides to throw away an entire codebase and start
from scratch. Although GNOME and KDE have stirred the pot the most with
this,
I've also lived through the same thing with the Enlightenment Project,
the SysV init to Upstart transition, the LILO bootloader being phased
out for GRUB, and now GRUB being replaced by GRUB2. For those of you who
thought the difference between GRUB2 and GRUB1 was “one”, you are: good
at subtraction, a bit of a smart aleck and in for a rude awakening. In
this article, I'm going to help you break in your new GRUB2 bootloader,
so hopefully some day, it will be as comfortable to you as the original GRUB.

Why?

The first question you might ask is why we need a new bootloader
at all? What is wrong with GRUB? The answer, according to the GRUB2
developers, is that the original GRUB codebase was rather old and had
become unmaintainable. The software continued to get new feature requests
(such as supporting new hardware and platforms) that ultimately were
beyond the scope of the original code, so the decision was made to scrap
it and start from scratch. Because it was a complete rewrite, the developers
decided to take the opportunity to make a clean break and redesign the
layout and syntax of the configuration files. Along with these changes,
GRUB2 has been able to add new features, such as a rescue mode, enhanced
graphical menu and splash screen support, full support for UUIDs, and
support for non-x86 platforms, such as PowerPC.

Old Boots

Before I go into how GRUB2 has changed things, I'm going to give a quick
overview of GRUB1 (or GRUB Legacy, as they are calling it now) to help
highlight the changes for those of you who might be unfamiliar with
either bootloader. GRUB (and LILO before it) has been the standard
bootloader used by the majority of Linux distributions. When you boot
your computer and see a menu that lets you choose between different
Linux kernels, or between different versions of Linux and Windows in a
dual-boot scenario, you probably are using GRUB. GRUB's job is to allow
you to choose between one or more operating systems at boot time and
then either load the respective kernel and initrd into memory and start
the rest of the boot process, or launch the boot code for some
other operating system, such as Windows.

GRUB is quite configurable and organizes itself into a few core programs
and directories:

/boot/grub/menu.lst: this is the default configuration
file for GRUB, although on some distributions it is a symlink to
/boot/grub/grub.conf. All of GRUB's configuration is in this file, and
users edit this file directly to change any GRUB options.

/usr/sbin/grub: this is the core GRUB binary that you can use (if
you learned all of the syntax) to install GRUB onto your system. The
syntax is a bit tricky though, so ultimately, other programs appeared
to help automate the process.

/usr/sbin/grub-install: this program acts as the front end to
/usr/sbin/grub and makes it much simpler to install GRUB to your hard
drive.

/usr/sbin/update-grub: this script helps automate configuration
of the menu.lst file. Instead of having to add new kernels to
menu.lst manually, you can run this script, and it will detect kernels available
on your system and build the menu.lst for you. In addition, this script
can read special configuration options in the comments of menu.lst and
further automate the process of providing rescue modes, memtest86+
and other customizations of the file.

Another great feature of GRUB is the fact that even with all of this
configuration, if you make a mistake, GRUB allows you to change essentially
any configuration option from the boot prompt. At the GRUB menu, you can
press the Esc key to change boot options on the fly.

Kyle Rankin is a director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.