2016-05-20 14:53:45 +00:00
|
|
|
use base "installedtest";
|
2015-03-18 21:28:03 +00:00
|
|
|
use strict;
|
|
|
|
use testapi;
|
2017-01-18 07:15:44 +00:00
|
|
|
use utils;
|
2015-03-18 21:28:03 +00:00
|
|
|
|
2022-08-23 00:22:26 +00:00
|
|
|
sub _enter_password {
|
|
|
|
my $password = shift;
|
|
|
|
if (get_var("SWITCHED_LAYOUT")) {
|
|
|
|
# see _do_install_and_reboot; when layout is switched
|
|
|
|
# user password is doubled to contain both US and native
|
|
|
|
# chars
|
|
|
|
desktop_switch_layout 'ascii';
|
|
|
|
type_very_safely $password;
|
|
|
|
desktop_switch_layout 'native';
|
|
|
|
type_very_safely $password;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
type_very_safely $password;
|
|
|
|
}
|
|
|
|
send_key "ret";
|
|
|
|
}
|
|
|
|
|
2015-03-18 21:28:03 +00:00
|
|
|
sub run {
|
2016-09-12 17:24:30 +00:00
|
|
|
my $self = shift;
|
2020-10-28 21:20:16 +00:00
|
|
|
my $password = get_var("USER_PASSWORD", "weakpassword");
|
2018-09-07 01:23:13 +00:00
|
|
|
my $version = get_var("VERSION");
|
2022-08-23 00:22:26 +00:00
|
|
|
my $desktop = get_var("DESKTOP");
|
2016-05-05 23:39:47 +00:00
|
|
|
# If KICKSTART is set, then the wait_time needs to consider the
|
|
|
|
# install time. if UPGRADE, we have to wait for the entire upgrade
|
2016-07-08 15:56:57 +00:00
|
|
|
# unless ENCRYPT_PASSWORD is set (in which case the postinstall
|
|
|
|
# test does the waiting)
|
2016-05-05 23:39:47 +00:00
|
|
|
my $wait_time = 300;
|
|
|
|
$wait_time = 1800 if (get_var("KICKSTART"));
|
2016-07-08 15:56:57 +00:00
|
|
|
$wait_time = 6000 if (get_var("UPGRADE") && !get_var("ENCRYPT_PASSWORD"));
|
2015-03-18 21:28:03 +00:00
|
|
|
|
2019-11-05 20:13:33 +00:00
|
|
|
# handle bootloader, if requested
|
|
|
|
if (get_var("GRUB_POSTINSTALL")) {
|
2022-07-28 20:32:57 +00:00
|
|
|
do_bootloader(postinstall => 1, params => get_var("GRUB_POSTINSTALL"), timeout => $wait_time);
|
2019-11-05 20:13:33 +00:00
|
|
|
$wait_time = 300;
|
|
|
|
}
|
|
|
|
|
2017-04-03 23:23:45 +00:00
|
|
|
# Handle pre-login initial setup if we're doing INSTALL_NO_USER
|
2022-09-28 06:18:42 +00:00
|
|
|
if (get_var("INSTALL_NO_USER") && !get_var("_SETUP_DONE")) {
|
2022-08-23 00:22:26 +00:00
|
|
|
if ($desktop eq 'gnome') {
|
2022-07-28 20:32:57 +00:00
|
|
|
gnome_initial_setup(prelogin => 1, timeout => $wait_time);
|
2017-04-03 23:23:45 +00:00
|
|
|
}
|
|
|
|
else {
|
2022-07-28 20:32:57 +00:00
|
|
|
anaconda_create_user(timeout => $wait_time);
|
2019-10-21 17:56:31 +00:00
|
|
|
# wait out animation
|
|
|
|
wait_still_screen 3;
|
2017-04-03 23:23:45 +00:00
|
|
|
assert_and_click "initialsetup_finish_configuration";
|
2022-09-28 06:18:42 +00:00
|
|
|
set_var("_SETUP_DONE", 1);
|
2017-04-03 23:23:45 +00:00
|
|
|
}
|
|
|
|
$wait_time = 300;
|
|
|
|
}
|
2020-01-10 22:28:49 +00:00
|
|
|
# Wait for the login screen, unless we're doing a GNOME no user
|
|
|
|
# install, which transitions straight from g-i-s to logged-in
|
2018-09-07 01:20:08 +00:00
|
|
|
# desktop
|
2022-08-23 00:22:26 +00:00
|
|
|
unless ($desktop eq 'gnome' && get_var("INSTALL_NO_USER")) {
|
2018-09-07 01:20:08 +00:00
|
|
|
boot_to_login_screen(timeout => $wait_time);
|
|
|
|
# if USER_LOGIN is set to string 'false', we're done here
|
|
|
|
return if (get_var("USER_LOGIN") eq "false");
|
2018-09-06 22:01:08 +00:00
|
|
|
|
2018-09-07 01:20:08 +00:00
|
|
|
# GDM 3.24.1 dumps a cursor in the middle of the screen here...
|
|
|
|
mouse_hide;
|
2022-08-23 00:22:26 +00:00
|
|
|
if ($desktop eq 'gnome') {
|
2020-11-12 18:20:34 +00:00
|
|
|
# we have to hit enter to get the password dialog, and it
|
|
|
|
# doesn't always work for some reason so just try it three
|
|
|
|
# times
|
|
|
|
send_key_until_needlematch("graphical_login_input", "ret", 3, 5);
|
2018-09-07 01:20:08 +00:00
|
|
|
}
|
|
|
|
assert_screen "graphical_login_input";
|
2020-10-30 17:29:00 +00:00
|
|
|
# seems like we often double-type on aarch64 if we start right
|
|
|
|
# away
|
2023-02-23 23:06:07 +00:00
|
|
|
wait_still_screen(stilltime => 5, similarity_level => 38);
|
2022-08-23 00:22:26 +00:00
|
|
|
_enter_password($password);
|
2018-09-06 22:01:08 +00:00
|
|
|
}
|
2016-05-05 23:39:47 +00:00
|
|
|
|
2023-02-23 17:41:46 +00:00
|
|
|
# Handle the welcome tour, unless _WELCOME_DONE is set (indicating
|
|
|
|
# it's been done previously within this test run, e.g. the second
|
|
|
|
# time this module runs on the update flow, or earlier in the boot
|
|
|
|
# process on the INSTALL_NO_USER flow), or START_AFTER_TEST is set
|
|
|
|
# to the same value as DEPLOY_UPLOAD_TEST (in which case it will
|
|
|
|
# have been done by the previous test run).
|
2022-12-08 23:14:04 +00:00
|
|
|
# the point of the default values here is to make the check fail if
|
|
|
|
# neither var is set, without needing an extra condition
|
|
|
|
my $sat = get_var("START_AFTER_TEST", "1");
|
|
|
|
my $dut = get_var("DEPLOY_UPLOAD_TEST", "2");
|
2023-02-23 17:41:46 +00:00
|
|
|
handle_welcome_screen if ($sat ne $dut && !get_var("_WELCOME_DONE"));
|
2022-12-08 23:14:04 +00:00
|
|
|
if (get_var("IMAGE_DEPLOY")) {
|
2020-10-28 21:20:16 +00:00
|
|
|
# if this was an image deployment, we also need to create
|
|
|
|
# root user now, for subsequent tests to work
|
2024-01-09 18:37:57 +00:00
|
|
|
select_console "tty3-console";
|
2022-12-08 23:14:04 +00:00
|
|
|
console_login(user => get_var("USER_LOGIN", "test"), password => get_var("USER_PASSWORD", "weakpassword"));
|
2024-04-13 21:22:30 +00:00
|
|
|
wait_still_screen 3;
|
2022-12-08 23:14:04 +00:00
|
|
|
type_string "sudo su\n";
|
2024-04-13 21:59:14 +00:00
|
|
|
wait_still_screen 3;
|
2022-12-08 23:14:04 +00:00
|
|
|
type_string "$password\n";
|
2024-04-13 21:22:30 +00:00
|
|
|
wait_still_screen 3;
|
2022-12-08 23:14:04 +00:00
|
|
|
my $root_password = get_var("ROOT_PASSWORD") || "weakpassword";
|
|
|
|
assert_script_run "echo 'root:$root_password' | chpasswd";
|
|
|
|
desktop_vt;
|
2018-09-06 22:01:08 +00:00
|
|
|
}
|
|
|
|
|
Try hiding cursor in middle right of screen on desktops
os-autoinst is set so that if you once manually set the cursor
somewhere, all subsequent calls to `assert_and_click` will return
the cursor to the last manually-set position (if you never set
the cursor anywhere manually, it uses the `mouse_hide` location).
The mouse_hide location is no good for modern desktops as they
use hot corners in various ways, so for the desktop tests, early
in login, we set the mouse to 300/800, which we hope is a kind
of neutral location that doesn't interfere with matches of the
desktop_background needles (which I usually put towards the
right of the screen).
Unfortunately, KDE can show fairly big previews of active windows
down there, and hovering over one causes that window to be
displayed and all others to be hidden. Which rather breaks the
desktop browser test, when we have the Welcome Center popping up
on boot.
We already moved the mouse set point from 300/200 a few years
back because of a *different* awkward interaction with the browser
test, so we can't go back there. Let's try 1023/384 instead -
that's all the way on the right hand side of the screen, but half
way down, not in either corner. I really hope this doesn't cause
problems for any tests cos I don't know where else to stick the
damn thing if this doesn't work.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-12-04 17:15:17 +00:00
|
|
|
# Move the mouse somewhere it won't highlight the match areas and
|
|
|
|
# hopefully won't negatively interact with anything else later
|
|
|
|
mouse_set(1023, 384);
|
2018-09-06 22:01:08 +00:00
|
|
|
# KDE can take ages to start up
|
2022-07-28 20:32:57 +00:00
|
|
|
check_desktop(timeout => 120);
|
2015-03-18 21:28:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
sub test_flags {
|
Don't snapshot after wait_login tests (usually)
We currently snapshot after every run of _console_wait_login or
_graphical_wait_login, which means we snapshot *twice* on most
update tests as those modules get run twice. However, we almost
never use those snapshots. Snapshotting takes quite some time,
and hits the disk pretty hard, so we should avoid it unless it
is really needed.
We only have a few modules that are not fatal (and so might use
the snapshots), and most of those don't run after one of these
tests, or run after a later module that's also a milestone. Best
I can tell, only two test suites really need to use a snapshot
from a login test: server_cockpit_updates and modularity_tests.
To handle these and potential future cases, we'll add a new
module that does nothing, but is marked 'milestone', so it will
take a snapshot, and load that test after the login test if the
var LOGIN_SNAPSHOT is set, and set that var for those two suites.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-07 23:24:02 +00:00
|
|
|
return {fatal => 1};
|
2015-03-18 21:28:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|