This is suppose to be stable between releases so that you can ensure smooth migrations between versions and recovery from save states. qemu-system-x86_64: Length mismatch: pc.bios: 0x40000 in != 0x20000: Invalid argument qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram' qemu-system-x86_64: load of migration failed: Invalid argument Previous version was 2.3.0-r5 and now I'm using 2.4.0-r1.
i don't think we can guarantee upgrades across all versions w/out never upgrading the bios blobs. we've been keeping the pinned versions based on what the qemu release itself uses in a particular release.
Upstream provides this guarantee when you specify pc-MAJOR.MINOR or q35-MAJOR.MINOR. We've screwed something up in our packaging.
i don't know what you mean by "pc-MAJOR.MINOR or q35-MAJOR.MINOR" does it work if you install qemu-2.4.0-r1, and then force downgrade seabios (e.g. `emerge ~sys-firmware/seabios-1.7.5 --nodeps`) ?
(In reply to SpanKY from comment #3) > i don't know what you mean by "pc-MAJOR.MINOR or q35-MAJOR.MINOR" > See `qemu-system-x86_64 -M help` for an example. The point of these is to provide stability to users so that if they upgrade from say qemu-2.3.0 to qemu-2.4.0 but run the VM with `qemu-system-x86_64 -M pc-i440fx-2.3 ...` it will still work > does it work if you install qemu-2.4.0-r1, and then force downgrade seabios > (e.g. `emerge ~sys-firmware/seabios-1.7.5 --nodeps`) ? Of course. I'm seeing now that there's a bios-256k.bin and bios.bin in qemu for 2.4.0 and that made me look at my original error message. We unfortunately built seabios 1.7.5 as a 256k BIOS and 1.8.2 builds as a 128k BIOS. The issue here is we should have always been building 128k BIOSes until QEMU 2.4.0 where we need both sizes. In this case we aren't compiling a 256k BIOS and instead using the one from upstream. The more I look at this the more I feel we should have the BIOSes sub-slotted. Another example of a user getting bitten by this can be seen on the Xen ML http://lists.xen.org/archives/html/xen-devel/2015-11/msg01588.html Maybe even slot them entirely and use eselect to let people select the default provider.
We have "pinned" (either due to "pin-upstream-blobs" or simply due to the fact that the firmware didn't update too often) the firmware for quite a while. For >=app-emulation/qemu-2.9.0-r50 I plan to break firmware compatibility to migrate away from old and rusty sys-firmware/vgabios, see bug #529862. I have added a prominent elog warning to 2.9.0-r50. Shall we prepare a news item as well?
Having a prominent warning in place the moment firmware changes is the best we can do, I'd say. See changes for 2.9.0-r50.
