Boot with GRUB
By this time you may be thinking, “Okay, GRUB has got it goin' on. But do I have to keep booting from this lame floppy all the time?” Of course not. Booting from floppy is for weenies.
The operation for installing GRUB on the master boot record of your hard disk is similar to the creation of a GRUB floppy. The one difference is that our floppy has all the resources GRUB needs in one place. That is, the boot image, support and configuration files are all on the floppy device MBR and /boot/grub/ directory. In a hard disk setup, you can choose where you want these resources to be.
For example, you could set up a /boot/grub directory on the first partition of your first hard disk and copy all GRUB's files into it as we did in our floppy setup. In our demonstration system, this would be the Win98 partition, and you may choose to do it that way if you want. But you can also set up the /boot/grub directory up in any device/partition on your machine with a filesystem supported by GRUB. In practice it is usually best to install this support directory in your most frequently used and/or most stable partition; that is, one that you aren't reinstalling all the time.
For this example, we will use the Slackware partition since this stays pretty stable, and I tend to do more tracking and installations in the Debian system. Once this decision is made, everything else is simple. First, boot into Slackware, create the /boot/grub directory and copy GRUB's files into it (these are all the files that the GRUB build installed in the /usr/local/share/grub/i386-pc directory). Make sure to put your handcrafted menu.lst configuration file in here, too.
Next, start GRUB, either with the grub executable you built in Linux or by rebooting with the GRUB floppy. If GRUB starts in menu mode, press c to go to command-line mode. Enter the following commands at the grub prompt:
grub> root (hd0,1) grub> setup (hd0) grub> quit
You're done. Your system is now fully GRUB'd, installed in the MBR of your hard disk. Type reboot as root (or take the floppy out and jab the keyboard with the old three-prong) and watch just how fast GRUB comes up now!
A few words of explanation about these installation commands. The first, root (hd0,1), tells GRUB to mount this device, in this case the partition with the Slackware installation. All files will now be relative to this device, so the GRUB installer will know to look for its support files in the /boot/grub directory we created in the Slackware partition.
The second command, setup (hd0), is a simplified front end to GRUB's install command. Note in particular that we specify the device as (hd0) and not (hd0,0). Device (hd0) results in GRUB's installation to the master boot record, which is what we want. If we had instead used (hd0,0), GRUB would be installed to the boot sector of the first partition, rather than the MBR. The difference is crucial; your technical writer makes mistakes like this so you don't have to. While each partition can have a boot sector, your hard disk will have only one master boot record the BIOS loads every time you start your machine. Unless you are doing some kind of funky boot-chaining, like using LILO to boot GRUB, you will usually want to install GRUB in the master boot record.
When GRUB installs itself on a device, it first copies a small piece of itself to the MBR, which it calls stage1. Then it follows stage1 with just enough information about where to find the rest of GRUB. In our example, GRUB will put stage1 in the MBR, followed by a blocklist that points to the Slackware partition. GRUB will then find the rest of what it needs (its stage2 files) in the /boot/grub directory.
To check this setup, just edit the menu configuration file in Slackware's /boot/grub/menu.lst at any time. Any changes will be reflected in the next boot.
If you should foul up the hard disk installation somehow or want to uninstall GRUB from your system, here's what you need to know.
First, if you ever want to clean your MBR from whatever is installed there, the canonical method is to use the fdisk program from an MS-DOS boot floppy:
A:> FDISK /MBR
Of course, this isn't necessary if you just want to go back to LILO as your system's boot manager. In that case, simply make sure your /etc/lilo.conf file has a line that reads boot=/dev/hda. Then, when the rest of the lilo.conf file is the way you want, just rerun LILO. This will put LILO back on the MBR of your system.
If you install GRUB in the boot sector of a partition, instead of the MBR (such as specifying setup (hd0,0) instead of setup (hd0)), you may need to reinstall that OS's boot loader. In the case of DOS/Windows, this means running the sys command from your DOS/Windows boot floppy: A:> SYS C:.
If, this is a Linux partition, it is again effective to rerun LILO, where /etc/lilo.conf has a line in the boot stanza that reads root=/dev/hda1.
In general, most OSes will have a way to reinstall their partition's boot sector without doing a full reinstallation from scratch. (For FreeBSD, see boot0cfg(8); for OpenBSD, see installboot(8).)
In practice, especially if you followed through on the GRUB floppy examples, you should find that GRUB itself is one of the best rescue and system recovery tools in your toolkit. For example, if you have ever made a screwup in your lilo.conf file, you know you can be in for some major pain if your system won't boot. With GRUB, you always have a miniature, self-contained operating system that can recognize and mount different filesystems, find files, locate kernels and boot them, bringing your system back to life so you can work on it. At times like these, GRUB can save your bacon.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- 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