Project

General

Profile

action #18228

[ppc64le][s390x][migration] test fails in boot_to_desktop_sym

Added by dgutu almost 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
High
Assignee:
okurz
Category:
Bugs in existing tests
Target version:
-
Start date:
2017-03-31
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario sle-12-SP3-Server-DVD-ppc64le-migration_offline_sle12_allpatterns_fullupdate@ppc64le fails in
boot_to_desktop_sym

Reproducible

Fails since (at least) Build 0303 (current job)

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest

Related issues

Related to openQA Tests - coordination #18964: [functional][epic][u]Bootloader/boot functions refactorResolved2017-10-182018-07-31

History

#1 Updated by okurz almost 6 years ago

  • Priority changed from Normal to Urgent

#2 Updated by maritawerner almost 6 years ago

Dumitru told me yesterday that he has already submitted a PR and he and Matthias are working on that?

#3 Updated by dgutu almost 6 years ago

PR was merged. Waiting for a running job.

#5 Updated by RBrownSUSE almost 6 years ago

  • Priority changed from Urgent to Immediate

Situation is not better in the current build, what is our next step?

#6 Updated by dgutu almost 6 years ago

The safe and fastest way is to revert the migration jobs for ppc and s390 to migrate without patching and leave x86 to make patching.
I had no way to test patch_before_migration on this 2 archs.
And I wanted to avoid modifying/changing s390x and ppc migration jobs for the obvious reason.
Should I revert the testsuite settings?

#7 Updated by dgutu almost 6 years ago

dgutu wrote:

The safe and fastest way is to revert the migration jobs for ppc and s390 to migrate without patching and leave x86 to make patching.
I had no way to test patch_before_migration on this 2 archs.
And I wanted to avoid modifying/changing s390x and ppc migration jobs for the obvious reason.
Should I revert the testsuite settings?

Not revering, looking into bootloader_ofw to adapt for today needs.

#8 Updated by dgutu almost 6 years ago

  • Status changed from New to In Progress

#9 Updated by dehai almost 6 years ago

s390x has also this issue with latest build.
https://openqa.suse.de/tests/858653#step/boot_to_desktop_sym/2

#11 Updated by dgutu almost 6 years ago

Preparing to test the PR on ppc machine.

#12 Updated by okurz almost 6 years ago

  • Subject changed from [ppc64le] test fails in boot_to_desktop_sym to [ppc64le][s390x][migration] test fails in boot_to_desktop_sym

#14 Updated by okurz almost 6 years ago

https://openqa.suse.de/tests/872179 is passing way over the previously failing steps so I guess we are done here for s390x. Now for ppc64le. dgutu: an "immediate" ticket deserves an update at least once a day.

#15 Updated by dgutu almost 6 years ago

  • Status changed from In Progress to Feedback
  • Assignee deleted (dgutu)

At the moment I could not find any solution or workaround for ppc because:

  • When I need to patch I want to boot the HDD, so I use BOOTFROM=d or BOOT_HDD_IMAGE=1
  1. If using BOOTFROM=d then ofw will never permit to boot the grub from HDD, it will reboot always into the bootloader of installation media.
  2. If using BOOT_HDD_IMAGE=1 the ofw boots only the grub from HDD and the patching steps are running fine but once you want to reboot patched system you will never get the installer bootloader...the ofw will but always from hdd(which makes offline upgrade impossible).
  3. If I don't use any of the methods above then the system boots from installation media and then instructed by bootloader_ofw.pm reboots into hdd and finds the grub and again the patching steps are running fine. Again, after patching system need to reboot into installer which doesn't happen, we always get the hdd boot.

This boot order is decided on the os-autoinst level. Playing with set_var on some step before reboot doesn't work.

Everything described above works fine for clean install and online migration.

#16 Updated by dgutu almost 6 years ago

  • Status changed from Feedback to In Progress

#17 Updated by mitiao almost 6 years ago

If the boot order on power is decided on the os-autoinst level, who can give a help to resolve it?
This issue blocks all offline migration of ppc64le.

#18 Updated by maritawerner almost 6 years ago

  • Assignee set to dzedro

Jozef, do you have time to look into that?

#19 Updated by dzedro almost 6 years ago

I updated two ppc64le tests, they were using x86_64 images
Created bug for ppc64le https://bugzilla.suse.com/show_bug.cgi?id=1035428
And created workaround PR
Some ppc64le migration tests are missing BOOTFROM=d, offline migration have to always boot cd-rom (d)
to continue with installation on reboot_and_install, that is also solution for poo#18580

#20 Updated by dzedro almost 6 years ago

BOOTFROM=d has to be used with reboot_and_install, to do patch or check before installation and then start installation
That is also the purpose of reboot_and_install to reboot and start installation, e.g. zdup does not need BOOTFROM=d as
it's upgrading running system.

#21 Updated by dzedro almost 6 years ago

I cloned one type of each ppc64le migration with my changes.
I would consider this fixed with new build, I tested it with various tests that could get broken,
but maybe I missed something.

migration_offline
migration_zdup_offline
om_proxyscc

#22 Updated by okurz almost 6 years ago

  • Related to coordination #18964: [functional][epic][u]Bootloader/boot functions refactor added

#23 Updated by dzedro almost 6 years ago

  • Assignee changed from dzedro to okurz

As I wrote in PR, boot is handled in previous test reboot_and_install on SLE zdup test
https://openqa.suse.de/tests/924736#step/setup_zdup/4
On openSUSE it is different, okurz please take over.

#24 Updated by okurz almost 6 years ago

#25 Updated by okurz almost 6 years ago

merged, test retriggered as https://openqa.suse.de/tests/926031#live

#26 Updated by okurz almost 6 years ago

  • Priority changed from Immediate to High

originally reported scenario works now: https://openqa.suse.de/tests/924958

reducing prio.

#28 Updated by okurz almost 6 years ago

Hm, in this case it seems the correct bootloader menue is shown before it is catched so https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2867

#29 Updated by okurz almost 6 years ago

The scenarios that previously where stuck in setup_zdup now progress further until the last test module "grub_test_snapshot" where still the inst-bootmenu is shown when it's not expected.

Working on that.

#30 Updated by okurz almost 6 years ago

  • Status changed from In Progress to Resolved

Cleanup of too many needles and initial rework of how the bootmenu is looked for fixed the grub_test_snapshot module as well.

I consider myself done here with

These jobs were wrongly labeled. I deleted the existing labels.

#31 Updated by JWSun almost 6 years ago

okurz wrote:

The scenarios that previously where stuck in setup_zdup now progress further until the last test module "grub_test_snapshot" where still the inst-bootmenu is shown when it's not expected.

Working on that.

I found "grub_test_snapshot" failed again on build 0393.
https://openqa.suse.de/tests/946810#step/grub_test_snapshot/14

#33 Updated by okurz almost 6 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: migration_zdup_offline_sle12sp2_ha+allpatterns_fullupdate_ppc
https://openqa.suse.de/tests/980552

Also available in: Atom PDF