Project

General

Profile

Actions
Copy link

action #101015

closed

[tools][sle][x86_64][aarch64][QEMUTPM] can openqa create swtpm device automatically? size:M

Added by rfan1 about 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
livdywan
Category:
Feature requests
Target version:
Ready
Start date:
2021-09-16
Due date:
2021-11-26
% Done:

0%

Estimated time:

Description

Hello openQA experts:

Observation

I tried to boot a vm with swtpm device attached, however, it reported error msg "[2021-10-15T05:01:44.346271+02:00] [warn] !!! : qemu-system-x86_64: -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock: Failed to connect socket /tmp/mytpm1/swtpm-sock: No such file or directory"

Acceptance criteria

  • AC1: qemu tpm device is created automatically

https://openqa.suse.de/tests/7422844#details

Steps to reproduce

1) re-run a job with "QEMUTPM"=1
openqa-clone-job --from http://openqa.suse.de --skip-deps --host http://openqa.suse.de 7369899 --apikey "xxx" --apisecret "xxx" --skip-download _GROUP=0 EXCLUDE_MODULES=openssl_alpn,build_hdd QEMUTPM=1

2) We can hit the issue mentioned above

Problem

As described in https://github.com/os-autoinst/os-autoinst/blob/master/doc/backend_vars.asciidoc
Configure VM to use a TPM emulator device, with appropriate args for the arch. sysadmin is responsible for running swtpm with a socket at /tmp/mytpmX, where X is the value of QEMUTPM or the worker instance number if QEMUTPM is set to 'instance'

However, IMO, the job should be assigned a random worker to run. we need have to configure a swtpm device there before start my job. at the same time, I may need swtpm 1.2 or swtpm 2.0 device based on the test requirement.

Suggestion

Workaround

n/a

Can someone help take a look at this issue?

Actions
Copy link
 #1

Updated by rfan1 about 3 years ago

  • Copied from action #98727: [tools][sle][aarch64] the published hdd can't be booted up due to wrong format added
Actions
Copy link
 #2

Updated by rfan1 about 3 years ago

  • Copied from deleted (action #98727: [tools][sle][aarch64] the published hdd can't be booted up due to wrong format)
Actions
Copy link
 #3

Updated by rfan1 about 3 years ago

  • Priority changed from Low to Normal
Actions
Copy link
 #4

Updated by livdywan about 3 years ago

  • Subject changed from [tools][sle][x86_64][aarch64][QEMUTPM] can openqa create swtpm device automatically? to [tools][sle][x86_64][aarch64][QEMUTPM] can openqa create swtpm device automatically? size:M
  • Description updated (diff)
  • Status changed from New to Workable
Actions
Copy link
 #5

Updated by livdywan about 3 years ago

  • Status changed from Workable to In Progress
  • Assignee set to livdywan

I'll grab it. Should be nice to have a ticket that's not depending on a moving target.

Actions
Copy link
 #6

Updated by rfan1 about 3 years ago

  • Description updated (diff)
Actions
Copy link
 #7

Updated by openqa_review about 3 years ago

  • Due date set to 2021-11-05

Setting due date based on mean cycle time of SUSE QE Tools

Actions
Copy link
 #9

Updated by livdywan about 3 years ago

cdywan wrote:

https://github.com/os-autoinst/os-autoinst/pull/1834

PR is under review. On top of the initial poc I added an additional swtpm package, check that existing devices continue to work (i.e. not creating a new device if one exists) and adjust tests to put the device file in place.

Actions
Copy link
 #10

Updated by rfan1 about 3 years ago

Thanks for the update!

For now, tpm2 support is high priority.

Actions
Copy link
 #11

Updated by livdywan about 3 years ago

  • Due date changed from 2021-11-05 to 2021-11-12

rfan1 wrote:

For now, tpm2 support is high priority.

I now added an additional variable QEMUTPM_VER. While the default is still 2.0 will be able to use both. And I also added tests for the respective cases.

Actions
Copy link
 #12

Updated by livdywan about 3 years ago

  • Due date changed from 2021-11-12 to 2021-11-19

Since the tests don't seem to behave correctly without it I prepared https://github.com/os-autoinst/os-autoinst/pull/1853

Actions
Copy link
 #13

Updated by livdywan about 3 years ago

  • Due date changed from 2021-11-19 to 2021-11-26
  • Status changed from In Progress to Feedback

Still need to verify in a "full openQA job" context, with the branch installed. Trying to do that on openqa-staging-1.qa.suse.de but seemingly running into unrelated issues

Actions
Copy link
 #14

Updated by livdywan about 3 years ago

cdywan wrote:

Still need to verify in a "full openQA job" context, with the branch installed. Trying to do that on openqa-staging-1.qa.suse.de but seemingly running into unrelated issues

sudo mv /usr/lib/os-autoinst{,.bak}
sudo git clone -b qemutpm_device https://github.com/kalikiana/os-autoinst /usr/lib/os-autoinst
sudo systemctl restart openqa-worker@42
sudo openqa-clone-job --from http://openqa.suse.de --skip-deps 7656835 _GROUP=0 CASEDIR="https://github.com/rfan1/os-autoinst-distri-opensuse.git#swtpm_test_only"
Created job #40945: sle-15-SP4-Online-x86_64-Build63.1-create_swtpm_hdd@64bit -> http://localhost/t40945

This unfortunately fails because /var/lib/openqa/share/tests/sle is not on swtpm_test_only. Maybe a bug?

I manually updated the distri anyway, and with QEMUTPM=1 QEMUTPM_VER=2 you something may be broken - need to investigate what that is.

Actions
Copy link
 #15

Updated by livdywan about 3 years ago

  • Status changed from Feedback to Resolved

cdywan wrote:

I manually updated the distri anyway, and with QEMUTPM=1 QEMUTPM_VER=2 you something may be broken - need to investigate what that is.

Btw to add swtpm I added the according repo:

releasever=15.2; sudo zypper ar -p 95 -f 'https://download.opensuse.org/repositories/security/openSUSE_Leap_$releasever' security; sudo zypper dup --from security --allow-vendor-change

I tried the variants i.e. QEMUTPM=1 QEMUTPM_VER=2 but also QEMUTPM=1 QEMUTPM_VER=1 and that seems to work. The test also shows the devices:

crw-rw---- 1 tss root  10,   224 Nov 25 12:17 /dev/tpm0
crw-rw---- 1 tss tss  253, 65536 Nov 25 12:17 /dev/tpmrm0

And e.g. [debug] running swtpm socket --tpmstate dir=/tmp/mytpm1 --ctrl type=unixio,path=/tmp/mytpm1/swtpm-sock --log level=20 -d --tpm2 is visible in autoinst-log.txt.

Note that porting the test is not part of this ticket.

Actions
Copy link
 #16

Updated by livdywan about 3 years ago

  • Status changed from Resolved to Feedback

Bad muscle memory, obviously the branch still needs to be merged :-D

Actions
Copy link
 #17

Updated by rfan1 about 3 years ago

Thanks much for your kindly help on this case again!

Actions
Copy link
 #18

Updated by livdywan about 3 years ago

  • Status changed from Feedback to Resolved

rfan1 wrote:

Thanks much for your kindly help on this case again!

You're very welcome!

Actions
Copy link
 #19

Updated by okurz about 3 years ago

  • Project changed from openQA Tests (public) to openQA Project (public)
  • Category changed from Bugs in existing tests to Feature requests
Actions
Copy link

Also available in: Atom PDF