Home ›

Hack and / - Break In Your Boots

Issue 197

From Issue #197
September 2010

Nov 01, 2010  By Kyle Rankin
 in
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.
New Boots

Now that you have learned (or refreshed your memory) about GRUB, you may promptly forget it, because much of what I said above has changed. For starters (and this will drive you crazy), the default key to edit GRUB2 options at boot is Shift, not Esc. Second, the main configuration file has been changed from /boot/grub/menu.lst to /boot/grub/grub.cfg. Not only has the filename changed, but also the syntax inside the file is quite different from what you'd find in menu.lst.

While I'm on the subject of syntax changes, a crucial syntax change that GRUB2 makes is in how it numbers partitions. Where in GRUB your partitions were counted starting from zero, now the count starts with one. To make it more confusing, disk devices still are being counted starting from zero. Confused yet? In short:

  • GRUB1: /dev/sda1 = (hd0,0)

  • GRUB2: /dev/sda1 = (hd0,1)

Here's a sample stanza from GRUB's menu.lst and a similar stanza from GRUB2's grub.cfg, so you can compare their syntax:

GRUB: 

title    Ubuntu karmic (development branch), kernel 2.6.31-14-generic
uuid     c7b6836f-ac57-47ed-9e7c-b16adbf8abed
kernel   /boot/vmlinuz-2.6.31-14-generic root=UUID=
         ↪c7b6836f-ac57-47ed-9e7c-b16adbf8abed ro quiet splash
initrd   /boot/initrd.img-2.6.31-14-generic
quiet

GRUB2: 

menuentry 'Ubuntu, with Linux 2.6.31-20-generic' --class ubuntu 
 ↪--class gnu-linux --class gnu --class os {
        recordfail
        insmod ext2
        set root='(hd0,2)'
        search --no-floppy --fs-uuid --set 
        ↪c7b6836f-ac57-47ed-9e7c-b16adbf8abed
        linux   /boot/vmlinuz-2.6.31-20-generic 
        ↪root=UUID=c7b6836f-ac57-47ed-9e7c-b16adbf8abed 
        ↪ro   quiet splash
        initrd  /boot/initrd.img-2.6.31-20-generic
}

Before you sit down and study the new syntax, I should point out that you are actively discouraged from editing grub.cfg directly. This file is generated from a series of scripts and configuration files I will talk about later, so any changes you make will be overwritten the next time any package updates that would trigger the GRUB2 update.

Like with GRUB, here are the core files and programs involved in GRUB2 configuration:

  • /boot/grub/grub.cfg: this is the core GRUB2 configuration file but is not to be edited directly.

  • /etc/default/grub: this is the main configuration file for end users to edit. In this file, you can configure a limited subset of GRUB2 options, such as timeouts, basic kernel boot options and whether to use a graphical console or UUIDs. Every time you make a change to this file, you must run /usr/sbin/update-grub for the changes to be reflected. Here are some sample lines from the file to give you some idea of the syntax: 

    GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

  • /etc/grub.d/: this directory contains a series of scripts that are executed in numerical order by the grub-mkconfig program and will configure different parts of grub.cfg. On a default Ubuntu Lucid install, for instance, you would find the following files: 

    $ ls /etc/grub.d/
00_header        10_linux       30_os-prober  README
05_debian_theme  20_memtest86+  40_custom

    The order in which configuration options appear in grub.cfg is governed by the order its script appears in this directory. So if, for instance, you wanted to have a different OS appear before the Linux options in the menu, you could name the script 01_otheros. Although the scripts that are currently there do a few complicated things, essentially your script needs to output the configuration information you want in the proper grub.cfg syntax, so I suppose it even could be a series of echo statements in a shell script. If you want to create a custom configuration script though, Ubuntu has provided the 40_custom script for you to use that will not risk being overwritten.

  • /usr/sbin/grub-install: like with GRUB, the GRUB2 grub-install program is the recommended way to install GRUB2 onto a device. It calls a number of other scripts that perform various system checks, device probes and everything else that's necessary to install GRUB2 to a boot device.

  • /usr/sbin/update-grub: this script still exists and is still the recommended way to update GRUB2's configuration file, but now this is a very short shell script that executes grub-mkconfig. Whenever you edit a configuration file or script, run this command with no arguments to rebuild the grub.cfg file.

  • /usr/sbin/grub-mkconfig: this program does the real heavy-lifting to build your grub.cfg file. It is the program that executes the various scripts in /etc/grub.d.

In addition to the above changes, here are a few extra things that are different in GRUB2:

  • GRUB2 no longer has stage 1.5 in the boot process.

  • On a new Ubuntu install when no other OSes are present, GRUB2 will not display a menu at boot time and will instead boot directly into the Ubuntu install.

  • To reiterate, hold Shift instead of Esc to change GRUB2 boot options.

If you are like I was when I first discovered all of these changes, right about now you are feeling like the ground has been moved out from under you. I felt much like I did when I couldn't buy a new pair of black suede One Stars. All I can hope for is that over time, like my new shoes, the uncomfortable parts of GRUB2 will break in, and I will feel comfortable with them and maybe some day even like them as much as GRUB1.

______________________

Kyle Rankin is a systems architect; and the author of DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks, and Ubuntu Hacks.

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions