Updated to fc24, got unbootable 4.5.0-rc7 kernel, qemu 2.5.0 and edk2.git-0-20160324.b1635.gf0bbcdf.x86_64.
The problem still persists. I was able to jump into ovmf setup menu, the drive is recognised. Trying booting from any partition results in a hang and errors.
First it says about invalid MBR on a GPT disk, the last two lines of the debug console are:
ExtractConfig: BlockToConfig(): Invalid Parameter, Progress="<null string>
ASSERT /home/jenkins/workspace/edk2/rpmbuild/rpm/BUILD/edk2.git/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c(1256): TmpRequest != ((void *) 0)
In short, updating to qemu 2.5 did not help.
OVMF is from git, upgrading QEMU ATM to 2.5.x. Apparently, fedora has 2.5 qemu only in beta 24.
Thanks for the advice, didn't know about the new qemu release.On Mar 27, 2016 1:01 AM, "Dan Ziemba" <zman0900 gmail com> wrote:On Fri, 2016-03-25 at 01:10 +0300, Blank Field wrote:
> Hello again, fellow subscribers.
> Since 4.3.X kernels I am experiencing some strange problems with disk
> I am passing through the whole /dev/sda(since i also dualboot into
> that system for some weird software or hardware) to my VM, and since
> recent versions of kernel the VM gets stuck in an endless loop,
> consuming 100% one core.
> The ISA debug console says stuff like:
> PartitionValidMbr: Bad MBR partition size EndingLBA(D99299D3) >
> The thing is that the disk in question has nothing to do with MBR, it
> is formatted into GPT.
> I can't pinpoint the source of that weird D99299D3 number.
> That kind of error happens for every partition detected.
> Device Start End Sectors Size Type
> /dev/sda1 2048 1171875000 1171872953 558.8G Microsoft basic
> /dev/sda2 1171875840 1172080639 204800 100M EFI System
> /dev/sda3 1172080640 1172342783 262144 128M Microsoft reserved
> /dev/sda4 1172342784 1465145343 292802560 139.6G Microsoft basic
> /dev/sda5 1465145344 1953525134 488379791 232.9G Microsoft basic
> That looks like a valid partition table for me. Moreover, the fact
> that i am able to boot an UEFI-capable system bare-metal confirms
> the partition table is correct.
> I remember i've seen some related messages on the list in february or
> something, but they only stated the existence of this error.
> Have any of you seen stuff like that? If so, how do you live with it?
> Maybe i should write to edk2-devel mailing list for this, because it
> isn't much related to VFIO, but normal qemu folks rarely sacrifice
> whole disk to a VM.
> QEMU emulator version 2.4.1 (qemu-2.4.1-7.fc23)
> kernel 4.4.5-300.fc23.x86_64(doesn't matter much from 4.3.X)
A lot of people had problems booting with OVMF with kernels 4.2 and
4.3. It's fixed for myself and I think most others with 4.4, but I
think you may need fairly recent qemu and ovmf versions. Looks like
your OVMF is new enough if that date means what I think it does, but
you should try upgrading to qemu 2.5.
vfio-users mailing list
vfio-users redhat com