To learn about Linux startup process I placed grub in a disk image file and tried to boot using qemu. I currently has not put any kernel image into the drive just grub. I installed grub using

kpartx -av mydrive.img
losetup /dev/loop1 /dev/mapper/loop0p1
mount /dev/loop1 mnt/mydrive/
cd mnt/mydrive/boot
grub-install --no-floppy --boot-directory=. -v /dev/loop0

I wanted to go through the boot sequence step by step, so I expected grub to claim that the kernel is missing, then I want to fix that by installing the kernel, and continue adding stuff all the way up to X.

Now I get

error: no such device

But expected

error: no configuration file

form rescue prompt, ls gives

(hd0) (fd0)

Questions: * What device is grub looking for? Is that something that refers to the host system? [Partially solved, the UUID is the same as the UUID for the virtual file system] * Why cannot Grub find the device?

All works fine if I install grub (and nothing but grub) from a live-cd (I chose Bodhi-linux since this is a small binary distro) inside the VM. Will qemu give the boot partition a different uuid, not used outside?

Here is the partition table for the virtual drive:

Disk mydrive.img: 264 MB, 264241152 byte
32 huvuden, 63 sektorer/spår, 256 cylindrar, totalt 516096 sektorer
Enheter = sektorer av 1 · 512 = 512 byte
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Diskidentifierare: 0xebe6ebdb

       Enhet Start     Början        Slut     Block    Id  System
mydrive.img1            2048      516095      257024   83  Linux
  • What version of grub? – eyoung100 Oct 23 '14 at 13:47
  • @eyoung100 grub2. Are there large differences between different versions within grub2? – user877329 Oct 23 '14 at 14:00
  • No, but a Major Difference exists Between Grub-1 and Grub-2. Drive Numbering in Grub is zero based. Since A VM only has one disk by default hd0 is correct. I believe your issue her is that you have not embedded the boot sector code in the boot block. See this Gentoo Wiki Entry. Follow the Configuration Section for BIOS/MBR /dev/loop0 is a CDROM type device. See WikiPedia, and you can't install a bootloader on a Read-only device. – eyoung100 Oct 23 '14 at 14:37
  • @eyoung100 But QEMU seems to boot into grub, and looking at the file in a hexeditor, I can see traces of grub. – user877329 Oct 23 '14 at 15:05
  • grub-install --no-floppy /dev/loop0 indicates that you attemped to install the bootsector code as an appendage to the image file. QEMU does not see the image file because it is treating the image as the hard disk hd0 as noted by your rescue prompt. You need to mount the image in a working system on the loop device like an ISO without the RO flag, create a boot directory in the image, run grub-install, pointed at the mount point of the image, unmount and reboot QEMU. This is one of the reasons I use VirtualBox. – eyoung100 Oct 23 '14 at 15:23

It seems the module for the kind of partition (I assume a DOS/MBR partition label) is not installed by grub by default into core.img.

Use the following to install the required module as well:

grub-install --modules part_msdos --root-directory=. /dev/loop0

Then grub should be able to read the partition table, the filesystem and therefore the installation contained in mnt/mydrive/boot.

As a result the grub command ls should output something like:

(hd0) (hd0,msdos1) (hd0)
  • It took me forever to discover this was the solution to not seeing the msdos partitions! – Beau Harder Dec 20 '16 at 22:07

Please note, as Giles pointed out, this applies to the x86 architecture only.


If you want to learn the proper order, you need to install a host system in QEMU before you install a kernel. While this approach seems counter intuitive to learning about the boot process, it is the only working way. Let me explain:

A running system of any OS has at least 3 Parts:

  1. A Kernel
  2. A Loader
  3. The final Booted OS.

Computers operate in two modes:

  1. Real Mode
  2. Protected Mode, sometimes referred to incorrectly as Virtual Mode.

All x86 processors operate in some form of these two modes no matter how sophisticated they are or how fast they operate. For More see the list to the right of the WikiPedia Articles I've linked.

How This Works

  1. All Computers Start in Real Mode.
  2. Real Mode does things like Checking your BIOS Settings, making sure all your Devices are connected, and Controls the Clock for Timing.
  3. Once Real Mode Completes checking, control is passed to the loader, aka the bootloader. The bootloader does exactly what it's name implies, by loading just enough pieces of code to transfer control of the PC from Real Mode to Protected Mode. Some Bootloaders achieve this Transfer at the beginning of their "takeover" Some do at the end, but most do it in Stages. See Booting.
  4. Once the Bootloader, completes loading the stages, the OS can safely and efficiently handle all other operations, as the PC is now in "Permanent Protected Mode" until the next restart.

How this Relates to Grub

If you look at the files that were copied over when you properly installed Grub, you'll see files containing the text Stage. There should be 3. Stage1*, Stage1_5*, and Stage2*

  1. Stage1 Loads boot.img which is embedded in the MBR/EFI. It is configured to attach to disks and at the Very end loads core.img
  2. Stage1_5 uses core.img to load Sectors 0-62, commonly referred to as the BootSector. These sectors by convention contain nothing, and therefore items placed in them are never overwritten or updated automaticaly
  3. Once Stage_2 begins, the first 62 sectors and the path to your kernel have been determined. Stage_2 loads the kernel, and its helper files, most natably the Initial RAM Disk into memory. The RAM Disk and Kernel are then uncompressed and used to setup yur system and transfer control to your chosen Linux OS.

See GNU Grub

Now the reason I say this is counter intuitive: You cannot start at Step 3 of How this Works, and Work your way through the How this Relates to Grub. After Stage1.5 completes Stage_2 will send you to a rescue prompt, as the Kernel and Initial RAM Disk, if you have one, once uncompressed have no device to setup, in your case hd0. Also the error Grub is reporting is correct.

error: no such device

is correct because there is no OS on hd0 to setup, therefore there is no OS to tell Grub Stage_2, "Hey I'm the OS that needs to be loaded." As such, you must work backwards, by building or installing the OS, then installing a kernel, and lastly installing the Bootloader. In your case, you need to configure QEMU to load the ISO image of a LiveCD as a CDROM, then install the OS on the virtual Disk hd0 then configure the bootloader. For a list of LiveCD's see DistroWatch Major Distributions. If you feel more comfortable with less bloat, try a Source Based Distribution, like Gentoo.

  • Do you mean I need to virtualize twice? – user877329 Oct 23 '14 at 17:15
  • No you only need to Virtualize once. Read the last section now that it's finished :) – eyoung100 Oct 23 '14 at 17:53
  • Installing grub (and only grub) from a live-cd inside the VM solves the problem of finding the device. Does the UUID became wrong somehow. Any way: grub starts its shell normally now. – user877329 Oct 23 '14 at 18:20
  • In that case, I learned something new today. Grub will happily exit to a grub shell if no OS exist. This is much like having DOS installed but no Windows in which you receive a C:\> prompt. Regarding the UUID, I don't think you're understanding the difference between your physical machine and a virtual machine. The LiveCD you used sees the Virtual Machine as if it were the physical machine, therefore because you have now properly installed Grub in the VM, Grub treats the image you created as if it were a real HDD. – eyoung100 Oct 23 '14 at 18:31
  • 1
    While there is some good stuff in here, there are enough errors to make it pretty misleading. All this real mode stuff is specific to x86, you should mention that. Only legacy boot goes into real mode when the BIOS (bootloader provided by the hardware vendor) finishes and loads the bootloader provided by the OS vendor such as Grub; EFI boot operates in long mode. The part about Grub is correct for Grub1 but not for Grub2 over EFI and I'm not sure about Grub2 over MBR. You can certainly install Grub without installing Linux; the blocking point is having stage2 somewhere. – Gilles 'SO- stop being evil' Oct 24 '14 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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