QA » openQA Project » openQA Tests

this looks like an sporadic issue, but I think it's worth investigating since assert_script_run('curl -O ' . data_url('textinfo')); belongs in the backend and that's a critical thing :)

# Test died: command 'curl -O http://10.0.2.2:20063/CldQCbjudrGe1EfF/data/textinfo' failed at /usr/lib/os-autoinst/testapi.pm line 953.
    testapi::_handle_script_run_ret(7, "curl -O http://10.0.2.2:20063/CldQCbjudrGe1EfF/data/textinfo", "fail_message", "", "timeout", 90, "quiet", undef) called at /usr/lib/os-autoinst/testapi.pm line 991
    testapi::assert_script_run("curl -O http://10.0.2.2:20063/CldQCbjudrGe1EfF/data/textinfo") called at microos/tests/console/textinfo.pm line 39
    textinfo::run(textinfo=HASH(0x55c8af23c578)) called at /usr/lib/os-autoinst/basetest.pm line 360
    eval {...} called at /usr/lib/os-autoinst/basetest.pm line 354
    basetest::runtest(textinfo=HASH(0x55c8af23c578)) called at /usr/lib/os-autoinst/autotest.pm line 372
    eval {...} called at /usr/lib/os-autoinst/autotest.pm line 372
    autotest::runalltests() called at /usr/lib/os-autoinst/autotest.pm line 242
    eval {...} called at /usr/lib/os-autoinst/autotest.pm line 242
    autotest::run_all() called at /usr/lib/os-autoinst/autotest.pm line 296
    autotest::__ANON__(Mojo::IOLoop::ReadWriteProcess=HASH(0x55c8b0bc8790)) called at /usr/lib/perl5/vendor_perl/5.26.1/Mojo/IOLoop/ReadWriteProcess.pm line 326
    eval {...} called at /usr/lib/perl5/vendor_perl/5.26.1/Mojo/IOLoop/ReadWriteProcess.pm line 326
    Mojo::IOLoop::ReadWriteProcess::_fork(Mojo::IOLoop::ReadWriteProcess=HASH(0x55c8b0bc8790), CODE(0x55c8b0c86640)) called at /usr/lib/perl5/vendor_perl/5.26.1/Mojo/IOLoop/ReadWriteProcess.pm line 488
    Mojo::IOLoop::ReadWriteProcess::start(Mojo::IOLoop::ReadWriteProcess=HASH(0x55c8b0bc8790)) called at /usr/lib/os-autoinst/autotest.pm line 298
    autotest::start_process() called at /usr/bin/isotovideo line 256

In this test the system is setup by a remote target. I don't think this should make a difference. However, it doesn't look like there's any attempt made to wait until the network is ready on the machine. It just waits for the login prompt and than immediately switches to the serial console attempting the download:

     $self->select_serial_terminal;
     assert_script_run('curl -O ' . data_url('textinfo'));

I find it a bit weird that there actually is a test module networking to test whether networking works but it only runs after textinfo and doesn't wait until the network is actually ready (with some timeout). It would make more sense to swap the order of those test modules and wait until the network is ready within networking.

I'm actually pretty sure that in these failures the networking just isn't ready. That's because the serial log shows that only the IPv6 address is assigned in the first place and the IPv4 address (which we rely on here) is only assigned later:

[  406.246840][    T1] reboot: Restarting system
[   15.567090][    T1] systemd[1]: Failed to transition into init label 'system_u:system_r:init_t:s0', ignoring.



Welcome to openSUSE MicroOS (x86_64) - Kernel 5.16.14-1-default (ttyS0).

SSH host key: SHA256:r2d0xtLtSNQOPt0VhMBodwl05cjT9Gcq1of80ZVLUHo (DSA)
SSH host key: SHA256:Y031XUds/7W74LT9hY6oO9LAtIbv118o6tRPvXF486w (ECDSA)
SSH host key: SHA256:HrjLbuj6HDWGvevGCSaG92q1MSTBlXk6AcWsvJQLExA (ED25519)
SSH host key: SHA256:GxJZDfGFv71X20sDKPg36fuJRDyEZGJiBVDQxXG1eX8 (RSA)
ens4:  fe80::5054:ff:fe12:38


localhost login: 


Welcome to openSUSE MicroOS (x86_64) - Kernel 5.16.14-1-default (ttyS0).

SSH host key: SHA256:r2d0xtLtSNQOPt0VhMBodwl05cjT9Gcq1of80ZVLUHo (DSA)
SSH host key: SHA256:Y031XUds/7W74LT9hY6oO9LAtIbv118o6tRPvXF486w (ECDSA)
SSH host key: SHA256:HrjLbuj6HDWGvevGCSaG92q1MSTBlXk6AcWsvJQLExA (ED25519)
SSH host key: SHA256:GxJZDfGFv71X20sDKPg36fuJRDyEZGJiBVDQxXG1eX8 (RSA)
ens4: 10.0.2.16 fe80::5054:ff:fe12:38


localhost login: YpuUt-0-

The log message without IPv4 address is also visible in screenshots after the failing curl invocation (https://openqa.opensuse.org/tests/2246907#step/textinfo/16) and the log message with IPv4 address only appears shortly later (https://openqa.opensuse.org/tests/2246907#step/textinfo/18).

So I would conclude that tests should simply wait until the network is ready (including IPv4) before using it. Hence I'm moving the ticket back to openQA tests.

mkittler you should be aware that removing the target version and not assigning the ticket to a team (with an according keyword in the subject) while keeping a "[" in the subject will likely lead to the ticket being overlooked for long, see https://progress.opensuse.org/projects/openqatests/wiki#ticket-backlog-triaging . You gave good suggestions what could be done except that the "networking" test module is microos specific, the test module "textinfo" is more generic, so moving one after the other is not something that works in all cases.

acarvajal assigning to you as test module maintainer. Could you please update the ticket with the right keyword for "diamond assurance"?