This adds base_services_start test for ARM. We cannot use boot_to_login_screen
on ARM, because wait_still_screen fires too soon (for first minute or so screen of ARM
VM is completely blank). It also uses rather ugly hack of misusing HDD_ and NUMDISK,
see D860 and https://github.com/os-autoinst/openQA/issues/684.
Details
Try to run base_services_start on ARM.
Diff Detail
- Repository
- rOPENQATESTS os-autoinst-distri-fedora
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
templates | ||
---|---|---|
1579 | It's correct for both cases. We don't want to connect HDD_2 at all, neither in this test, nor in the other. Trigger is setting HDD_2_DECOMPRESS_URL during test scheduling (by POSTing it), so it is actually set for all ARM tests - that was the problem when I tried to use HDD_1_DECOMPRESS_URL. We set HDD_1=HDD_2 in first test (so we could use downloaded disk), and HDD_1=disk_%FLAVOR%_%MACHINE%.qcow2 for second (so it uses disk from previous test), but in neither case we want HDD_2 to be really connected to VM. | |
tests/base_services_start.pm | ||
8 | Problem isn't with timeout, problem is that wait_still_screen fires prematurely. During ARM boot it is normal for screen not to move for 30 seconds (so wait_still_screen 30 returns prematurely). Actually, because VT is initialized only halfway during the boot, it shows blank screen for tens of seconds. I could set higher stilltime_sec, but it means that it would take much longer before it realizes that system actually booted - and that would be also true for other architectures (would I removed get_var("ARCH") eq "arm"). I was thinking about changing boot_to_login_screen, but I couldn't find solution that would be general (architecture independent). |
The comment is incorrect here, isn't it? Shouldn't it only be in the other one?