action #95845
closedIP address for accessing host network from SUT no longer automatically assigned (under Tumbleweed) size:M
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: 
(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_64as 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:56than iPXE shows that the IP address is assigned correctly.
Files
Updated by okurz almost 3 years ago
- Priority changed from Normal to Urgent
- Target version set to Ready
Updated by mkittler almost 3 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.
Updated by ggardet_arm almost 3 years ago
The first one is missing -enable-kvm. Is it on purpose?
Updated by mkittler almost 3 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.
Updated by tinita almost 3 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.
Updated by ilausuch almost 3 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
Updated by favogt almost 3 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
Updated by okurz almost 3 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.
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?
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
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.