Development/Testing
From Syslinux Wiki
Contents |
Testing tips using an emulator
An emulator allows you to simulate a computer (called a Virtual Machine) in your existing Operating System. This is really helpful when developing at the bootloader level since you don't have to reboot your machine whenever you need to test.
Several types exist: Qemu (Open Source), Bochs (Open Source) or VMware (Closed Source). See the Resources section below.
Such tools will virtualize the motherboard for you, but you need to provide virtual devices, such as the hard drive.
Using extlinux or syslinux
Creating a virtual hard drive
A virtual hard drive is a file on disk that will be used in an emulator. There are several utilities to create it: bximage (shipped with Bochs), qemu-img (shipped with Qemu). VMware Workstation provides a built-in utility too.
The following examples will use qemu-img, but it shouldn't make any difference.
RAW format
The RAW format is the preferred one (most portable). qemu-img can generate one for you:
qemu-img create -f raw testing.img 10M
This creates a 10M blank RAW file.
VMDK format
VMDK is the format developed by VMware.
This can be done using VMware Workstation when creating a new Virtual Machine. If you only have VMware Player, qemu-img can generate one for you:
qemu-img create -s -f vmdk testing.vmdk 10M
This creates a 10M blank VMDK file.
Format the drive
To format it, create a loopback device:
losetup /dev/loop0 testing.img
To format the file as ext2 for instance:
mkfs.ext2 /dev/loop0
Don't forget to destroy the device when you don't need it anymore:
losetup -d /dev/loop0
Play with it!
The disk is now ready. You are now ready to install a SYSLINUX derivative on it and do some testing. For instance, to install extlinux:
mount /dev/loop0 /mnt/syslinux extlinux -i /mnt/syslinux
You can then boot from it using any emulator, e.g.:
qemu -M pc -hda testing.img -boot c
Typical workflow when testing a com32 module
Let's say you are developing a com32 module foo.c32. To test it, a typical workflow would be:
hack...hack...hack... make foo.c32 losetup /dev/loop0 testing.img mount /dev/loop0 /mnt/syslinux cp foo.c32 /mnt/syslinux umount /mnt/syslinux losetup -d /dev/loop0 qemu -M pc -hda testing.img -boot c hack...hack...hack...
Using pxelinux
Since qemu 0.9.1, it's possible do to a "local" PXE boot. Let's see how to use that feature.
Concept
When booting qemu using the network, it sends a DHCP requests and expect a PXE answer with the name of tftp server. While using the net user mode, QEMU offers a DHCP server. So basically, if this DHCP give a proper answer, it is possible to use a local dir to fake the content of a tftp server.
Implementation
In a local directory of your choice, put the same content as you do on a real tftp server. This example uses the ~/pxe directory.
~/pxe/
|--pxelinux.0
|--pxelinux.cfg/default
|--vmlinuz
|--initrd
|--hdt.c32
|--dummy_disk.img
Starting Qemu
This is a typical qemu call to net boot the local directory.
qemu -net nic -net user -boot n -hda ~/pxe/dummy_disk.img --kernel-kqemu -bootp /pxelinux.0 -tftp ~/pxe
As you can see, qemu still requires a sample disk image. This sounds like a bug but anyway, we need it even if it is not needed for the PXE booting. So QEMU will boot using the network (-boot n) and will use a local dir (~/pxe) as tftp root dir and will load pxelinux (~/pxe/pxelinux.0) as bootstrap.
And that's it! It's now up to you to provide in pxelinux.cfg/default a proper configuration to load a kernel or a COM32 module.
Note: you need Qemu 0.9.0 or higher.
Note2: you need a ROM for you ethernet card. To do this:
qemu /dev/null
Then switch to the monitor (Control-Alt-F2) and type:
info pci
Note: you can also pass the option
-monitor stdio
to access the monitor in the shell.
Look at your ethernet card information (PCI VENdor and DEVice IDs). Then go to rom-o-matic and download the corresponding ROM (.rom format). Save it under:
/usr/share/qemu/pxe-ne2k_pci.bin
You're all set!
Typical workflow when testing a COM32 module
Let's say you are developing a COM32 module foo.c32. To test it, a typical workflow would be:
ln -sf ~/mysyslinuxdeveltree/com32/modules/foo.c32 ~/pxe/ hack...hack...hack... make foo.c32 qemu -net nic -net user -boot n -hda ~/pxe/dummy_disk.img --kernel-kqemu -bootp /pxelinux.0 -tftp ~/pxe hack...hack...hack... make foo.c32 qemu -net nic -net user -boot n -hda ~/pxe/dummy_disk.img --kernel-kqemu -bootp /pxelinux.0 -tftp ~/pxe
As you can see, no need to do anything between two version as the tftp dir always point to the last version of your code!
User Contribution: Gene
Platform
My Use
Currently, I'm utilizing VMware Server as a desktop virtualization platform. Unlike VMware Player, it allows one to create VMs from scratch. Unlike VMware Workstation, their desktop application targeted towards developers, it is limited to 1 snapshot and no 3D acceleration. On occasion, the remote management capabilities of VMware Server have proven useful.
Compare
This is merely a brief comparison based on my use.
- QEMU: Doesn't idle the processor
- BOCHS: Doesn't idle the processor; a nice GUI with buttons for controlling some characteristics (remove/install floppy, power off)
- DOSEMU: Idles the processor; not a full virtualization platform
- VMware Server: Doesn't idle the processor; compatible (depending on VMware hardware version) with the enterprise products (VMware ESX) I manage at my job; Been using VMware products for over 8 years
Disks: Floppies
I've also been using raw disk images but rather than creating a full hard drive, I've used standard sized floppy images (as floppies, of course). Most systems today understand both "1.44MB" (1440kiB, technically) and "2.88MB" floppy images. For most uses, I use "2.88MB" floppy images as they give you more space while still being standardized. I did notice some issues with a "2.88MB" image and DOSEMU but I'm not sure if DOSEMU can be utilized in this manner effectively.
Using a floppy disk allows me to mount the disk in Linux, copy files in or edit existing files, umount then use it with VMware Server, BOCHS or QEMU.
