On Mon, Oct 26, 2009 at 06:14:47PM +0200, RISKO Gergely wrote:
> Thanks for the idea.

thanks for taking the time to consider it.

 
> Somehow I'm not really sure about this.
> 
> First of all, the files in /usr/share/etherboot are currently gzipped?
> Can qemu and kvm use them, or do the system administrator has to ungzip
> them before?

yes, they have to be unzipped first.

one option would be for qemu or kvm to uncompress the needed roms at package
install time, though this could potentially get out of sync with the installed
version of etherboot.

 
> Why the images for kvm/qemu, why not for vmware/virtualbox/whatnot?

i know that qemu currently use the roms from etherboot (and am fairly certain
kvm does too), virtualbox implements their own roms (which i believe are code
copies of etherboot, so would be ideal to also use what's in the archive, if
technically feasible). i don't know what vmware does, but i'm guessing they
implement their own pxe rom.

qemu ships a copy of the uncompressed binaries in the package, by adding
etherboot as a build-dependency, uncompressing the appropriate etherboot roms,
and adding them to the package. thus the qemu packages are including binaries
without source, if the etherboot package and qemu package get out of sync.

so i suggest a package with the roms from qemu and kvm as they are a known set
of roms useful to other packages currently in the archive, and that currently
ship roms from the etherboot package in a sub-optimal way. 


> What is the problem with depending on the whole package?  Too big?
> 32Mb?  Is it too big on a system, where you run virtual machines with
> kvm (which only runs on a recent hardware)?

they need to be uncompressed to be useful. the size of the package would be
much larger if all the roms were shipped uncompressed.

with a relatively small set of uncompressed roms, it would be nice to not have
to install the whole package just to get network boot support for a handful of
network cards.

 
> And if the answer is still go ahead, then why not the all-in-one.iso.gz,
> which is 1Mb and has all major network cards, so probably can be used
> with all of the virtualization products?

using an iso image doesn't emulate a network booted machine; it emulates a
machine booting from a CD. so it wouldn't really be useful to emulate a true
thin-client that needed the CD for some other purpose.

 
> I'm open to discussion, but not sure about creating another binary
> package in the archive.  

understandable. using the logic that the proposed new etherboot package would
only include roms useful to virtual machines also present in the archive could
hopefully keep the scope of the package sane.


> Nowadays everyone is switching to some pxe solution anyway, instead of using
> etherboot...  

though the versions of etherboot in debian do support pxe.

i'm put some time into packaging gPXE, which is what the etherboot project has
moved most development to, although it is not currently in the archive, and who
knows how long the license and copyright review will take.

etherboot is already available in debian, and used indirectly by qemu and kvm.


> Can't kvm/qemu can just boot with pxe as if pxe support would
> have been built into the virtual hardware?

no, kvm/qemu don't re-implement pxe or other network booting code, they wisely
rely on other projects to handle that part of things so as not to duplicate
efforts.

upstream qemu does ship the binary etherboot roms in their tarballs without
source, which must be removed for debian's qemu packages, of course.


so, again, thanks for considering the request. hopefully my rationale is
convincing enough. :)

live well,
  vagrant



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to