grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

grub2+qemu El Torito boot


From: Maciek Nowacki
Subject: grub2+qemu El Torito boot
Date: Wed, 26 Jul 2006 15:32:39 -0600
User-agent: Mutt/1.5.12-2006-07-14

Hi,

I've written a script that might be interesting to those who would like to
test GRUB2 in qemu without any use of root privileges. This method uses an
iso9660 filesystem, since mkisofs is the only program I know of that will
create a pre-filled filesystem compatible with GRUB2.

This is a two-stage approach that uses GRUB Legacy to load GRUB2 from a CD
image, which GRUB2 then uses as a hard drive (whole device, no partition
table). This is effectively native El Torito, except that GRUB Legacy handles
the initial boot.

GRUB2 should be able to load a menu file from the CD image, but I haven't
tried this yet...

The script is meant to run in the root of the directory that will be used to
generate the iso9660 filesystem. Everything is created from scratch (except
that GRUB2 must be compiled ahead of time and the GRUB Legacy stage2_eltorito
file must be available) so this could actually be an empty directory.
TORITO_IMAGE will probably have to be changed unless you have GRUB Legacy
installed on a Debian x86_64 host. QEMU specifies an x86_64 target.

Oh, and I wasn't able to get this to work with GRUB 1.94: I'm using a cvs
pull that is a few hours old, since 1.94 seems to go into rescue mode no
matter what I do.

-- Maciek


#!/bin/bash

# run-grub2.sh : July 26, 2006
# Maciek Nowacki <address@hidden>, http://m.4k.ca/

# configurable variables:
BOOT_IMAGE=booter.iso
TORITO_IMAGE=/lib/grub/x86_64-pc/stage2_eltorito

GRUB2_DIR=../grub2
GRUB2_IMAGE=core.img

QEMU=qemu-system-x86_64

# derived variables:
# MENU_LST is a bash array that is copied from beginning to end into menu.lst
# Other variables may be (and are) used in its initialization.
MENU_LST=(                                      \
        'timeout 0'                             \
        'title'                                 \
        'kernel (hd0)/'"${GRUB2_IMAGE}"         \
)

QEMU_CMD='-hda '"${BOOT_IMAGE}"' -boot d -cdrom '"${BOOT_IMAGE}"

GRUB2_MODLIST=` echo "${GRUB2_DIR}"/*.mod | tr \\  \\\n | sed -e s/\.mod// \
        | rev | sed -e s/\\\/\\.\\*// | rev | tr \\\n \\  `

GRUB2_MKIMAGE_CMD='-v -d '"${GRUB2_DIR}"' '${GRUB2_MODLIST}

TORITO_IMAGE_NAME=`echo "${TORITO_IMAGE}" | rev | sed -e s/\\\/.\*// | rev`
MKISOFS_CMD='-R -b '"${TORITO_IMAGE_NAME}"' -no-emul-boot -boot-load-size 4 
-boot-info-table .'

# override derived variables here if desired:


# end of variable initialization.

# Note that grub-mkimage and mkisofs both use stdout redirection to create
# their respective files. This is so that if either command fails, its target
# will be zeroed and the error will be more obviously apparent.

"${GRUB2_DIR}"/grub-mkimage ${GRUB2_MKIMAGE_CMD} > "${GRUB2_IMAGE}"

# These directories are typically hardcoded into stage2_eltorito. It would be
# neat to scan the binary for the actual location, rather than assuming.
rm -fr boot
mkdir -p boot/grub

# menu.lst is guaranteed not to exist at this point (rm above)
for (( COUNTER=0 ; $COUNTER < "${#MENU_LST[*]}" ; COUNTER++ )) do
        echo "${MENU_LST[$COUNTER]}" >> boot/grub/menu.lst 
done

cp "${TORITO_IMAGE}" .

mkisofs ${MKISOFS_CMD} > "${BOOT_IMAGE}"

"${QEMU}" ${QEMU_CMD}





reply via email to

[Prev in Thread] Current Thread [Next in Thread]