mirror of
https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git
synced 2024-11-25 07:13:09 +00:00
eadf23a516
There's a weird issue with the rpmostree_rebase test for this update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f6afa6f9e5#comment-2919613 it doesn't reproduce locally (I can type fine after doing the same things the test does up to the rollback) and I can't think of any possible cause, and I don't want to hold the update up. So we're just gonna work around it and hope this doesn't start happening to all F38 update tests after this goes stable. If it does, we'll have to do the workaround for all of them. The workaround is just to rollback and reboot 'blindly', instead of checking the rollback command works. The drawback is that if the rollback command fails we'll wait 7.5 minutes before giving up on it, and it'll be a bit less clear exactly what happened. Signed-off-by: Adam Williamson <awilliam@redhat.com>
79 lines
2.4 KiB
Perl
79 lines
2.4 KiB
Perl
use base "installedtest";
|
|
use strict;
|
|
use testapi;
|
|
use utils;
|
|
|
|
sub run {
|
|
|
|
my $self = shift;
|
|
$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;
|
|
# avoid rebasing from 37 to <37, bad stuff happens
|
|
# FIXME when 38 branches, we should change this to RELNUM+1
|
|
$rebase = "rawhide" if ($relnum eq "37");
|
|
$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", 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:
|