Re: Installing GRUB to drive image

[Jordan Uggla]

On Wed, Mar 28, 2012 at 10:32 AM, Charles Yost <address@hidden> wrote:
> On Wed, Mar 28, 2012 at 1:38 AM, Jordan Uggla <address@hidden> wrote:
>> On Tue, Mar 27, 2012 at 9:28 PM, Charles Yost <address@hidden> wrote:
>>> I am attempting to install grub as the bootloader to a drive image.
>>> After attempting to use grub-install, then grub-mkimage and
>>> grub-setup, I cannot find a way to make it work. Can anyone help me?
>>
>> What commands did you run, and in what way did they "not work"? (And
>> for future references this is the type of information that you should
>> start with when asking for support).
>>
>> grub-mkrescue is probably the simplest way to make a bootable disk
>> image but kpartx and grub-install should work as well (with grub 1.99
>> or newer for the kpartx support).
>>
> Thanks for the response Jordan.
> I am using grub 1.99, but I'm not sure that grub-mkrescue will do what
> I want, because I'm attempting to create a bootable hard-disk image
> with separate /boot and /root directories.
> I used dd to create a 1GB image. Then I used parted to partition it
> with 4 partitions, (partition 1 for /boot, and partition 3 as /)
> 1049kB-50M, 50M-71M, 71M-547M, 547M-1023MB. Next I used losetup to
> find a free loop, and losetup $FREE_LOOP disk.img. Next kpartx -a
> $FREE_LOOP to create block devices for the partitions. I used
> mkfs.ext3 to format the partitions (such as mkfs.ext3 -b 1024 -L boot
> /dev/mapper/${FREE_LOOP}p1). I then used losetup --find to select more
> free loop devices, and used them to mount each partition, keeping

This is where you start to go wrong. The reason why kpartx is
recommended is because it creates these devices for you, and when you
use the devices created by kpartx grub's utilities can tell the relationship
between a partition and its drive. By adding the extra and completely
unneeded step of creating more loop devices for each partition you're
making it so that this information is no longer accessible to grub's
utilities. And since "kpartx -a /path/to/disk.img" will also
automatically find the first free loop device and use it, I would
recommend that you don't use losetup directly at all.

> track of which ones I used for which partition. I then write the
> device.map file using all the loops (eg: (hd0,1) /dev/loop2). Finally

This is also wrong. The device.map is at this point a file which you
should only use if you want to override the very good logic in grub's
utilities. By listing a device in the device.map you are telling
grub's utilities that it is, from the perspective of the firmare at
boot, a *drive* and nothing more. So if your extra losetup step
earlier hadn't been enough to confuse grub's utilities into thinking
that the partitions were separate non-partitioned drives with no
relation to /dev/loop0, you just explicitly told them that this was
the case. It may seem odd that device.map accepts device names with
',' in them but ',' is actually a common character in device names in
Open Firmware. Remove the device.map entirely and everything should
work fine.

> I copied in all the files needed (such as all the grub files). For the
> next few steps I tried several methods. Method 1: using grub-install
> from the host directory, then chrooting into the mounted image and
> using grub-mkconfig (eg: --modules=serial
> --boot-directory=$BOOT_MOUNTPOINT --root-directory=$ROOT_MOUNTPOINT).

--root-directory and --boot-directory actually control the same thing.
People were confused and limited by the semantics of --root-directory
and so --boot-directory was created and --root-directory only exists
for backwards compatibility. In short, if $BOOT_MOUNTPOINT was the
same as $ROOT_MOUNTPOINT/boot then it shouldn't have caused any
problem, but removing the --root-directory option will not hurt
anything and will be more clear.

> Method 2:  Copying in the GRUB images from /usr/lib/grub/i386-pc, then
> using grub-editenv to create the grubenv file, then grub-mkimage to
> create the core.img ($ROOT_MOUNTPOINT/usr/bin/grub-mkimage
> --directory=$ROOT_MOUNTPOINT/usr/lib/grub/i386-pc --format=i386-pc
> --output=$BOOT_MOUNTPOINT/grub/core.img --prefix="(hd0,msdos1)/grub"
> biosdisk ext2 part_msdos serial), then grub-setup (eg:
> $ROOT_MOUNTPOINT/usr/sbin/grub-setup --directory=$BOOT_MOUNTPOINT/grub
> --device-map=$CREATED_DEV_MAP "(hd0)")

grub-install is really the only way to go when installing grub. If you
can't get grub-install to work then it's *very* unlikely that you will
be to do anything worthwhile manually.

> Neither of these methods worked. GRUB starts up, says "error: no such
> disk" and then dumps me to the rescue prompt. And if I enter 'ls' it
> shows no disks.
> I hope I didn't leave anything important out.
> Thanks,
> => Charles Y.

Though reading through what I wrote above I've realized that it may
sound like harsh criticism, all of the mistakes you've made are
actually very common and understandable and I will try to add notes in
grub's documentation about these common pitfalls.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)