os-autoinst-distri-fedora/tests/_boot_to_anaconda.pm

235 lines
10 KiB
Perl
Raw Permalink Normal View History

use base "anacondatest";
2015-01-26 14:58:07 +00:00
use strict;
use lockapi;
2015-01-26 14:58:07 +00:00
use testapi;
use utils;
use tapnet;
use anaconda;
2015-01-26 14:58:07 +00:00
sub _handle_incomplete_hub {
if (match_has_tag "anaconda_main_hub_keyboard_layout_incomplete") {
# workaround IoT/osbuild issue
# https://github.com/osbuild/images/issues/309
# by visiting the incomplete spokes
click_lastmatch;
wait_still_screen 3;
assert_and_click "anaconda_spoke_done";
# for animation
wait_still_screen 3;
assert_and_click "anaconda_main_hub_time_date_incomplete";
wait_still_screen 3;
assert_and_click "anaconda_spoke_done";
wait_still_screen 3;
send_key "shift-tab";
}
}
2015-01-26 14:58:07 +00:00
sub run {
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
my $self = shift;
if (get_var("IS_PXE")) {
# PXE tests have DELAYED_START set, so VM is not running yet,
# because if we boot immediately PXE will time out waiting for
# DHCP before the support server is ready. So we wait here for
# support server to be ready, then go ahead and start the VM
mutex_lock "support_ready";
mutex_unlock "support_ready";
resume_vm;
}
add a cockpit realmd FreeIPA join test Summary: This requires a few other changes: * turn clone_host_resolv into clone_host_file, letting you clone any given host file (cloning /etc/hosts seems to make both server deployment and client enrolment faster/more reliable) * allow loading of multiple POSTINSTALL tests (so we can share the freeipa_client_postinstall test). Note this is compatible, existing uses will work fine * move initial password change for the IPA test users into the server deployment test (so the client tests don't conflict over doing that) * add GRUB_POSTINSTALL, for specifying boot parameters for boot of the installed system, and make it work by tweaking _console_wait _login (doesn't work for _graphical_wait_login yet, as I didn't need that) * make the static networking config for tap tests into a library function so the tests can share it * handle ABRT problem dirs showing up in /var/spool/abrt as well as /var/tmp/abrt (because the enrol attempt hits #1330766 and the crash report shows up in /var/spool/abrt, don't ask me why the difference, I just work here) * specify the DNS servers from the worker host's resolv.conf as the forwarders for the FreeIPA server when deploying it; if we don't do this, rolekit defaults to using the root servers as forwarders(!) and thus we get the public, not phx2-appropriate, results for e.g. mirrors.fedoraproject.org, some of which the workers can't reach, so PackageKit package install always fails (boy, was it fun figuring THAT mess out) Even after all that, the test still doesn't actually pass, but I'm reasonably confident this is because it's hitting actual bugs, not because it's broken. It runs into #1330766 nearly every time (I think I saw *one* time the enrolment actually succeeded), and seems to run into a subsequent bug I hadn't seen before when trying to work around that by trying the join again (see https://bugzilla.redhat.com/show_bug.cgi?id=1330766#c37 ). Test Plan: Run the test, see what happens. If you're really lucky, it'll actually pass. But you'll probably run into #1330766#c37, I'm mostly posting for comment. You'll need a tap-capable openQA instance to test this. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D880
2016-06-07 20:00:39 +00:00
# construct the kernel params. the trick here is to wind up with
# spaced params if GRUB or GRUBADD is set, and just spaces if not,
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
# then check if we got all spaces. We wind up with a harmless
# extra space if GRUBADD is set but GRUB is not.
add a cockpit realmd FreeIPA join test Summary: This requires a few other changes: * turn clone_host_resolv into clone_host_file, letting you clone any given host file (cloning /etc/hosts seems to make both server deployment and client enrolment faster/more reliable) * allow loading of multiple POSTINSTALL tests (so we can share the freeipa_client_postinstall test). Note this is compatible, existing uses will work fine * move initial password change for the IPA test users into the server deployment test (so the client tests don't conflict over doing that) * add GRUB_POSTINSTALL, for specifying boot parameters for boot of the installed system, and make it work by tweaking _console_wait _login (doesn't work for _graphical_wait_login yet, as I didn't need that) * make the static networking config for tap tests into a library function so the tests can share it * handle ABRT problem dirs showing up in /var/spool/abrt as well as /var/tmp/abrt (because the enrol attempt hits #1330766 and the crash report shows up in /var/spool/abrt, don't ask me why the difference, I just work here) * specify the DNS servers from the worker host's resolv.conf as the forwarders for the FreeIPA server when deploying it; if we don't do this, rolekit defaults to using the root servers as forwarders(!) and thus we get the public, not phx2-appropriate, results for e.g. mirrors.fedoraproject.org, some of which the workers can't reach, so PackageKit package install always fails (boy, was it fun figuring THAT mess out) Even after all that, the test still doesn't actually pass, but I'm reasonably confident this is because it's hitting actual bugs, not because it's broken. It runs into #1330766 nearly every time (I think I saw *one* time the enrolment actually succeeded), and seems to run into a subsequent bug I hadn't seen before when trying to work around that by trying the join again (see https://bugzilla.redhat.com/show_bug.cgi?id=1330766#c37 ). Test Plan: Run the test, see what happens. If you're really lucky, it'll actually pass. But you'll probably run into #1330766#c37, I'm mostly posting for comment. You'll need a tap-capable openQA instance to test this. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D880
2016-06-07 20:00:39 +00:00
my $params = "";
$params .= get_var("GRUB", "") . " ";
$params .= get_var("GRUBADD", "") . " ";
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
# Construct inst.repo arg for REPOSITORY_VARIATION
my $repourl = get_var("REPOSITORY_VARIATION");
if ($repourl) {
$params .= "inst.repo=" . get_full_repo($repourl) . " ";
2015-02-04 13:45:37 +00:00
}
# Construct inst.addrepo arg for ADD_REPOSITORY_VARIATION
my $repourl = get_var("ADD_REPOSITORY_VARIATION");
if ($repourl) {
$params .= "inst.addrepo=addrepo,$repourl ";
}
if (get_var("ANACONDA_TEXT")) {
$params .= "inst.text ";
# we need this on aarch64 till #1594402 is resolved,
# and we also can utilize this if we want to run this
# over the serial console.
$params .= "console=tty0 " if (get_var("ARCH") eq "aarch64");
# when the text installation should run over the serial console,
# we have to add some more parametres to grub. Although, the written
# test case recommends using ttyS0, OpenQA only uses that console for
# displaying information but does not accept key strokes. Therefore,
# let us use a real virtio console here.
if (get_var("SERIAL_CONSOLE")) {
# this is icky. on ppc64 (OFW), virtio-console is hvc1 and
# virtio-console1 is hvc2, because the 'standard' serial
# terminal is hvc0 (the firmware does this or something).
# On other arches, the 'standard' serial terminal is ttyS0,
# so virtio-console becomes hvc0 and virtio-console1 is
# hvc1. We want anaconda to wind up on the console that is
# virtio-console1 in both cases
if (get_var("OFW")) {
$params .= "console=hvc2 ";
}
else {
$params .= "console=hvc1 ";
}
}
}
# inst.debug enables memory use tracking
$params .= "debug" if get_var("MEMCHECK");
add a cockpit realmd FreeIPA join test Summary: This requires a few other changes: * turn clone_host_resolv into clone_host_file, letting you clone any given host file (cloning /etc/hosts seems to make both server deployment and client enrolment faster/more reliable) * allow loading of multiple POSTINSTALL tests (so we can share the freeipa_client_postinstall test). Note this is compatible, existing uses will work fine * move initial password change for the IPA test users into the server deployment test (so the client tests don't conflict over doing that) * add GRUB_POSTINSTALL, for specifying boot parameters for boot of the installed system, and make it work by tweaking _console_wait _login (doesn't work for _graphical_wait_login yet, as I didn't need that) * make the static networking config for tap tests into a library function so the tests can share it * handle ABRT problem dirs showing up in /var/spool/abrt as well as /var/tmp/abrt (because the enrol attempt hits #1330766 and the crash report shows up in /var/spool/abrt, don't ask me why the difference, I just work here) * specify the DNS servers from the worker host's resolv.conf as the forwarders for the FreeIPA server when deploying it; if we don't do this, rolekit defaults to using the root servers as forwarders(!) and thus we get the public, not phx2-appropriate, results for e.g. mirrors.fedoraproject.org, some of which the workers can't reach, so PackageKit package install always fails (boy, was it fun figuring THAT mess out) Even after all that, the test still doesn't actually pass, but I'm reasonably confident this is because it's hitting actual bugs, not because it's broken. It runs into #1330766 nearly every time (I think I saw *one* time the enrolment actually succeeded), and seems to run into a subsequent bug I hadn't seen before when trying to work around that by trying the join again (see https://bugzilla.redhat.com/show_bug.cgi?id=1330766#c37 ). Test Plan: Run the test, see what happens. If you're really lucky, it'll actually pass. But you'll probably run into #1330766#c37, I'm mostly posting for comment. You'll need a tap-capable openQA instance to test this. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D880
2016-06-07 20:00:39 +00:00
# ternary: set $params to "" if it contains only spaces
$params = $params =~ /^\s+$/ ? "" : $params;
2015-02-04 13:45:37 +00:00
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
# set mutex wait if necessary
my $mutex = get_var("INSTALL_UNLOCK");
2015-01-27 12:35:27 +00:00
# we need a longer timeout for the PXE boot test
my $timeout = 60;
$timeout = 120 if (get_var("IS_PXE"));
# call do_bootloader with postinstall=0, the params, and the mutex,
# unless we're a VNC install client (no bootloader there)
unless (get_var("VNC_CLIENT")) {
do_bootloader(postinstall => 0, params => $params, mutex => $mutex, timeout => $timeout);
}
2015-02-04 13:05:20 +00:00
# Read variables for identification tests (see further).
my $identification = get_var('IDENTIFICATION');
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
# proceed to installer
if (get_var("KICKSTART") || get_var("VNC_SERVER")) {
# wait for the bootloader *here* - in a test that inherits from
# anacondatest - so that if something goes wrong during install,
# we get anaconda logs. sleep a bit first so we don't get a
# match for the installer bootloader if it hangs around for a
# while after do_bootloader finishes (in PXE case it does)
sleep 60;
assert_screen "bootloader", 1800;
}
else {
if (get_var("ANACONDA_TEXT")) {
# select that we don't want to start VNC; we want to run in text mode
if (get_var("SERIAL_CONSOLE")) {
# we direct the installer to virtio-console1, and use
# virtio-console as a root console
select_console('user-virtio-console');
unless (wait_serial "Use text mode", timeout => 120) { die "Anaconda has not started."; }
type_string "2\n";
unless (wait_serial "Installation") { die "Text version of Anaconda has not started."; }
}
else {
assert_screen "anaconda_use_text_mode", 300;
type_string "2\n";
# wait for text version of Anaconda main hub
assert_screen "anaconda_main_hub_text", 300;
}
}
else {
if (get_var('LIVE')) {
# on lives, we have to explicitly launch anaconda
my $launched = 0;
my $count = 5;
while ($count > 0) {
$count -= 1;
assert_screen ["live_start_anaconda_icon", "apps_menu_button_active", "next_button"], 300;
if (match_has_tag "next_button") {
# we're on F39+ Workstation and looking at gnome-initial-setup
# completing g-i-s launches the installer
gnome_initial_setup(live => 1);
$launched = 1;
}
if (match_has_tag "apps_menu_button_active") {
# give GNOME some time to be sure it's done starting up
# and ready for input
wait_still_screen 5;
send_key "super";
wait_still_screen 5;
}
else {
# this means we saw the launcher, which is what we want
last;
}
}
# if we hit the g-i-s flow we already launched
unless ($launched) {
# for KDE we need to double-click
my $relnum = get_release_number;
my $dclick = 0;
$dclick = 1 if (get_var("DESKTOP") eq "kde");
assert_and_click("live_start_anaconda_icon", dclick => $dclick);
unless (check_screen "anaconda_select_install_lang", 180) {
# click it again - on KDE since 2019-10 or so it seems
# like the first attempt sometimes just doesn't work
assert_and_click("live_start_anaconda_icon", dclick => $dclick, timeout => 300);
}
}
}
# wait for anaconda to appear
assert_screen ["anaconda_select_install_lang", "anaconda_webui_welcome"], 300;
# on webUI path we are done now, also set a var so later
# tests know if we're on the webUI path
if (match_has_tag "anaconda_webui_welcome") {
set_var("_ANACONDA_WEBUI", 1);
return;
}
# we click to work around RHBZ #1566066 if it happens
click_lastmatch;
my $language = get_var('LANGUAGE') || 'english';
assert_and_click("anaconda_select_install_lang", timeout => 300);
# Select install language
wait_screen_change { assert_and_click "anaconda_select_install_lang_input"; };
type_safely $language;
# Needle filtering in main.pm ensures we will only look for the
# appropriate language, here
assert_and_click "anaconda_select_install_lang_filtered";
assert_screen "anaconda_select_install_lang_selected", 10;
assert_and_click "anaconda_select_install_lang_continue";
2015-01-30 09:35:13 +00:00
# wait 180 secs for hub or Rawhide warning dialog to appear
# (per https://bugzilla.redhat.com/show_bug.cgi?id=1666112
# the nag screen can take a LONG time to appear sometimes).
# If the hub appears, return - we're done now. If Rawhide
# warning dialog appears, accept it.
if (check_screen ["anaconda_rawhide_accept_fate", "anaconda_main_hub"], 180) {
if (match_has_tag("anaconda_rawhide_accept_fate")) {
assert_and_click "anaconda_rawhide_accept_fate";
}
else {
# this is when the hub appeared already, we're done
_handle_incomplete_hub;
return;
}
}
# If we want to test self identification, in the test suite
# we set "identification" to "true".
# Here, we will watch for the graphical elements in Anaconda main hub.
my $branched = get_var('VERSION');
if ($identification eq 'true' or ($branched ne "Rawhide" && $branched ne "ELN")) {
check_left_bar(); # See utils.pm
check_prerelease();
check_version();
}
# This is where we get to if we accepted fate above, *or*
# didn't match anything: if the Rawhide warning didn't
# show by now it never will, so we'll just wait for the
# hub to show up.
assert_screen "anaconda_main_hub", 900;
_handle_incomplete_hub;
}
2015-01-27 12:35:27 +00:00
}
2015-01-26 14:58:07 +00:00
}
sub test_flags {
return {fatal => 1};
2015-01-26 14:58:07 +00:00
}
1;
# vim: set sw=4 et: