View Revisions of Installing GRUB on a Hard Disk Image File

Compare:	Current Version: 23-Feb-10 11:55 Version 1: 04-Feb-09 19:32 (should be the newer of the two)
To:	Current Version: 23-Feb-10 11:55 Version 1: 04-Feb-09 19:32 (older)

Key: Unchanged text, New text, Deleted text

h2. Introduction

"GRUB":http://www.gnu.org/software/grub/ is the GRand Unified Bootloader. For those unfamiliar, a bootloader is a critical piece of software used when a computer turns on. Its job is to load an operating system. The bootloader resides on a disk of some sort (floppy, hard) and is called by the BIOS, which is the real low-level program that runs on startup. GRUB is installed at a specific location on these devices.

Image files are byte-for-byte representations of block devices, such as a hard disk or floppy disk. They can be used for a variety of things, such as backup, offline investigation, or virtual machines. I was using the latter (specifically, "Bochs":http://bochs.sourceforge.net/ and "KVM":http://kvm.qumranet.com/). These programs act like a computer within a computer, and take an image file to be the disk for the virtual machine.

How do these come together? When building an image file from scratch, I wanted to install GRUB on it. There are a lot of "resources":http://sig9.com/bochs-grub about how to install GRUB on a floppy image or on a real HDD, but not on a HDD image. Perhaps this info is already out there, but since I didn't find it, I figured I'd tell you all what klueska and I came up with.

h2. Details

The following was done on a regular Linux box. Use root/sudo when you need to. Normally, I'll explain what I'll do, and then show the commands I used to do it.

h3. Creating the Image

This will create an 8MB image. Use whatever size you want. These values will result in one cylinder (based on the old sector/cylinder/head sizing). Fdisk complained on smaller images, so YMMV. I have a folder called mnt/ in my current directory, which is where I store both the images and the image mount point.

bc..
dd if=/dev/zero of=mnt/hdd.img bs=512 count=16065

p.

This creates a loopback device that connects to the image file. This helps some utilities that are expecting to work with a device instead of a file. For instance, fdisk was a little happier with this.

bc..
losetup /dev/loop1 mnt/hdd.img

p.

Fdisk the image, just like it's a regular block device. The easiest thing is to just create one Linux primary partition.

bc..
fdisk /dev/loop1

p.

Okay, enough with the slow stuff; it's time to put your "daddy pants" on. Here's the problem. You need to make a file system on that partition, but you do not have a device that points to just that partition, like you would for a normal hard drive. You only have the loopback device, which points to the whole image. It's like you only have /dev/hda, and not /dev/hda1. What to do? Create another loopback device, and have the device start from a certain offset within the image.

This determines the offset, in sectors, for the beginning of the partition. Then multiply the sector offset by 512, since losetup offsets by bytes.

bc..
fdisk -ul /dev/loop1

p.

This will have us point loop2 to the partition on the disk, as explained in more detail "here":http://web2.
This will have us point loop2 to the partition on the disk (if there is only one partition), as explained in more detail "here":http://web2.
clarkson.edu/projects/itl/honeypot/ddtutorial.txt. Then we simply make a filesystem on it.

bc..
losetup -o 32256 /dev/loop2 /dev/loop1
mkfs /dev/loop2

p.

If you have multiple partitions, you will need to tell @losetup@ how far to go into the target with the @--sizelimit@ flag.
By default, it will map all the way to the end of the target, which will clobber any following partitions.
To figure out the size, look at the Blocks column output of @fdisk -ul@, and multiply that by 1024.
Thanks to Anonymous for pointing this out in the comments below.
Here's an example (for about 400 cylinders):

bc.
.

losetup -o 32256 --sizelimit 3290079232 /dev/loop2 /dev/loop1
mkfs /dev/loop2

p.


This will mount it so you can examine it and so you're ready to install grub. Make sure you have mkdir'd mnt/hdd, yada yada yada.

bc..
mount /dev/loop2 mnt/hdd/

p.



h3. Installing GRUB

This creates the file structure on the image for GRUB and copies local copies of critical GRUB files to the appropriate folder. It also copies whatever kernel you want to load into the root of the image's file system. Adjust files and paths to your liking.

bc..

mkdir -p mnt/hdd/boot/grub
cp -r /boot/grub/stage1 /boot/grub/stage2 /boot/grub/menu.lst mnt/hdd/boot/grub
cp -r the_kernel mnt/hdd/

p.

Don't forget to edit the menu.lst file (a grub.conf) to suit your kernel. Mine looked something like this. Look elsewhere for more guidance.

bc..
default 0
timeout 10

title=LonnyOS
root (hd0,0)
kernel /the_kernel

p.

Now install GRUB for real.

bc..
grub --device-map=/dev/null

p.

This will open up a GRUB environment. Enter the following:

bc..
device (hd0) mnt/hdd.img
root (hd0,0)
setup (hd0)

p.

Note that we set the device to the actual image file, and not the loopback device. GRUB can work with either. Normally, utilities work better with the device, but due to a "bug":http://www.mail-archive.com/bug-grub@gnu.org/msg09648.html in GRUB, it was flipping out (Error 22) when given the loopback device. It worked fine when installing on the hdd.img. For more details, look elsewhere (my references and google are decent starting points).


h3. Using the Image

You can easily mount the image and use it, even while using the image directly for a virtual machine. I ran @losetup -a@ to see which loopback devices I had, then the -d flag to delete whichever I don't need. Now I'll loopback directly into the image, and mount it. And then make sure my regular user account has all the access necessary. Also, be careful of any necessary sizelimits to @losetup@, as mentioned above.


bc..
losetup -o 32256 /dev/loop0 mnt/hdd.img
mount /dev/loop0 mnt/hdd
chown -R brho:brho mnt/hdd

p.

As I muck around with the_kernel, I can just cp it into mnt/hdd/, and quickly run KVM or Bochs to test the new kernel.

bc..
kvm mnt/hdd.img
bochs -q 'ata0-master: type=disk, mode=flat, path="./mnt/hdd.img", cylinders=1, heads=255, spt=63'

p.

One thing to note: after you copy the_kernel to mnt/hdd, the hdd.img is not actually updated instantly. This is because filesystems do not immediately flush their changes to disk, and the write() syscall will return early. If you want to immediately run your VM with your new image, simply sync your disks to make sure all writes are flushed.

bc..
sync

p.

h2. Conclusion

Hopefully this has helped you. If you hose your system, you're on your own / standard disclaimers apply. But if not, perhaps you are the happy owner of a fresh GRUB hdd image. More importantly, you should know how to make one and (roughly) how the process worked.

h2. References

"http://www.linuxjournal.com/article/4622":http://www.linuxjournal.com/article/4622
"http://sig9.com/bochs-grub":http://sig9.com/bochs-grub
"http://web2.clarkson.edu/projects/itl/honeypot/ddtutorial.txt":http://web2.clarkson.edu/projects/itl/honeypot/ddtutorial.txt
"http://www.mail-archive.com/bug-grub@gnu.org/msg09648.html":http://www.mail-archive.com/bug-grub@gnu.org/msg09648.html