Project

General

Profile

Actions

action #95845

closed

IP address for accessing host network from SUT no longer automatically assigned (under Tumbleweed) size:M

Added by mkittler over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
Regressions/Crashes
Target version:
Start date:
2021-07-22
Due date:
2021-08-05
% Done:

0%

Estimated time:

Description

observation

The fullstack test of os-autoinst fails under Tumbleweed because eth0 (within the SUT) does not get an IP address assigned automatically anymore. Likely a change within QEMU causes this.

As a workaround the following PR has been merged: https://github.com/os-autoinst/os-autoinst/pull/1728/files
That means assigning an IP manually works and to reproduce the issue via os-autoinst's fullstack test one needs to revert 3cd3e5fe076ad4c1ee55ace70eade03d1f1f9bc8.

(Btw, the workaround should likely have assigned the IP 10.0.2.15 because 10.0.2.2 is actually the Gateway.)

The problem is not limited to the TinyCore system, it also happens with openSUSE. E.g. when cloning a test with the online_repos module (like https://openqa.opensuse.org/tests/1849850) it becomes quite apparent that the IP address is not assigned: no IP

(The referenced test does not fail on the production instance because on production we're using Leap which doesn't seem to be affected.)

Acceptance Criteria

  • AC 1: Test runs again without this problem

suggestions

  • Check for changes within Tumbleweed's QEMU package
  • Check for changes of the QEMU invocation produced by os-autoinst
  • Likely a DHCP problem (with the DHCP server QEMU is supposed to provide?)
  • Read https://wiki.qemu.org/Documentation/Networking
  • Report a bug if someone is capable to identify the regression

further notes

  • So far I've been testing this with qemu-6.0.0-27.1.x86_64 as provided by Tumbleweed.
  • When just starting QEMU via qemu-system-x86_64 -m 1024 -accel kvm -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 than iPXE shows that the IP address is assigned correctly.

Files

online-repos.png (35.2 KB) online-repos.png mkittler, 2021-07-22 09:47
Actions #1

Updated by okurz over 2 years ago

  • Priority changed from Normal to Urgent
  • Target version set to Ready
Actions #2

Updated by mkittler over 2 years ago

  • Description updated (diff)
Actions #3

Updated by mkittler over 2 years ago

The QEMU invocation of the fullstack test is:

/usr/bin/qemu-system-i386 -only-migratable -chardev ringbuf,id=serial0,logfile=serial0,logappend=on -serial chardev:serial0 -audiodev none,id=snd0 -device intel-hda -device hda-output,audiodev=snd0 -m 1024 -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -boot once=d -smp 1 -no-shutdown -vnc :90,share=force-shared -device virtio-serial -chardev pipe,id=virtio_console,path=virtio_console,logfile=virtio_console.log,logappend=on -device virtconsole,chardev=virtio_console,name=org.openqa.console.virtio_console -chardev socket,path=qmp_socket,server,nowait,id=qmp_socket,logfile=qmp_socket.log,logappend=on -qmp chardev:qmp_socket -S -blockdev driver=file,node-name=hd0-file,filename=/tmp/99-full-stack.t-ttWL/pool/raid/hd0,cache.no-flush=on -blockdev driver=qcow2,node-name=hd0,file=hd0-file,cache.no-flush=on -device ide-hd,id=hd0-device,drive=hd0,serial=hd0 -blockdev driver=file,node-name=cd0-overlay0-file,filename=/tmp/99-full-stack.t-ttWL/pool/raid/cd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=cd0-overlay0,file=cd0-overlay0-file,cache.no-flush=on -device ide-cd,id=cd0-device,drive=cd0-overlay0,serial=cd0

For the cloned KDE test it is:

/usr/bin/qemu-system-x86_64 -only-migratable -chardev ringbuf,id=serial0,logfile=serial0,logappend=on -serial chardev:serial0 -audiodev none,id=snd0 -device intel-hda -device hda-output,audiodev=snd0 -global isa-fdc.fdtypeA=none -m 1536 -cpu qemu64 -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -boot once=d -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -no-shutdown -vnc :91,share=force-shared -device virtio-serial -chardev pipe,id=virtio_console,path=virtio_console,logfile=virtio_console.log,logappend=on -device virtconsole,chardev=virtio_console,name=org.openqa.console.virtio_console -chardev socket,path=qmp_socket,server,nowait,id=qmp_socket,logfile=qmp_socket.log,logappend=on -qmp chardev:qmp_socket -S -device virtio-scsi-pci,id=scsi0 -blockdev driver=file,node-name=hd0-file,filename=/hdd/openqa-devel/openqa/pool/1/raid/hd0,cache.no-flush=on -blockdev driver=qcow2,node-name=hd0,file=hd0-file,cache.no-flush=on -device virtio-blk,id=hd0-device,drive=hd0,serial=hd0 -blockdev driver=file,node-name=cd0-overlay0-file,filename=/hdd/openqa-devel/openqa/pool/1/raid/cd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=cd0-overlay0,file=cd0-overlay0-file,cache.no-flush=on -device scsi-cd,id=cd0-device,drive=cd0-overlay0,serial=cd0

Maybe the parameters -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 are problematic.

Actions #4

Updated by ggardet_arm over 2 years ago

The first one is missing -enable-kvm. Is it on purpose?

Actions #5

Updated by mkittler over 2 years ago

  • Description updated (diff)
Actions #6

Updated by mkittler over 2 years ago

@ggardet_arm We possibly disabled KVM because it wasn't working within the CI (or on any system we wanted to run the test suite). I suppose the parameter doesn't make a difference here.

Actions #7

Updated by tinita over 2 years ago

I just wanted to note my debugging from yesterday.
I got a failure a couple of times for the fullstack test (but very few times), but most of the times it succeeded. I wasn't able to find out if it was failing for the exact same reason as in GHA, because when I tried to shorten it to run only the failing test module, the error didn't occur anymore at all.
I'm on Leap 15.2.

Actions #8

Updated by ilausuch over 2 years ago

  • Subject changed from IP address for accessing host network from SUT no longer automatically assigned (under Tumbleweed) to IP address for accessing host network from SUT no longer automatically assigned (under Tumbleweed) size:M
  • Description updated (diff)
  • Status changed from New to Workable
Actions #9

Updated by favogt over 2 years ago

  • Status changed from Workable to In Progress

It's a bug in libslirp, which got updated to 4.6.0 recently.

It's fixed only in latest master. I made a SR: https://build.opensuse.org/request/show/907725

Actions #10

Updated by okurz over 2 years ago

  • Due date set to 2021-08-05
  • Status changed from In Progress to Blocked
  • Assignee set to okurz

cool, thx. The submission to openSUSE:Factory is https://build.opensuse.org/request/show/907726 . I will wait for that.

Actions #11

Updated by favogt over 2 years ago

  • Status changed from Blocked to Resolved

okurz wrote:

cool, thx. The submission to openSUSE:Factory is https://build.opensuse.org/request/show/907726 . I will wait for that.

Got released with TW 20210725. Does it fully resolve the issue?

Actions #12

Updated by okurz over 2 years ago

  • Status changed from Resolved to Feedback

We should still revert the workaround in os-autoinst test code again: https://github.com/os-autoinst/os-autoinst/pull/1735

Actions #13

Updated by okurz over 2 years ago

  • Status changed from Feedback to Resolved

tests run again fine in GHA on master branch after merging the revert. The fix to the dependency has been provided. So how we addressed the issue: We found the problem, reacted soon. Identified that an updated dependency could be the reason. First we assumed qemu but with the help of the right persons, e.g. ggardet and fvogt, in #opensuse-factory . mkittler did good by creating a workaround quickly. The real problem was fixed and finally we removed the workaround again. So all good now.

Actions

Also available in: Atom PDF