Re: Installing GRUB to drive image

[Charles Yost]

On Wed, Mar 28, 2012 at 9:00 PM, Charles Yost <address@hidden> wrote:
> 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.
>


Progress has been made, I think, but the image, when copied on to
disk, is not booting. It displays: (error: no such device:
69ee516d-d9b4-4075-84e4-8d71d31f3061) I don't have any partitions with
this block id on the system I used to create the image, so I can only
guess that it was the block id of the device created by kpartx? It
then dumps me to the rescue prompt. When at the rescue prompt, I can
type ls and it shows (hd0), but insmod normal produces: (error:
unknown filesystem.).
What should I try next?
=> Charles