The grub {{Filename|menu.lst}} provides for a convenient way to add a number of entries with [http://www.kernel.org/doc/Documentation/kernel-parameters.txt extended kernel parameters] to configure all sorts of advanced settings to enable you to quickly and conveniently boot into your existing system with varying levels of debugging output. It's very easy and useful to create several levels of debugging just by adding additional entries to your grub configuration. And if you ever have issues or problems down the road due to a power-failure or hardware failure, it can save you hours of trouble, and of course nothing can beat debugging output when it comes to learning about your system.

+

+

===Light Debug===

+

A quick way to see more verbose messages on your console is to bootup your normal grub entry after appending '''verbose''' to the kernel line. This simple word added to your kernel line turns on more logging thanks to the {{Filename|/etc/rc.sysinit}} file, which at the top of the file runs:

+

if /bin/grep -q " verbose" /proc/cmdline; then

+

/bin/dmesg -n 8

+

+

Very simple way to get a bit more messages and debug output in your logs.

+

+

title Arch Linux DEBUG Light

+

kernel /vmlinuz26 root=/dev/disk/by-label/ROOT ro rootwait verbose

+

initrd /kernel26.img

+

+

+

===Medium Debug===

+

This example {{Filename|menu.lst}} entry turns on real logging that is set by the kernel and not in an init script. Adding the '''debug''' kernel parameter to your kernel line is recognized by a lot of linux internals and enables quite a bit of debugging compared to the default.

An even more impressive kernel parameter is the '''ignore_loglevel''', which causes the system to ignore any loglevel and keeps the internal loglevel at the maximum debugging level, basically rendering dmesg unable to lower the debug level.

If the "Heavy Debug" seemed like a lot of output, thats about 1/2 of the logging that occurs with this example. This does a couple things, it uses the '''earlyprintk''' parameter to setup your kernel for "early" "printing" of messages to your "vga" screen. The ''',keep''' just lets it stay on the screen longer. This will let you see logs that normally are hidden due to the boot-up process.

+

This also changes the log buffer length to 10MB, and also instructs that any fatal signals be printed with '''print_fatal_signals'''. The last one, '''sched_debug''', you can look up in the very excellent kernel documentation on [http://www.kernel.org/doc/Documentation/kernel-parameters.txt kernel parameters].

The first few debugging examples showed some really nice kernel parameters to turn on really verbose debugging. This kind of debugging is absolutely critical if you want to max out your system or just learn more about what is going on behind the scenes. But there is a final trick that is my favorite, it's the ability to set both environment variables, and more importantly, module parameters at boot.

+

+

As an example, here is the boot line that I am using at the moment on an older Dell Desktop, just to illustrate module parameters and environment vars.

Since it's low on both memory and CPU, I disable ipv6. I also turn on kernel modesetting for the i915 video card, set my terminal to be xterm-256color, and boot straight into [Xorg X]. This lets me use a very optimized arch-linux configuration, amazing how fast thanks to using [slim] as the login manager, ratpoison as my window manager, and terminal with [[tmux]] as my login shell, all from boot, as the pstree shows (plus synergy!).

That kind of optimized system is only possible if you first can figure out your system, by debugging both the kernel as previously illustrated, debugging the init process, and most importantly, by debugging the modules enabled for your system's hardware/firmware/software. Debugging modules is challenging but worth the effort, and then you are able to do some truly insane debugging from grub like the following example, note that the actual grub entry is all on one line, but I split it into 4 lines so you could see it all. This basically turns on every module on this little Dell desktop to be at the absolute max debug level. There is so much logging when I boot this that the system grinds to a halt and is slower than a TI-89 calculator.

A couple key items from that grub entry are '''sysrq_always_enabled''' which forces on the sysrq magic, which really is a lifesaver when debugging at this level as your machine will freeze/stop-responding sometimes and it's nice to use sysrq to kill all tasks, change the loglevel, unmount all filesystems, or do a hard reboot. Another key parameter is the '''initcall_debug''', which debugs the init process in excruciating detail. Very useful at times. The last parametery I find very useful is the '''udev.log_priority=8'''.

+

+

====Break Into Init====

+

For instance, If you add '''break=y''' to your kernel cmdline, init will pause early in the boot process (after loading modules) and launch an interactive sh shell which can be used for troubleshooting purposes. (Normal boot continues after logout.) This is very similar to the shell that shows up if your computer gets turned off before it is able to shutdown properly. But using this parameter lets you enter into this mode differently at will.

+

+

+

====Debugging init====

+

This awesome parameter '''udev.log_priority=8''' does the same thing as editing the file {{Filename|/etc/udev/udev.conf}} except it executes earlier. If you want to know your hardware, that is the key parameter right there. Another trick is if you change the {{Filename|/etc/udev/udev.conf}} and then add that file as a file to be included in your mkinitcpio.conf, your initrd environment will also have incredible debugging once you remake your initrd, which on arch is as easy as

+

{{Command|sudo pacman -Syf kernel26}}

+

+

Debugging udev is key because the initrd performs a root change at the end of its run to usually launch a program like /sbin/init as part of a chroot, and unless the new file system has a valid /dev directory, udev must be initialized before invoking chroot in order to provide {{Filename|/dev/console}}.

+

exec chroot . /sbin/init <dev/console >dev/console 2>&1

+

+

So basically, you aren't able to view the logs that are generated before /dev/console is initialized by udev or by a special initrd you compiled yourself. One method the kernel developers use to be able to still get the log messages generated before /dev/console is available is to provide an alternative console that you can enable or disable from grub.

+

+

+

====Net Console====

+

If you read through the kernel documentation regarding debugging, you will hear about Netconsole, which can be loaded from the kernel line in GRUB, compiled into your kernel, or loaded at runtime as a module. Having a netconsole entry in your {{Filename|menu.lst}} is most excellent for debugging slower computers like old laptops or thin-clients. It's easy to use. Just setup a 2nd computer (running arch) to accept syslog requests on a remote port, very fast and quick to do on arch-linux, 1 line to syslog.conf. Then you could use a log-color-parser like ccze to view all syslog logs, or just tail your everything.log. Then on your laptop, boot up and select the netconsole entry from the grub menu, and you will start seeing as much logging as you want on your syslog system. This logging lets you view even earlier log output than is available with the earlyprintk=vga kernel parameter, as netconsole is used by kernel hackers and developers, so it's very powerful.

GNU GRUB is a multiboot bootloader. It was derived from GRUB, the GRand Unified Bootloader, which was originally designed and implemented by Erich Stefan Boleyn.

Briefly, the bootloader is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.

Currently, GRUB is the de facto standard bootloader of Linux, and is expected to be superseded by GRUB2 in the near future. When this happens, "GRUB" will become "GRUB Legacy".

Finding GRUB's root

GRUB must be told where its files reside on the system, since multiple instances may exist (i.e., in multi-boot environments). GRUB files always reside under Template:Filename, which may be on a dedicated partition.

Hard disks are defined as (hdX); this also refers to any USB storage devices.

Device and partitioning numbering begin at zero. For example, the first hard disk recognized in the BIOS will be defined as (hd0). The second device will be called (hd1). This also applies to partitions. So, the second partition on the first hard disk will be defined as (hd0,1).

Dual booting with Windows

Add the following to the end of your Template:Filename (assuming that your Windows partition is on the first partition of the first drive):

title Windows
rootnoverify (hd0,0)
makeactive #if you use Windows7 this line should be commented out
chainloader +1

Note: Windows 2000 and later versions do NOT need to be on the first partition to boot (contrary to popular belief). If the Windows partition changes (i.e. if you add a partition before the Windows partition), you will need to edit the Windows Template:Filename file to reflect the change (see this article for details on how to do that).

If Windows is located on another hard disk, the map command must be used. This will make your Windows install think it is actually on the first drive. Assuming that your Windows partition is on the first partition of the second drive:

title Windows
map (hd0) (hd1)
map (hd1) (hd0)
rootnoverify (hd1,0)
makeactive #if you use Windows7 this line should be commented out
chainloader +1

Dual booting with GNU/Linux

This can be done the same way that an Arch Linux install is defined. For example:

To facilitate system maintenance, the Template:Codeline or Template:Codeline command should be used to boot another Linux distribution that provides an "automagic" GRUB configuration mechanism (e.g. Debian, Ubuntu, openSUSE). This allows the distribution to manage its own Template:Filename and boot options.

The Template:Codeline command will load another bootloader (rather than a kernel image); useful if another bootloader is installed in a partition's boot sector (GRUB, for example). This allows one to install a "main" instance of GRUB to the MBR and distribution-specific instances of GRUB to each partition boot record (PBR).

The Template:Codeline command will instruct the currently running GRUB instance to load the specified configuration file. This can be used to load another distribution's Template:Filename without a separate GRUB installation. The caveat of this approach is that other Template:Filename may not be compatible with the installed version of GRUB; some distributions heavily patch their versions of GRUB.

For example, GRUB is to be installed to the MBR and some other bootloader (be it GRUB or LILO) is already installed to the boot sector of Template:Codeline.

Selecting this entry at boot will load the other distribution's Grub2 menu.

Bootloader installation

Manual recovery of GRUB libs

The Template:Filename files are expected to be in Template:Filename, which may not be the case if the bootloader was not installed during system installation or if the partition/filesystem was damaged, accidentally deleted, etc.

Manually copy the grub libs like so:

# cp -a /usr/lib/grub/i386-pc/* /boot/grub

Note: Don't forget to mount the system's boot partition if your setup uses a separate one! The above assumes that either the boot partition resides on the root filesystem or is mounted to /boot on the root file system!

General notes about bootloader installation

GRUB may be installed from a separate medium (e.g. a LiveCD), or directly from a running Arch install. The GRUB bootloader is seldom required to be reinstalled and installation is not necessary when:

GRUB must be installed on the MBR (first sector of the hard disk), or the first partition of the first storage device to be recognized by most BIOS's. To allow individual distributions the ability to manage their own GRUB menus, multiple instances of GRUB can be used, see #chainloader and configfile.

Installing the GRUB bootloader may need to be done from within a Template:Codelineed environment (i.e. from installed environment via a separate medium) for cases like RAID configurations or if you forgot/broke your GRUB installation. You will need to Change Root from a LiveCD or another Linux installation to do so.

Tip: The GRUB shell also supports tab-completion. If you type 'root (hd' then press Tab twice you will see the available storage devices, this can also be done for partitions. Tab-completion also works from the GRUB boot menu. If there is an error in your configuration file you can edit in the boot menu and use tab-completion to help find devices and partitions. See #Edit GRUB entries in the boot menu.

Alternate method (grub-install)

Tip: This procedure is known to be less reliable, the recommended method is to use the GRUB shell.

Use the Template:Codeline command followed by the location to install the bootloader. For example to install the GRUB bootloader to the MBR of the first drive:

# grub-install /dev/sda

GRUB will indicate whether it successfully installs. If it does not, you will have to use the GRUB shell method.

Tips and tricks

Additional configuration notes.

Graphical boot

For those desiring eye candy, see grub-gfx. GRUB2 also offers enhanced graphical capabilities, such as background images and bitmap fonts.

Framebuffer resolution

One can use the resolution given in the Template:Filename, but you might want to use your LCD wide-screen at its full native resolution. Here is what you can do to achieve this:

On Wikipedia, there is a list of extended framebuffer resolutions (i.e. beyond the ones in the VBE standard). But, for example, the one I want to use for 1440x900 (Template:Codeline) does not work. This is because the graphic card manufacturers are free to choose any number they wish, as this is not part of the VBE 3 standard. This is why these codes change from one card to the other (possibly even for the same manufacturer).

So instead of using that table, you can use one of the tools mentioned below to get the correct code:

Note: vbetest gives you VESA mode to which we need to add 512 to get the correct value to use in kernel option line. While hwinfo gives you directly the correct value needed by the kernel.

GRUB recognized value

This is an easy way to find the resolution code using only GRUB itself.

On the kernel line, specify that the kernel should ask you which mode to use.

kernel /vmlinuz26 root=/dev/sda1 ro vga=ask

Now reboot. GRUB will now present a list of suitable codes to use and the option to scan for even more.

You can pick the code you would like to use (don't forget it, it is needed for the next step) and boot using it.

The number you have picked here is the hexadecimal number, in order to use it at the kernel line you can transform it into a decimal number.

Now replace ask in the kernel line with the correct one you have picked.

e.g. the kernel line for [369] 1680x1050x32 would be:

kernel /vmlinuz26 root=/dev/sda1 ro vga=873

Naming by label

If you alter (or plan to alter) partition sizes from time to time, you might want to consider defining your drive/partitions by a label. You can label ext2, ext3, ext4 partitions by:

e2label </dev/drive|partition> label

The label name can be up to 16 characters long but cannot have spaces for GRUB to understand it. Then define it in your Template:Filename:

kernel /boot/vmlinuz26 root=/dev/disk/by-label/Arch_Linux ro

Password protection

You can enable password protection in the GRUB configuration file for operating systems you wish to have protected. Bootloader password protection may be desired if your BIOS lacks such functionality and you need the extra security.

Warning: If you disable booting from other boot devices (like a CD drive) in the BIOS's settings and then password protect all your operating system entries, it could be difficult to re-enable booting back into the operating systems if the password is forgotten.

Restart with named boot choice

If you realize that you often need to switch to some other non-default OS (e.g. Windows) having to reboot and wait for the GRUB menu to appear is tedious. GRUB offers a way to record your OS choice when restarting instead of waiting for the menu, by designating a temporary new default which will be reset as soon as it has been used.

Arch is the default (0). We want to restart in to Windows. Change Template:Codeline to Template:Codeline -- this will record the current default in a Template:Filename file in the GRUB directory whenever the savedefault command is used. Now add the line Template:Codeline to the bottom of the Windows entry. Whenever Windows is booted, it will reset the default to Arch, thus making changing the default to Windows temporary.

Now all that is needed is a way to easily change the default manually. This can be accomplished using the command Template:Codeline. So, to reboot into Windows, enter the following command:

LILO and GRUB interaction

as some tasks (e.g. kernel compilation using Template:Codeline) will make a LILO call, and LILO will then be installed over GRUB. LILO may have been included in your base system, depending on your installer media version and whether you selected/deselected it during the package selection stage.

Note: pacman -R lilo will not remove LILO from the MBR if it has been installed there; it will merely remove the lilo package. The LILO bootloader installed to the MBR will be overwritten when GRUB (or another bootloader) is installed over it.

Now you should be able to restart your computer with the disk in the drive and it should boot to GRUB. Make sure that your floppy disk is set to have higher priority than your hard drive when booting in your BIOS first, of course.

Advanced Debugging

The grub Template:Filename provides for a convenient way to add a number of entries with extended kernel parameters to configure all sorts of advanced settings to enable you to quickly and conveniently boot into your existing system with varying levels of debugging output. It's very easy and useful to create several levels of debugging just by adding additional entries to your grub configuration. And if you ever have issues or problems down the road due to a power-failure or hardware failure, it can save you hours of trouble, and of course nothing can beat debugging output when it comes to learning about your system.

Light Debug

A quick way to see more verbose messages on your console is to bootup your normal grub entry after appending verbose to the kernel line. This simple word added to your kernel line turns on more logging thanks to the Template:Filename file, which at the top of the file runs:

if /bin/grep -q " verbose" /proc/cmdline; then
/bin/dmesg -n 8

Very simple way to get a bit more messages and debug output in your logs.

Medium Debug

This example Template:Filename entry turns on real logging that is set by the kernel and not in an init script. Adding the debug kernel parameter to your kernel line is recognized by a lot of linux internals and enables quite a bit of debugging compared to the default.

Heavy Debug

An even more impressive kernel parameter is the ignore_loglevel, which causes the system to ignore any loglevel and keeps the internal loglevel at the maximum debugging level, basically rendering dmesg unable to lower the debug level.

Extreme Debug

If the "Heavy Debug" seemed like a lot of output, thats about 1/2 of the logging that occurs with this example. This does a couple things, it uses the earlyprintk parameter to setup your kernel for "early" "printing" of messages to your "vga" screen. The ,keep just lets it stay on the screen longer. This will let you see logs that normally are hidden due to the boot-up process.
This also changes the log buffer length to 10MB, and also instructs that any fatal signals be printed with print_fatal_signals. The last one, sched_debug, you can look up in the very excellent kernel documentation on kernel parameters.

Insane Debug

The first few debugging examples showed some really nice kernel parameters to turn on really verbose debugging. This kind of debugging is absolutely critical if you want to max out your system or just learn more about what is going on behind the scenes. But there is a final trick that is my favorite, it's the ability to set both environment variables, and more importantly, module parameters at boot.

As an example, here is the boot line that I am using at the moment on an older Dell Desktop, just to illustrate module parameters and environment vars.

Since it's low on both memory and CPU, I disable ipv6. I also turn on kernel modesetting for the i915 video card, set my terminal to be xterm-256color, and boot straight into [Xorg X]. This lets me use a very optimized arch-linux configuration, amazing how fast thanks to using [slim] as the login manager, ratpoison as my window manager, and terminal with tmux as my login shell, all from boot, as the pstree shows (plus synergy!).

That kind of optimized system is only possible if you first can figure out your system, by debugging both the kernel as previously illustrated, debugging the init process, and most importantly, by debugging the modules enabled for your system's hardware/firmware/software. Debugging modules is challenging but worth the effort, and then you are able to do some truly insane debugging from grub like the following example, note that the actual grub entry is all on one line, but I split it into 4 lines so you could see it all. This basically turns on every module on this little Dell desktop to be at the absolute max debug level. There is so much logging when I boot this that the system grinds to a halt and is slower than a TI-89 calculator.

A couple key items from that grub entry are sysrq_always_enabled which forces on the sysrq magic, which really is a lifesaver when debugging at this level as your machine will freeze/stop-responding sometimes and it's nice to use sysrq to kill all tasks, change the loglevel, unmount all filesystems, or do a hard reboot. Another key parameter is the initcall_debug, which debugs the init process in excruciating detail. Very useful at times. The last parametery I find very useful is the udev.log_priority=8.

Break Into Init

For instance, If you add break=y to your kernel cmdline, init will pause early in the boot process (after loading modules) and launch an interactive sh shell which can be used for troubleshooting purposes. (Normal boot continues after logout.) This is very similar to the shell that shows up if your computer gets turned off before it is able to shutdown properly. But using this parameter lets you enter into this mode differently at will.

Debugging init

This awesome parameter udev.log_priority=8 does the same thing as editing the file Template:Filename except it executes earlier. If you want to know your hardware, that is the key parameter right there. Another trick is if you change the Template:Filename and then add that file as a file to be included in your mkinitcpio.conf, your initrd environment will also have incredible debugging once you remake your initrd, which on arch is as easy as

Debugging udev is key because the initrd performs a root change at the end of its run to usually launch a program like /sbin/init as part of a chroot, and unless the new file system has a valid /dev directory, udev must be initialized before invoking chroot in order to provide Template:Filename.

exec chroot . /sbin/init <dev/console >dev/console 2>&1

So basically, you aren't able to view the logs that are generated before /dev/console is initialized by udev or by a special initrd you compiled yourself. One method the kernel developers use to be able to still get the log messages generated before /dev/console is available is to provide an alternative console that you can enable or disable from grub.

Net Console

If you read through the kernel documentation regarding debugging, you will hear about Netconsole, which can be loaded from the kernel line in GRUB, compiled into your kernel, or loaded at runtime as a module. Having a netconsole entry in your Template:Filename is most excellent for debugging slower computers like old laptops or thin-clients. It's easy to use. Just setup a 2nd computer (running arch) to accept syslog requests on a remote port, very fast and quick to do on arch-linux, 1 line to syslog.conf. Then you could use a log-color-parser like ccze to view all syslog logs, or just tail your everything.log. Then on your laptop, boot up and select the netconsole entry from the grub menu, and you will start seeing as much logging as you want on your syslog system. This logging lets you view even earlier log output than is available with the earlyprintk=vga kernel parameter, as netconsole is used by kernel hackers and developers, so it's very powerful.

Troubleshooting

GRUB Error 17

If your partition table gets messed up, an unpleasant "GRUB error 17" message might be the only thing that greets you on your next reboot. There are a number of reasons why the partition table could get messed up. Commonly, users who manipulate their partitions with GParted -- particularly logical drives -- can cause the order of the partitions to change. For example, you delete Template:Filename and resize Template:Filename, then finally re-create what used to be Template:Filename only now it appears at the bottom of the list, Template:Filename for example. Although the physical order of the partitions/logical drives has not changed, the order in which they are recognized has changed.

Fixing the partition table is easy. Boot from your Arch CD/DVD/USB, login as root and fix the partition table:

# fdisk /dev/sda

Once in disk, enter e[x]tra/expert mode, [f]ix the partition order, then [w]rite the table and exit.

Accidental install to a Windows partition

If you accidentally install GRUB to a Windows partition, GRUB will write some information to the boot sector of the partition, erasing the reference to the Windows bootloader. (This is true for NTLDR the bootloader for Windows XP and earlier, unsure about later versions).

To fix this you'll need to use the Windows Recovery Console for your Windows release. Because many computer manufacturers do not include this with their product (many choose to use a recovery partition) Microsoft has made them available for download. If you use XP, look at this page to be able to turn the floppy disks to a Recovery CD. Boot the Recovery CD (or enable Windows Recovery mode) and run Template:Codeline to repair the partition boot sector. After this, you will have to install GRUB again---this time, to the MBR, not to the Windows partition---to boot Linux.

Edit GRUB entries in the boot menu

Once you have selected and entry in the boot menu, you can edit it by pressing key e. Use tab-completion if you need to to discover devices then Esc to exit. Then you can try to boot by pressing b. Note: these settings will not be saved.

device.map error

to force GRUB to recheck the device map, even if it already exists. This may be necessary after resizing partitions or adding/removing drives.

KDE reboot pull-down menu fails

If you've opened a sub-menu with the list of all operating systems configured in GRUB, selected one, and upon restart, you still booted your default OS, then you might want to check if you have the line:

GRUB fails to find or install to any virtio /dev/vd* or other non-BIOS devices

I had trouble installing GRUB while installing ArchLinux in an virtual KVM machine using a virtio device for hard drive. To install GRUB, I figured out the following:
Enter a virtual console by typing ctrl+alt+f2 or any other f-key for a free virtual console.
Assuming your root file system is mounted in the folder /mnt and boot file system is either mounted or stored in the folder /mnt/boot

1. Assure that all needed GRUB files is present in your boot directory(assuming mounted in /mnt/boot folder), by issuing the command:

# ls /mnt/boot/grub

2. If the grub folder allready contains all the needed files, jump to step 3. Otherwise, do the following commands(replacing /mnt, your_kernel and your_initrd with the real paths and file names). You should also have the menu.lst file written to this folder: