Bug 994082

Summary:	qemu smbios option doesn't work properly
Product:	[openSUSE] openSUSE Distribution	Reporter:	Ludwig Nussel <lnussel>
Component:	Virtualization:Other	Assignee:	Lin Ma <lma>
Status:	VERIFIED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P2 - High	CC:	grace.wang, jshand2013, lma, okurz, yfjiang, zcjia
Version:	Leap 15.0
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	Yes
Marketing QA Status:	---	IT Deployment:	---

Description Ludwig Nussel 2016-08-17 09:38:38 UTC

openQA uses the smbios option to pass smbios tables from a Laptop to
the VM so we can see how a system behaves on a Laptop. The used
files are here:
https://github.com/os-autoinst/os-autoinst/tree/master/dmidata/dell_e6330

The script to create them one level higher. The files are unchanged
since >= years and worked 10 months ago with 42.1 as guest.

With current qemu in Leap and Factory that doesn't work anymore.
/sys/devices/virtual/dmi/id/ doesn't contain chassis_type and
dmidecode throws an error.

Comment 1 Lin Ma 2016-08-29 13:57:55 UTC

the smbios code changed a lot since seabios 1.7.5.
It triggered this issue if user specifies the machine type like '-machine pc-i440fx-2.1,...' or newer.
will dig seabios code later.

Comment 2 Lin Ma 2016-09-07 02:17:10 UTC

A qemu patch was sent to upstream, waiting for feedback.

Comment 3 Ludwig Nussel 2016-11-07 12:12:42 UTC

any update?

Comment 4 Lin Ma 2016-11-08 03:29:26 UTC

no respond yet from upstream, perhaps them missed the patch, just ping them to try to get some
feedback. Because this isn't a urgent issue, I'd like to get some feedback from upstream first,
then merge it into our update.

Comment 5 Ludwig Nussel 2016-11-09 11:58:36 UTC

Well, for us it is important as right now we cannot do automated tests for laptops.

Comment 6 Lin Ma 2018-03-14 07:30:02 UTC

The SR  was posted.
https://build.opensuse.org/request/show/586666

Comment 7 Lin Ma 2018-03-15 03:29:34 UTC

The SR was accepted. close the issue as fixed.

Comment 8 Fei Li 2018-03-15 03:47:52 UTC

*** Bug 1084316 has been marked as a duplicate of this bug. ***

Comment 10 John Shand 2018-05-21 09:14:06 UTC

this bug seems to be present in tumbleweed 19/05/2018

i'm not too sure what information you need, but let me know

Comment 16 Oliver Kurz 2018-08-15 05:44:57 UTC

Hi Lin Ma, can you state if you plan to handle this reopened bug? The reminder comment point to recurring reproducing test failures which the openQA test reviewers assume is still due to this bug. E.g. https://openqa.opensuse.org/tests/725482/file/video.ogv#t=114.21,114.25 is one of the latest examples showing how the first boot entry is selected but then the system fails to boot and is as it looks like rebooting/crashing.

Comment 17 Lin Ma 2018-08-16 11:38:00 UTC

(In reply to Oliver Kurz from comment #16)
> Hi Lin Ma, can you state if you plan to handle this reopened bug? The
> reminder comment point to recurring reproducing test failures which the
> openQA test reviewers assume is still due to this bug. E.g.
> https://openqa.opensuse.org/tests/725482/file/video.ogv#t=114.21,114.25 is
> one of the latest examples showing how the first boot entry is selected but
> then the system fails to boot and is as it looks like rebooting/crashing.

Sorry for the late responding, a little bit busy recently.

These urls are hardly open by my browser in Beijing office, The connection to opensuse.org is terrible, I can't see them.

The issue which was described by comment 1 won't cause boot failure.
The previous patches were designed for avoid to throw errors while dmidecoding smbios tables in guest.

So far I have no idea what changes cause the boot failure, will take a look at it, but It takes time, I need to finish fates first in my hand.

Comment 18 Lin Ma 2018-08-27 11:01:44 UTC

Hi Oliver,

I read the openqa autoinst-log.txt and reproduced the issue on my local box today, The following are some information for your reference, hoep it can workaround the issue for you:

1. If guest os is leap42.3+ and machine type <=2.3 in qemu cmd line, the issue which mentioned by c16 can be reproduced.

2. If guest os is sles 11sp4,12+ or 15, the issue which mentioned by c16 can NOT be reproduced, whatever the machine type is.

3. This is a new issue, not the same one that described by c1.

Is it possible for you that adjust machine type to 2.4+ in openqa environment as a workaround? do you have anyelse testcases which need machine type 2.0?

Comment 20 Oliver Kurz 2018-09-14 13:52:34 UTC

So I assume that the issue as mentioned here has a fix available and we can set the bug to RESOLVED FIXED. https://progress.opensuse.org/issues/32116 is the ticket in the openQA backlog to actually bring the tests forward which should provide the necessary verification. We can follow on in there.

Comment 21 Jia Zhaocong 2018-09-17 05:13:07 UTC

Hi Oliver, I'm assigned to poo#32116.

I tried Leap 15.1 Build 302.1, with the default QEMUMACHINE=pc-i440fx-2.0, I got the same error with https://openqa.opensuse.org/tests/755850 .
After updating to QEMUMACHINE=pc-i440fx-2.4, it no longer stuck at grub.

So can you update "QEMUMACHINE=pc-i440fx-2.0" to "QEMUMACHINE=pc-i440fx-2.4" in https://openqa.opensuse.org/admin/machines ? (Do we need to update to versions newer than 2.4?)

Comment 22 Oliver Kurz 2018-09-17 14:36:24 UTC

I updated the machine definitions on o3 and retriggered the tests with the updated setting in the most recent openSUSE Leap build with:

$ for i in 755850 755855 755819 755827; do openqa-clone-job <o3> $i QEMUMACHINE=pc-i440fx-2.4 ; done
Created job #756977: opensuse-15.1-DVD-x86_64-Build302.1-gnome@Laptop_64-2G -> https://openqa.opensuse.org/t756977
Created job #756978: opensuse-15.1-DVD-x86_64-Build302.1-kde@Laptop_64-2G -> https://openqa.opensuse.org/t756978
Created job #756979: opensuse-15.1-NET-x86_64-Build302.1-gnome@Laptop_64 -> https://openqa.opensuse.org/t756979
Created job #756980: opensuse-15.1-NET-x86_64-Build302.1-kde@Laptop_64 -> https://openqa.opensuse.org/t756980

Let's see what they will tell :)

Comment 23 Oliver Kurz 2018-09-17 15:28:04 UTC

Ok, at least two jobs of these passed "first_boot" which is probably all we need to see :) I guess we are good here.