Project

General

Profile

Actions
Copy link

action #18228

closed

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

Added by dgutu about 8 years ago. Updated almost 8 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 1 (0 open — 1 closed)

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

Actions
Actions
Copy link
 #1

Updated by okurz about 8 years ago

  • Priority changed from Normal to Urgent
Actions
Copy link
 #2

Updated by maritawerner about 8 years ago

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

Actions
Copy link
 #3

Updated by dgutu about 8 years ago

PR was merged. Waiting for a running job.

Actions
Copy link
 #5

Updated by RBrownSUSE about 8 years ago

  • Priority changed from Urgent to Immediate

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

Actions
Copy link
 #6

Updated by dgutu about 8 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?

Actions
Copy link
 #7

Updated by dgutu about 8 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.

Actions
Copy link
 #8

Updated by dgutu about 8 years ago

  • Status changed from New to In Progress
Actions
Copy link
 #9

Updated by dehai about 8 years ago

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

Actions
Copy link
 #11

Updated by dgutu about 8 years ago

Preparing to test the PR on ppc machine.

Actions
Copy link
 #12

Updated by okurz about 8 years ago

  • Subject changed from [ppc64le] test fails in boot_to_desktop_sym to [ppc64le][s390x][migration] test fails in boot_to_desktop_sym
Actions
Copy link
 #14

Updated by okurz about 8 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.

Actions
Copy link
 #15

Updated by dgutu about 8 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.

Actions
Copy link
 #16

Updated by dgutu about 8 years ago

  • Status changed from Feedback to In Progress
Actions
Copy link
 #17

Updated by mitiao about 8 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.

Actions
Copy link
 #18

Updated by maritawerner about 8 years ago

  • Assignee set to dzedro

Jozef, do you have time to look into that?

Actions
Copy link
 #19

Updated by dzedro about 8 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

Actions
Copy link
 #20

Updated by dzedro about 8 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.

Actions
Copy link
 #21

Updated by dzedro about 8 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

Actions
Copy link
 #22

Updated by okurz about 8 years ago

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

Updated by dzedro about 8 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.

Actions
Copy link
 #24

Updated by okurz about 8 years ago

Actions
Copy link
 #25

Updated by okurz about 8 years ago

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

Actions
Copy link
 #26

Updated by okurz about 8 years ago

  • Priority changed from Immediate to High

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

reducing prio.

Actions
Copy link
 #28

Updated by okurz almost 8 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

Actions
Copy link
 #29

Updated by okurz almost 8 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.

Actions
Copy link
 #30

Updated by okurz almost 8 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.

Actions
Copy link
 #31

Updated by JWSun almost 8 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

Actions
Copy link
 #33

Updated by okurz almost 8 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

Actions
Copy link

Also available in: Atom PDF