[SeaBIOS] [Qemu-devel] insmod virtio-blk is broken in qemu 1.0

Anthony Liguori anthony at codemonkey.ws
Mon Dec 19 20:44:33 CET 2011


On 12/19/2011 01:40 PM, Richard W.M. Jones wrote:
> On Mon, Dec 19, 2011 at 07:16:02PM +0000, Daniel P. Berrange wrote:
>> On Mon, Dec 19, 2011 at 07:04:54PM +0000, Richard W.M. Jones wrote:
>>> On Mon, Dec 19, 2011 at 12:02:59PM -0600, Anthony Liguori wrote:
>>>> I would like to point out that August ->  October is a pretty long
>>>> time period for a regression like this to exist.  I think that
>>>> really indicates that the primary problem is testing, not frequency
>>>> of SeaBIOS updates.
>>>
>>> Fair point.
>>>
>>> My understanding is we're going to switch to having qemu.git in Fedora
>>> Rawhide, which means that libguestfs will always be testing the
>>> 'perfect storm' of qemu + kernel + glibc from git (once glibc get
>>> their act together anyhow, just qemu + kernel at first).
>>>
>>> We usually do a build and a comprehensive test at least once a week,
>>> often a few times a week, so we would have picked this up much sooner.
>>
>> That wouldn't actually catch this problem, because when we build
>> QEMU in Fedora, we never use the SeaBIOS that QEMU includes in
>> GIT. Fedora always ships the newest SeaBIOS release available
>> from upstream, regardless of what QEMU includes.
>
> Ah yes indeed, I forgot about this.
>
> Nevertheless, it'll at least improve other aspects of our
> qemu testing :-)
>
> In reply to Anthony: the reason Fedora does this is because
> binary blobs aren't permitted, no matter what the origin.  We
> have to build SeaBIOS from source, and the choice is made to
> build from the upstream SeaBIOS source, not from the source
> release indirectly pointed to by qemu.

FWIW, we ship SeaBIOS source directly in our release tarballs.  There's nothing 
indirect about it.

Fedora could have a seabios-qemu RPM that was built from the qemu SRPM.  Since 
it ultimately is going to live in /usr/share/qemu, that seems like a nicer thing 
to do AFAICT.

You could have an alternatives mechanism if people really wanted to use upstream 
SeaBIOS...

Regards,

Anthony Liguori

>
> Rich.
>




More information about the SeaBIOS mailing list