action #117349
closedFix booting to hdd after online migration in uefi
Description
Motivation¶
Job fails not being able to select hd after yast2 migration ending on starting new installation: https://openqa.suse.de/tests/9622209#step/yast2_migration/23
Needle inst-bootmenu
needs to match in opensusebasetest
Acceptance criteria¶
AC1: Fix test suite settings, change MACHINE: 64bit
to MACHINE: uefi
AC2: Fix needle above to allow proper booting
Updated by JERiveraMoya about 2 years ago
I don't get why it is configured with MACHINE: 64bit
instead MACHINE: uefi
.
@tina, if you know any reason please add it here, otherwise, I set AC1
.
Updated by JERiveraMoya about 2 years ago
- Description updated (diff)
- Target version set to Current
Updated by JERiveraMoya about 2 years ago
- Subject changed from During yast2 migration phase, popup unexpected beta warning page to Fix booting to hdd after online migration in uefi
Updated by leli about 2 years ago
This looks not like a needle issue, after grub2 matched at https://openqa.suse.de/tests/9622209#step/yast2_migration/15, it should select 'boot from hard disk' while not sending ret.
[2022-09-28T11:30:47.388327+02:00] [debug] >>> testapi::_handle_found_needle: found bootloader_uefi-grub2-20211009, similarity 1.00 @ 118/305
[2022-09-28T11:30:47.388806+02:00] [debug] tests/migration/online_migration/yast2_migration.pm:277 called opensusebasetest::wait_boot -> lib/opensusebasetest.pm:1177 called opensusebasetest::handle_grub -> lib/opensusebasetest.pm:981 called opensusebasetest::grub_select -> lib/opensusebasetest.pm:944 called testapi::send_key
Need investigate why handle_grub call grub_select while not wait_grub, deep check the parameters for the functions and compare the setting of failed job and passed job.
Updated by JERiveraMoya about 2 years ago
resolution changed, please compare screenshots:
https://openqa.suse.de/tests/9622209#step/online_migration_setup/1
https://openqa.suse.de/tests/9519130#step/online_migration_setup/1
and
https://openqa.suse.de/tests/9622209#step/yast2_migration/15
https://openqa.suse.de/tests/9519130#step/yast2_migration/15
For the failure we have:
inst-bootmenu
29 % bootloader_uefi-20210301
Updated by jgwang about 2 years ago
I just added some diag output in the code, and then I used the command openqa-clone-custom-git-refspec to clone job 9622209, here is the new job https://openqa.suse.de/tests/9714863, it passed.
Updated by jgwang about 2 years ago
I checked the mustmatch tag array like [ "bootloader-shim-import-prompt","grub2","migration-source-system-grub2","inst-bootmenu"], I don't know if needle is a random match in the array with the testapi "assert_screen", and we expect "inst-bootmenu" matched.
the tags from bootloader_uefi-20210301.json: [ "ENV-UEFI-1","ENV-OFW-0","inst-bootmenu","bootloader-grub2" ]
the tags from bootloader_uefi-grub2-20211009.json: [ "grub2" ]
Updated by JERiveraMoya about 2 years ago
- Tags deleted (
qe-yast-refinement) - Status changed from New to Workable
Updated by JERiveraMoya about 2 years ago
- Status changed from Workable to In Progress
Updated by jgwang about 2 years ago
I cloned the failed job(9681141) to run, and strange things have happened, the re-run jobs all passed:
- https://openqa.suse.de/tests/9720956#step/yast2_migration/15
- https://openqa.suse.de/tests/9720957#step/yast2_migration/15
- https://openqa.suse.de/tests/9720958#step/yast2_migration/15
- https://openqa.suse.de/tests/9720959#step/yast2_migration/15
I doubted that it was related to the setting of worker, so I cloned the job on the worker(9681141 failed on this worker), and everything worked well:
- https://openqa.suse.de/tests/9725164#step/yast2_migration/15
- https://openqa.suse.de/tests/9725165#step/yast2_migration/15
- https://openqa.suse.de/tests/9725166#step/yast2_migration/15
- https://openqa.suse.de/tests/9725168#step/yast2_migration/15
- https://openqa.suse.de/tests/9725169#step/yast2_migration/15
- https://openqa.suse.de/tests/9725170#step/yast2_migration/15
so the issue was not duplicated in the course of my investigation on it, it is strange and I don't why, anyway, this issue disappeared.
Updated by jgwang about 2 years ago
I got another question about needle tag in "wait_grub", please have a look at the code in function "wait_grub" from opensusebasetest.pm:
sub wait_grub {
...
my @tags;
...
push @tags, 'grub2';
...
push @tags, 'inst-bootmenu'
if (get_var('USBBOOT') && get_var('UEFI')
|| (check_var('ARCH', 'aarch64') && get_var('UEFI'))
|| get_var('OFW')
|| (check_var('BOOTFROM', 'd')));
...
assert_screen(\@tags, $bootloader_time);
....
elsif (match_has_tag('inst-bootmenu')) {
$self->wait_grub_to_boot_on_local_disk;
}
...
mutex_wait 'support_server_ready' if get_var('USE_SUPPORT_SERVER');
}
we created two needles "bootloader_uefi-20210301"(with inst-bootmenu tag) and "bootloader_uefi-grub2-20211009"(with grub2 tag) in the same background picture,under the background picture the above code in "wait_grub" matches either grub2 tag or inst-bootmenu tag which probably depends on alphabetical order of the needle name.
now in our job(such as 9720956) "assert_screen" matched "bootloader_uefi-20210301"(with inst-bootmenu tag) because of alphabetical order of the needle name, but maybe one day we won't be so lucky, "assert_screen" maybe match a needle with grub2 tag, this situation is not what we want.
so we need to think twice when create more than one needles in the same background picture.
Updated by jgwang about 2 years ago
I have committed the MR to change "machine" setting:
https://gitlab.suse.de/coolgw/wegao-test/-/merge_requests/154
Updated by jgwang about 2 years ago
jgwang wrote:
I have committed the MR to change "machine" setting:
https://gitlab.suse.de/coolgw/wegao-test/-/merge_requests/154
this MR was merged.
Updated by JERiveraMoya about 2 years ago
- Status changed from In Progress to Resolved