Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I did the following:

  1. created an empty .img file with dd
  2. associated it to /dev/loop0 with losetup
  3. created a partition in it with fdisk
  4. formatted such partition with mke2fs
  5. copied a custom GNU/Linux system into that partition

Now I'd like to make the .img file bootable by installing grub into its MBR and /boot directory. My goal is to load the .img file with qemu. It would be better if grub2 is used instead of grub legacy.


share|improve this question

This is with grub-pc version 1.98+20100804-5ubuntu3 (Maverick Meerkat).

The grub2 installer can install to loopback devices, but if you mount using the device mapper it will get confused and believe that you have an LVM scheme, failing mysteriously with a complaint about a missing abstraction.

Instead, you should setup the loopback device for the partition yourself, with a name that must match the pattern "/dev/loop[0-9]", i.e. without any partition designator at the end:

kpartx -v -a /dev/loop0
losetup /dev/loop1 /dev/mapper/loop0p1
mount /dev/loop1 /mnt

(Note that if you want grub-mkconfig/update-grub to operate on this volume, then the partition loopback must be connected to the disk loopback under /dev, and not directly to the image file).

Since you used fdisk to partition the image, you have an msdos-style partition table (aka label), and boot using a BIOS. In addition to putting the stage1/boot.img in the MBR, the stage1.5/core.img will be put in an embedding area in unpartitioned space (!) following right after, and there must be space for this.

The trick is now to tell the grub2 installer through a device map how your loopback setup will map to BIOS drives in the virtual machine. (In grub1 legacy this was done directly in the shell). You are probably planning to boot this image as the first disk, so I guess the appropriate mapping would be:

mkdir -p /mnt/boot/grub
cat > /mnt/boot/grub/ <<EOF
(hd0)   /dev/loop0
(hd0,1) /dev/loop1

Here I have put the device map inside the guest disk image, so that you can generate the boot configuration file grub.cfg:

mount --bind /dev /mnt/dev
chroot /mnt grub-mkconfig -o /boot/grub/grub.cfg

(Beware that the post-installer of the grub-pc package will run a probe that overwrites the device map(!), so you'll have to write it after installation and run grub-mkconfig/update-grub yourself).

Now run the installer from the host, pointing to the guest installation:

grub-install --no-floppy --grub-mkdevicemap=/mnt/boot/grub/ --root-directory=/mnt /dev/loop0

Finally, unmount everything set up here before starting qemu on your image:

umount /mnt/dev
umount /mnt
losetup -d /dev/loop1
kpartx -v -d /dev/loop0
share|improve this answer
Wow! I just ran into your answer while trying to understand why I couldn't update-grub a mount-looped, chrooted image file. I'm going to see if this can apply to my problem, but that's definitly an interesting track and very worth my upvote. Thanks! – filofel Dec 9 '10 at 16:01
Nice answer, unfortunately chroot /mnt grub-mkconfig -o /boot/grub/grub.cfg fails because there's no grub-mkconfig or any binary for that matter in the .img disk, and /mnt is already mounted. It would be great if you'd take it step by step and write all the details/commands. – Flavius Aug 30 '12 at 23:45
@RolKau: thank you for this excellent documentation! Together with toh's modifications below it solved many issues I had for years with grub when embedding from within chrooted environments. – sparkie Jan 9 '13 at 15:17
losetup -P is another good way of mounting a single partition: – Ciro Santilli 巴拿馬文件 六四事件 法轮功 Sep 11 '15 at 11:10

thanks a lot for these explanations. I integrated your solution into my own scripts with following modifications (translated to your notation/variables):

modprobe dm_mod
kpartx -va /root/rootfs.img # *.img is setup elsewhere
# normally you now would mount /dev/loop0p1 directly. BUT
# grub specialists didn't manage to work with loop partitions other than /dev/loop[0-9]
losetup -v -f --show /dev/mapper/loop0p1
mount /dev/loop1 /mnt
mkdir -p /mnt/boot/grub

# change into chrooted environment. all remaining work will be done from here. this differs from the howto above.
LANG=C chroot /mnt /bin/bash
set -o vi
mount -t sysfs sysfs /sys
mount -t proc  proc  /proc
# avoid grub asking questions
cat << ! | debconf-set-selections -v
grub2   grub2/linux_cmdline                select   
grub2   grub2/linux_cmdline_default        select   
grub-pc grub-pc/install_devices_empty      select yes
grub-pc grub-pc/install_devices            select   
apt-get -y install grub-pc
# don't setup prior to this point. It will be overwritten by grub-pc install
#corrected the /mnt/boot/grub/ to /boot/grub/
cat > /boot/grub/ << !
(hd0)   /dev/loop0
(hd0,1) /dev/loop1
# install here to fill /boot/grub for grub-mkconfig (update-grub)
grub-install /dev/loop0
# generate /boot/grub/grub.cfg

this works at least on debian squeeze. Check '/boot/grub/grub.cfg' for correctness.

share|improve this answer
Should cat > /mnt/boot/grub/ be done in the chrooted environment? If so, the path should be /boot/grub/ – cbliard Feb 12 '14 at 9:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.