Re: Installing GRUB to drive image

[Charles Yost]

On Wed, Mar 28, 2012 at 7:51 PM, Jordan Uggla <address@hidden> wrote:
> 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:

Let me start by saying that although your tone could be interpreted as
harsh, I would always rather have helpful harsh criticism, than no
help at all. Thank you again for the time you've spent on this.

>>>> 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.

I used losetup to create the initial loop to the disk image, and then
kpartx to create mappings (under /dev/mapper/) for the partitions
within the disk image, and then losetup to create loops back to the
mapped partitions so that I could access the files on them. Do I
understand that I should just be using kpartx for everything?

>
>> 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.
>

Ah, I understand now. I thought device.map was a roadmap to how the
devices would look during booting.
I also misunderstood (hd0,1) to be the same as (hd0,msdos1), which
I've seen used in other places.

>> 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.
>

$BOOT_MOUNTPOINT = The first partition
$ROOT_MOUNTPOINT = The third partition
Only after linux boots does it mount the first partition at /boot
If I understand correctly I should remove the --root-directory option anyways.

>> 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.
>

Ok. I will be sure to just use grub-install from now on.

>> 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.
>

I will make the alterations and see if I can get the image to boot.

Thanks,
=> Charles Y.