tags 572991 + pending
thanks
Bjørn Mork wrote:
> Michael Tokarev <m...@tls.msk.ru> writes:
[]
>> I too noticed that the list of video modes available is quite a bit
>> shorter than it used to be, but at that time I were dealing with
>> another bug and didn't pay enough attention to that fact, and it
>> were "successfully" forgotten. But without your findings it'd be
>> much more difficult to find and fix things.
>>
>> I'm adding the thing to the Debian qemu-kvm git repository now, to
>> be fixed in the next release.
>
> I'm afraid my primitive approach is not the proper way to fix it.
> qemu-kvm should depend on vgabios and just install symlinks as qemu
> does:
>
> bj...@nemi:~$ ls -la /usr/share/qemu/vgabios*
> lrwxrwxrwx 1 root root 22 2010-01-10 20:31 /usr/share/qemu/vgabios.bin ->
> ../vgabios/vgabios.bin
> lrwxrwxrwx 1 root root 29 2010-01-10 20:31
> /usr/share/qemu/vgabios-cirrus.bin -> ../vgabios/vgabios.cirrus.bin
>
> Which is bug #489442. Fixing that one will close both bugs.
No, that wont work either. #489442 isn't fixed by purpose:
current qemu-kvm wont work with latest vgabios v 0.6c because
some more changes are required in qemu to support it. I'm
not sure qemu will work with 0.6c correctly in all cases
either.
But this bug -- #572991 -- is actually due to my lack of attention.
qemu upstream includes ROM sources in roms/{vga,sea}bios, but in
qemu-kvm-0.12 the directories were both empty for some reason.
So I concluded that kvm now comes without any bios sources, and
took both bioses from qemu upstrem. But it turned out that the
vga bios is still at the same place it was in kvm-88 and previous
releases, namely in kvm/vgabios.
So proper(*) fix to this bug is to drop vgabios patch and use vgabios
from kvm/vgabios/ as it used to be in 0.11 and before.
(*) by "proper" here I mean something appropriate for this release
anyway (0.12), -- having in mind the fact that it wont work with
current vgabios as shipped in Debian. It's upstream decision to
bundle bios into the tarball, and it comes not without a reason,
regardless if we like it or not. It shouldn't be difficult to
fix, but it has to be done anyway.
> BTW, I think I'm going to propose some variant of my debugging patch to
> qemu upstream. The "Could not open SDL display" is rather useless as a
> fatal error message, given how easy it is to trigger this error with a
> simple guest (mis)onfiguration.
There's more to the point than that. Error handling/reporting is not in
a best shape in qemu, but it is being worked on slowly. Just a few days
ago there was a series of patches posted to qemu-devel@ to add I/O error
reporting to various places. For example, before that, qemu-img had
"nice" error reporting like "Unable to format disk image". Now it can
do more, like "Unable to format disk image: Dermission denied". There
was a patch to temporarily fix that in ubuntu kvm package, but I didn't
take it to Debian package because, while it fixes most common cases,
there are many other cases (many other sources of errors) which it does
not cover correctly, and the just-posted upstream patch series fixes it
for all. That to say, -- error reporting is something that should
receive good thinking and planning, simplistic "fixes" does not work
there. At least in our qemu/kvm case. But it is a good idea to report
the bad examples anyway, so at least the upstream will be aware of
the problem... ;)
Thank you!
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
