Qemu LiveCD experience

Paul Sladen ubuntu at paul.sladen.org
Mon Feb 20 04:52:33 GMT 2006

A short time ago, there was talk about making the LiveCD usable within MS
Windows by providing the ability to run it under the Qemu system emulator
within MS Windows.  I done the equivalent under Ubuntu, so here's the story.

On Linux the tendancy would be to use the image of the LiveCD directly with
something like:

  $ qemu -cdrom /dev/hdc

With MS Windows, this will not work as the raw CD data is not accessible.  
The contents of the CD will be mounted at a location like 'E:\' and it is
only possible to access the contents of that CD as normal files.  The only
files required for the LiveCD are:

  (a) kernel:      install/vmlinuz
  (b) initramfs:   install/initrd.gz
  (c) cloop:       casper/filesystem.squashfs

I eventually got this to work using:

  qemu -m 180 \
    -hda /dev/zero \
    -hdb live/casper/filesystem.squashfs \
    -kernel live/install/vmlinuz \
    -initrd initramfs.gz \
    -append "boot=casper initrd=/install/initrd.gz \
             ramdisk_size=1048576 root=/dev/ram rw quiet splash --"

with a two-line Kludge to Casper in 'scripts/casper' to make it use the
cloop as-is, without trying to mount a CD first.

   find_cd() {
  +       ln -s /dev/hdb /scripts/casper-qemu.squashfs && echo /scripts/casper-qemu.squashfs
  +       return;

and a one-line [workaround] Fix for qemu's '-initrd' option (the Ubuntu
kernels are just too big for Qemu's hard-coded defaults):

  -#define INITRD_LOAD_ADDR     0x00400000
  +#define INITRD_LOAD_ADDR     0x00600000

After about five minutes, the system boots and eventually gets to X (even
Suspend works!) and the system is surprisingly responsive.  Gotchas: 

 * 128MB is not enough RAM for the virtual machine, it'll die before X.
 * Passing the cloop as '/dev/hda' gets corrupted.  '/dev/hdb' is okay...

Qemu has native support for cloops as block device backing-files, so if the
LiveCDs was still using 'cloop', all the loopback overhead could be kept
outside of the emulated machine.  Because of now using squashfs this is no
longer possible;  SquashFS is a filesystem and so must be mounted inside of
the kernel, inside of the emulator.

It might be possible to use the native Qemu COW (Copy on Write) support as
'/dev/hdd' and then use this as the backing-store for unionfs instead of the
tmpfs within the machine.

There would need to be a small User-Interface to select if the user wants to
try a temporary session, fresh COW'ed session or their existing COW'ed
session.  It would be good to hack to the Qemu video card to present a
framebuffer size slighty smaller than the users screen (eg. 950x700) so they
can see the whole Ubuntu screen and still get to the taskbar...

Anyway, who out there has some time [ ;-) ] and wants to run with this to
see what they can do?  Obligitary screenshot, the other files are in that
directory too:


Britain is just cold, in a pesky way.  Nottingham, GB

More information about the ubuntu-devel mailing list