92d52c6ac6
So, there's a problem with how we figure out the NetworkManager connection to use in setup_tap_static: it expects the first connection in the list to be the right one, but this is only actually true so long as it's *active*. When we're in the tap case, it's usually not going to actually *work* out of the box on boot (or else we wouldn't need setup_tap_static at all...), so some time after boot, NetworkManager gives up on it and marks it as inactive. And after that, setup_tap_static won't work any more. I never noticed this as a problem before because usually we do setup_tap_static before that point. But it seems in the vnc client tests, on aarch64, desktop boot and login is slow enough that by the time we switch to a VT and try to setup the network, we're very close to that cutoff, and sometimes miss it. This, I hope, avoids the problem by doing the network setup in that test before we deal with the desktop login, then doing the desktop login, then doing the actual VNC bits. The alternative here would be to figure out a better way to do setup_tap_static, but I can't. Signed-off-by: Adam Williamson <awilliam@redhat.com>
26 lines
593 B
Perl
26 lines
593 B
Perl
use base "installedtest";
|
|
use strict;
|
|
use testapi;
|
|
use utils;
|
|
|
|
sub run {
|
|
menu_launch_type('boxes');
|
|
assert_screen ['apps_boxes_tutorial', 'boxes_new_connection'];
|
|
if (match_has_tag 'apps_boxes_tutorial') {
|
|
# Let us get rid of the Tutorial window.
|
|
send_key 'esc';
|
|
}
|
|
assert_and_click('boxes_new_connection');
|
|
assert_and_click('boxes_remote');
|
|
type_very_safely("vnc://172.16.2.114:5901\n");
|
|
assert_and_click('boxes_allow_inhibit');
|
|
assert_and_click('boxes_fullscreen');
|
|
}
|
|
|
|
sub test_flags {
|
|
return { fatal => 1 };
|
|
}
|
|
|
|
1;
|
|
|
|
# vim: set sw=4 et:
|