01.06.2010 07:17, Vagrant Cascadian wrote: > Package: qemu-kvm > Version: 0.12.4+dfsg-1~bpo50+1 > Severity: important > Tags: patch
> please consider using the newly introduced etherboot-qemu package to provide > PXE capable boot roms, rather than shipping copies of etherboot roms included > into the qemu-kvm package at build time. this makes it hard to track down the > sources that the etherboot roms were generated with, amoung other issues. What is interesting is that the pxe roms provided with the original upstream sources behaves differently from the ones in etherboot. Namely, all etherboot variants tries to boot twice: ----- Starting SeaBIOS (version 0.5.1-20100801_125707-gandalf) Booting from virtio-net.zrom 5.4.4 (GPL) ether... ROM segment 0xc900 length 0x8000 reloc 0x00000000 Etherboot 5.4.4 (GPL) http://etherboot.org Drivers: VIRTIO-NET Images: NBI ELF PXE Exports: PXE Protocols: DHCP TFTP Relocating _text from: [00087780,0009f310) to [07ee8470,07f00000) Boot from (N)etwork or (Q)uit? Probing pci nic... Probing isa nic... <sleep> Boot from (N)etwork or (Q)uit? Probing pci nic... [virtio-net]I/O address 0x0000c020, IRQ #11 MAC address 52:54:00:12:34:56 Searching for server (DHCP).... ----- This is new etherboot-qemu package, the same happens with the boot roms copied from older etherboot package. There's even a bugreport about this, see http://bugs.debian.org/585170 > the following patch that should address the issue, although you might consider > making etherboot-qemu a recommends rather than a depends. Well, if etherboot-qemu package isn't installed, we'll have a bunch of dangling symlinks, which is not good. I don't have any problems with the depends, esp. having in mind the dependency is quite small. But I wonder what is the difference between the original etherboot and this stripped-down etherboot-qemu. I see two points: etherboot-qemu is a subset of full etherboot (but it is still a separate package), and etherboot-qemu does not compress the boot roms. The latter can be dealt with in the qemu, i think - by uncompressing them automatically on the fly, it should be easy to implement. So.. Is there a good reason to introduce this stripped-down version? Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
