Boot with GRUB
To see how GRUB may be used to boot a multitude of different operating systems, consider this example setup:
First Hard Disk (SCSI, Linux /dev/sda): 1st primary partition: Win982nd primary partition: Linux-Slackware3rd primary partition: Linux-Debian4th primary partition: Linux SwapSecond Hard Disk (SCSI, Linux /dev/sdb)1st primary partition: FreeBSD2nd primary partition: OpenBSD3rd primary partition: BeOS
Note that although GRUB and Linux are capable of dealing with installations in extended partitions, here we show a preference for using primary partitions whenever possible. Filesystems in primary partitions are often mountable by other operating systems, whereas cross-OS mounting filesystems in extended partitions is often not supported.
This system has two hard disks with six different operating systems using seven partitions. As you probably know, each OS has its own nomenclature for naming devices and partitions. For example, the Slackware installation would be known to Linux as /dev/sda2 (with swap on /dev/sda4), while FreeBSD would recognize its filesystem on /dev/da1s1a. Alternatively, if the system were configured with IDE hard disks, Slackware would be on /dev/hda2, and FreeBSD would refer to its root directory on /dev/ad1s1a. You get large helpings of this alphabet soup whenever maintaining any multiboot setup.
Since GRUB also needs to be capable of loading any of these systems, it has its own OS-neutral naming conventions for referring to devices. Hard disks are all hd, floppy disks are fd, device numbering starts from zero, partition numbering starts from zero and complete device names are enclosed in parentheses.
With these naming rules, the floppy disk is (fd0), the Win98 partition is (hd0,0), and GRUB recognizes the Slackware and Debian partitions respectively as (hd0,1) for slackware and (hd0,2) for debian.
The BSDs further subdivide their own partitions (or “slices” in BSD terms), and GRUB would refer to the root mount for the FreeBSD system on (hd1,0,a).
Okay, ready to give GRUB a taste? Slide the GRUB floppy in the drive and reboot your system (with your system's BIOS configured to boot from A: drive). You should see GRUB's terse boot messages and then find yourself in the GRUB command-line environment as shown in Figure 1.
To start, let's boot Slackware. Enter the following commands at the grub prompt:
grub> root (hd0,1) grub> kernel /vmlinuz root=/dev/sda2 ro vga=791 grub> boot
Badda-bing, badda-boom, that postage-stamp-sized Tux appears in the upper-left corner of your screen (yes, Slackware is configured to use the framebuffer device), and Linux bootstraps its jolly way into glorious being.
Another example. Reboot the system again with the GRUB floppy, and enter the following commands at the grub prompt:
grub> rootnoverify (hd0,0) grub> makeactive grub> chainloader +1 grub> boot
Now your screen turns into a vague blue cloud, and you think you have made some horrible mistake. Then you realize it's only Windows and you remind yourself to expunge this partition one day soon.
Let's take a closer look at these examples. In the Slackware boot, we first used the GRUB root command to specify the device for GRUB to access. If the device has a filesystem recognized by GRUB (that is, one of ext2fs, reiser, ffs, etc.), it attempts to mount it and get its partition information, then reports its success following the command. Thus, you would see the following command/response dialog on your screen:
grub> root (hd0,1) Filesystem type is ext2fs, partition type 0x83
Next, we used the GRUB kernel command to specify the boot image for GRUB to load. The argument to the kernel command is the filename of the boot image relative to the device specified by the root command above. The kernel image file can also be specified in explicit (device)/filename terms as follows:
grub> kernel (hd0,1)/vmlinuzThe kernel command gives you great flexibility for specifying the boot image you wish to load. For example, if we saved a previous version of a kernel to the file /vmlinuz.old, we could specify it with this command (which shows GRUB's response):
grub> kernel /vmlinuz.old root=/dev/sda2 ro vga=ask [Linux-bzImage, setup=0xe00, size=0xfad30]The arguments following the name of the boot image are passed to the target kernel and aren't related to GRUB. For Linux, these kernel arguments are pretty much what you would specify them to be in lilo.conf. In our example, we tell the kernel what device to mount for the root partition (root=/dev/sda2 ro), using the device nomenclature expected by Linux. Note here that we also use the ro flag to mount the root filesystem read-only initially while it performs its filesystem check. The other kernel argument in our example simply demonstrates setting another kernel variable (vga=791) to use a particular vga mode for the framebuffer display.
Finally, the last command is grub> boot. The kernel image specified is now loaded and sent rolling down the royal road to bootdom.
The second example, using Win98, demonstrates the use of GRUB's chain-loading mechanism. This method of booting loads the target OS's own boot-chain-loader rather than a kernel image of the OS. In this instance, we specified:
grub> rootnoverify (hd0,0) grub> chainloader +1
First, the rootnoverify command is for OS filesystems not specifically recognized by GRUB, so that GRUB will not try to mount the partition. Next, the chainloader command will use the first sector of the partition of device (hd0,0) and attempt to boot whatever it finds there. This is a common means of booting OSes that install their own boot loaders in the first sector of the partition where they are installed (this is sometimes called the partition boot sector or PBR).
Finally, the makeactive command sets the active flag in the partition table for the device specified by the root command, as some operating systems, like Win98, require.
The GRUB command line is easy and fun, and you should boot the different OSes on your system a few times to get the hang of it. While you are testing, be sure to keep any notes specific to getting your particular kernels successfully loaded. This information will be useful later when you configure the menu system of GRUB to perform these command-line steps automatically.
But before we leave the command line, here are a few more GRUB commands to look at.
The help command will display a list of the 40 or so commands available in GRUB. Typing the name a particular command after help will produce on-line help for that particular command. So grub> help kernel will tell you all about using the kernel command.
The cat command can be used to view the contents of a file. For example, grub> cat (hd0,2)/etc/fstab will show the contents of the /etc/fstab file in the Debian installation. This is a very handy way of pulling out system configuration information if your normal boot loader gets whacked. Note also as you are using the GRUB command line that, like bash, up and down arrows will scroll through command history, and a tab will complete the name of a GRUB command or filename.
Finally, you can call up a specific menu interface with the configfile command as in:
grub> configfile (fd0)/boot/grub/menu.lst
This will switch GRUB into its menu mode with an interface defined by the file, menu.lst. We haven't created that file yet, but—look out, segue coming!—that's exactly what we will do next.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide