BIOS shipped as binary blobs without source

cjwatson> any binary blobs, yes
(need to be pruned or source provided).

 * bios.bin we can get from seabios (although there are known bugs with the version of seabios present in Lucid, but not in the upstream version of bios.bin)
 * vgabios we can get from vgabios (although there are known bugs with the version of seabios present in Lucid, but not in the upstream version of vgabios)
 * PXE roms we should get from kvm-pxe
 * OpenBIOS comes from openbios.org, which is GPLv2, but not packaged for Ubuntu, see Bug #183495
 * video.x comes from maconlinux.org, which is GPLv2, but not packaged for Ubuntu

So ideally, we need to:
 a) depend on seabios
 b) depend on vgabios
 c) package openbios, and depend on openbios
 d) package mol, and depend on mol

Packaging openbios and mol may not be reasonable for Lucid.

We have been discouraged by upstream QEMU to build/run different versions of any of these ROMs from what's shipped in the upstream tarball, as those versions are the ones that are known to work well.

As I said, it's fine to use versions that are shipped in the upstream
tarball; I certainly don't care whether the files live in the qemu-kvm
package or in vgabios etc. Regardless of this, though, we need to
provide source for them or we are infringing the licence on at least the
LGPLed BIOS ROMs. Upstream QEMU is not the copyright owner for all of
this stuff, as far as I can tell, and does not have the authority to
waive our obligations.

Aside from legal obligations, we're also skating along the edge of our
own licensing policy by not shipping source:
http://www.ubuntu.com/community/ubuntustory/licensing. One might point
out that BIOS ROMs are firmware and thus might be eligible for a
case-by-case exception. Such exceptions were only meant to be granted
when the only way we could get some piece of hardware working was to
ship some bit of firmware we only had in the form of a binary blob. I
don't think anyone ever envisaged that the reason we might be shipping
binary blobs would be because it was too hard to build from source
accurately, and this doesn't seem like a good basis for an exception.

I would strongly recommend building the ROMs from matching source code
(I don't think source is really source unless we're actually building
the binaries from it - part of the point of shipping source is so that
people can make modifications, and if the source doesn't verifiably
match what we're shipping then that rather defeats the point). If
you're concerned that it might not match, then perhaps you could simply
compare it against a checksum after building, with a comment saying that
this is to ensure that they match the versions that have been QAed by
upstream? I'd have thought that the sort of compilation being done here
is using fairly static toolchain elements and thus would produce fairly
static output, which would require at most minor massaging to become
bitwise-identical to what upstream's shipping.

On Thu, Mar 18, 2010 at 10:19:16PM -0000, Dustin Kirkland wrote:
> d) package mol, and depend on mol

video.x is already in the mol-drivers-macosx package (powerpc only); mol
has been in the Ubuntu archive since at least Hoary and I think since
the very beginning. It's not identical to the one in qemu-common,
although the two files are the same size.

mol-drivers-macosx is in multiverse, and in Debian it's in non-free.
This is because it is licensed under the AFPL 1.2, which forbids
"deploying" modified versions within an organisation without publishing
them, which is a restriction on privacy that we don't want in main. See
http://www.gnu.org/philosophy/historical-apsl.html for more discussion
here. Right now, qemu-kvm's copyright file doesn't mention the
copyright or licence for any of the BIOS ROMs, much less this problem.

Unless there's been an APSL 2 release of MOL, I don't think we can
legitimately include video.x in qemu-kvm, nor depend on
mol-drivers-macosx.

See:
 * https://launchpad.net/~kirkland/+archive/ppa/+packages

I re-rolled the orig tarball after removing the binary blobs, and called it qemu-kvm_0.12.3.noroms.orig.tar.gz. I set it (back to) depending on vgabios and seabios, and suggesting openbios-sparc and mol-drivers-macosx (neither of which have built in Ubuntu in a very long time).

I need to do a bit of testing on these.

What do you think?

This bug was fixed in the package qemu-kvm - 0.12.3+noroms-0ubuntu1

---------------
qemu-kvm (0.12.3+noroms-0ubuntu1) lucid; urgency=low

  * Re-roll the orig tarball, after having manually deleted the included
    binary-only bios rom blobs who source was not also included in the
    package, LP: #541524; the following files were removed:
    - pc-bios/bios.bin
    - pc-bios/linuxboot.bin
    - pc-bios/multiboot.bin
    - pc-bios/openbios-ppc
    - pc-bios/openbios-sparc
    - pc-bios/openbios-sparc32
    - pc-bios/openbios-sparc64
    - pc-bios/ppc_rom.bin
    - pc-bios/pxe-e1000.bin
    - pc-bios/pxe-i82559er.bin
    - pc-bios/pxe-ne2k_pci.bin
    - pc-bios/pxe-pcnet.bin
    - pc-bios/pxe-rtl8139.bin
    - pc-bios/pxe-virtio.bin
    - pc-bios/vapic.bin
    - pc-bios/vgabios.bin
    - pc-bios/vgabios-cirrus.bin
    - pc-bios/video.x
  * debian/control:
    - qemu-common goes back to depending on vgabios and seabios
    - suggest mol-drivers-macosx, which is in multiverse, and provides
      video.x (when that package actually builds)
    - suggest openbios-sparc, which is in universe, and provides the
      powerpc/sparc openbios roms (when that package actually builds)
  * debian/links:
    - put links in place for the external seabios and vgabios blobs
  * debian/patches/larger_default_ram_size.patch: increase the default
    mem size for virtual machines from the mostly unusable 128M to 384M,
    which most modern distros require
 -- Dustin Kirkland <email address hidden> Mon, 22 Mar 2010 18:14:30 -0700

Actually this change is responsible of an new trouble with apparmor.

Extract of /var/log/syslog:
Mar 23 14:19:13 kiwi kernel: [ 7025.583776] type=1503 audit(1269350353.212:49): operation="open" pid=17840 parent=1 profile="libvirt-f25941b5-8a0b-086a-888e-fe8570f0487d" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/usr/share/seabios/bios.bin"
[..]
Mar 23 14:19:13 kiwi libvirtd: 14:19:13.401: error : qemudWaitForMonitor:1536 : internal error unable to start guest: char device redirected to /dev/pts/2#012qemu: could not load PC BIOS 'bios.bin'#012

see Bug #513273
provide right bios or -vga std do not work and this is important to provide resolution to vm

There are two different problems to be tackled here:

  - with seabios bios.bin we get a lot of messages saying "BUG: kvm_dirty_pages_log_enable_slot: invalid parameters".
  - with vgabios.bin and -vga std we get 800x600x4 maximum resolution, as a fallback in qemu.

I have tested different combinations of bios.bin and vgabios.bin, supplied by seabios and vgabios vs supplied by qemu sources, and have determined the two problems are completely independent. In fact, you get full vga resolution with seabios bios.bin and the qemu source's vgabios.bin, however the kvm_dirty_pages do appear.

*** As a workaround to the needy, delete the links bios.bin and vgabios.bin from /usr/share/qemu-kvm and copy the files with the same name from the directory pc-bios in qemu sources into the directory (or just copy vgabios.bin and use the -bios command line switch for qemu to select a bios.

One issue per bug, guys ...

The -vga std problem is detailed in length in Bug #513273. Please continue the vga discussion there.

I just opened a new bug for the libvirt apparmor seabios issue, Bug #545302. Thanks for the patch, I'm rolling and uploading a fix just now.