mirror of
https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git
synced 2024-09-16 21:07:22 +00:00
d07b5a4178
We have had several problems where rebasing from one release to another just doesn't work, and we have to work around it somehow. Sometimes it's difficult or impossible to do. All we want to do here is check the rebase mechanism itself; we don't actually want to assert that you can rebase to any specific other release. For update tests, we should be able to use a non-standard ref name for the ostree we build, embed into the installer image, and install. That should mean we can then rebase to the standard ref name for the same release, which should be much safer than trying to rebase to a different release. We can't do this for the compose tests, but at least for update tests I'm hoping this makes things more robust. Signed-off-by: Adam Williamson <awilliam@redhat.com>
88 lines
2.8 KiB
Perl
88 lines
2.8 KiB
Perl
use base "installedtest";
|
|
use strict;
|
|
use testapi;
|
|
use utils;
|
|
|
|
sub run {
|
|
|
|
my $self = shift;
|
|
$self->root_console(tty => 3);
|
|
if (get_var("ARCH") eq "aarch64") {
|
|
# this should stop audit messages screwing things up
|
|
assert_script_run "rpm-ostree kargs --append=audit=0";
|
|
script_run "systemctl reboot", 0;
|
|
boot_to_login_screen;
|
|
$self->root_console(tty => 3);
|
|
}
|
|
|
|
# list available branches
|
|
my $subv = lc(get_var("SUBVARIANT"));
|
|
my $remote = "fedora";
|
|
$remote = "fedora-iot" if ($subv eq "iot");
|
|
assert_script_run "ostree remote refs $remote";
|
|
|
|
# get current branch
|
|
my $current = script_output "rpm-ostree status -b | grep fedora";
|
|
|
|
my $arch = lc(get_var("ARCH"));
|
|
|
|
# decide target
|
|
my $rebase;
|
|
my $target;
|
|
if ($current =~ "iot") {
|
|
$rebase = $current =~ "stable" ? "devel" : "stable";
|
|
$target = "fedora/${rebase}/${arch}/iot";
|
|
}
|
|
elsif ($current =~ "silverblue") {
|
|
my $relnum = get_release_number;
|
|
$rebase = $relnum - 1;
|
|
# on update tests, just rebase to the 'official' ref for the
|
|
# release, as opposed to the custom ref we used when building;
|
|
# this should be more reliable than a different release
|
|
$rebase = $relnum if (get_var("ADVISORY_OR_TASK"));
|
|
$rebase = "rawhide" if ($rebase eq get_var("RAWREL"));
|
|
$target = "fedora/${rebase}/${arch}/silverblue";
|
|
}
|
|
elsif ($current =~ "coreos") {
|
|
$rebase = $current =~ "stable" ? "testing" : "stable";
|
|
$target = "fedora/${arch}/coreos/${rebase}";
|
|
}
|
|
|
|
# rebase to the chosen target
|
|
validate_script_output "rpm-ostree rebase $target --bypass-driver", sub { m/systemctl reboot/ }, 300;
|
|
script_run "systemctl reboot", 0;
|
|
|
|
boot_to_login_screen;
|
|
$self->root_console(tty => 3);
|
|
|
|
# check booted branch to make sure successful rebase
|
|
validate_script_output "rpm-ostree status -b", sub { m/$target/ }, 300;
|
|
|
|
# rollback and reboot
|
|
if (get_var("ADVISORY") eq "FEDORA-2023-f6afa6f9e5") {
|
|
# FIXME: workaround for a very odd phenomenon with this update
|
|
# https://bodhi.fedoraproject.org/updates/FEDORA-2023-f6afa6f9e5#comment-2919613
|
|
# if that keeps happening after the update is stable we will
|
|
# have to do this for all affected releases
|
|
script_run "rpm-ostree rollback && systemctl reboot", 0;
|
|
boot_to_login_screen(timeout => 450);
|
|
}
|
|
else {
|
|
validate_script_output "rpm-ostree rollback", sub { m/systemctl reboot/ }, 300;
|
|
script_run "systemctl reboot", 0;
|
|
boot_to_login_screen;
|
|
}
|
|
$self->root_console(tty => 3);
|
|
|
|
# check to make sure rollback successful
|
|
validate_script_output "rpm-ostree status -b", sub { m/$current/ }, 300;
|
|
}
|
|
|
|
sub test_flags {
|
|
return {fatal => 1};
|
|
}
|
|
|
|
1;
|
|
|
|
# vim: set sw=4 et:
|