Project

General

Profile

Actions
Copy link

action #46868

closed

[aarch64][functional][y][migration] enable migration tests on aarch64

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

Status:
Resolved
Priority:
Normal
Assignee:
ggardet_arm
Category:
New test
Target version:
SUSE QA (private) - Milestone 23
Start date:
2019-01-30
Due date:
2019-03-12
% Done:

100%

Estimated time:
Difficulty:

Description

AArch64 tests do not include upgrade test at all.
Upgrade test should be enabled from Leap 15.0 to:

  • Tumbleweed
  • Leap 15.1

For this, we need to:
1) Have Leap 15.0 gnome and kde qcow2 images on o3
2) Enable update_leap_15.0_{gnome,kde} and zdup-leap-15.0-{gnome,kde} on Leap 15.1 and Tumbleweed tests

Related issues 5 (1 open — 4 closed)

Related to openQA Tests (public) - coordination #39302: [qe-core][functional][opensuse][epic][medium] uefi upgrade tests on TW+Leap (was: missing assets)New2018-08-08

Actions
Related to openQA Tests (public) - action #39305: [functional][u] 42.3 upgrade tests use GM image instead of updated oneResolvedSLindoMansilla2018-08-08

Actions
Related to openQA Tests (public) - action #36469: [opensuse][migration] Tumbleweed: Test upgrade path Leap 15.0 -> TumbleweedResolvedleli2018-05-23

Actions
Related to openQA Tests (public) - action #30385: [opensuse][migration]TW/zdup: version_switch_upgrade_target fails, as variables are not preparedRejectedtinawang1232018-01-16

Actions
Blocked by openQA Tests (public) - action #47303: [aarch64] 'eject_cd' does not workResolvedggardet_arm2019-02-08

Actions
Actions
Copy link
 #1

Updated by ggardet_arm almost 6 years ago

zdup-Leap-15.0-gnome must be fixed to use HDD_1=%DISTRI%-15.0-%ARCH%-GM-gnome@%MACHINE%.qcow2 instead of HDD_1=%DISTRI%-15.0-%ARCH%-267.2-gnome@%MACHINE%.qcow2 (replace 267.2 by GM)

aarch64 also requires to set UEFI_PFLASH_VARS

Actions
Copy link
 #2

Updated by okurz almost 6 years ago

  • Subject changed from [aarch64] enable migration tests on aarch64 to [aarch64][functional][y][migration] enable migration tests on aarch64
  • Description updated (diff)
  • Category set to New test
  • Status changed from New to In Progress
  • Assignee set to okurz
  • Target version set to Milestone 23

looking into the image names on o3

Actions
Copy link
 #3

Updated by okurz almost 6 years ago

  • Related to coordination #39302: [qe-core][functional][opensuse][epic][medium] uefi upgrade tests on TW+Leap (was: missing assets) added
Actions
Copy link
 #4

Updated by okurz almost 6 years ago

  • Related to action #39305: [functional][u] 42.3 upgrade tests use GM image instead of updated one added
Actions
Copy link
 #5

Updated by okurz almost 6 years ago

  • Related to action #36469: [opensuse][migration] Tumbleweed: Test upgrade path Leap 15.0 -> Tumbleweed added
Actions
Copy link
 #6

Updated by okurz almost 6 years ago

  • Related to action #30385: [opensuse][migration]TW/zdup: version_switch_upgrade_target fails, as variables are not prepared added
Actions
Copy link
 #7

Updated by okurz almost 6 years ago

  • Status changed from In Progress to Feedback

On https://openqa.opensuse.org/admin/assets when I search for "opensuse-15.0" I find:

hdd/opensuse-15.0-x86_64-GM-kde@64bit.qcow2
hdd/opensuse-15.0-x86_64-GM-gnome@64bit.qcow2
hdd/opensuse-15.0-x86_64-GM-cryptlvm@uefi.qcow2
hdd/opensuse-15.0-x86_64-267.2-gnome@64bit.qcow2
hdd/opensuse-15.0-x86_64-267.2-cryptlvm@uefi.qcow2
hdd/opensuse-15.0-x86_64-267.2-kde@64bit.qcow2

"267.2-gnome@64bit.qcow2" is actively used, last job opensuse-Tumbleweed-DVD-x86_64-Build20190126-zdup-Leap-15.0-gnome@64bit within openSUSE Tumbleweed. The file resides in the non-fixed directory. The "cryptlvm" and "kde" variants do not exist anymore. The jobs reference the ticket #39713 . It looks like we should be able to just use "opensuse-15.0-x86_64-GM-gnome@64bit.qcow2" instead and let the "267.2" be cleaned up by the gru task. The "GM" variant is also used by the according Leap upgrade jobs.

Triggered for testing:

openqa-clone-job --skip-chained-deps --within-instance https://openqa.opensuse.org 841596 _GROUP=0 TEST=zdup-Leap-15.0-gnome_from_GM_image_okurz_poo46868 HDD_1=opensuse-15.0-x86_64-GM-gnome@64bit.qcow2

-> https://openqa.opensuse.org/t842928

The job has passed the "firefox" module already so I guess it's good.

Actions
Copy link
 #8

Updated by okurz almost 6 years ago

  • Status changed from Feedback to Workable
  • Assignee changed from okurz to ggardet_arm

I changed the testsuite "zdup-Leap-15.0-gnome" to use the "GM" image now instead of "267.2".

@ggardet_arm back to you for the next step.

Actions
Copy link
 #10

Updated by ggardet_arm almost 6 years ago

UEFI_PFLASH_VARS and BOOTFROM=cdrom added to update_leap_15.0_gnome and zdup-leap-15.0-gnome

x86_64 does not need it, but it does not break existing x86_64 tests: https://openqa.opensuse.org/tests/843284

Actions
Copy link
 #11

Updated by okurz almost 6 years ago

Hm, these settings for UEFI_PFLASH_VARS in the test suite seem messy to me. But we can't put it in the machine, can we? Looks so messy to me. Maybe within the backend we can look for a qcow image with name of the HDD plus the suffix "-uefi-vars" dynamically? Would this work?

Actions
Copy link
 #12

Updated by ggardet_arm almost 6 years ago

okurz wrote:

Hm, these settings for UEFI_PFLASH_VARS in the test suite seem messy to me. But we can't put it in the machine, can we? Looks so messy to me. Maybe within the backend we can look for a qcow image with name of the HDD plus the suffix "-uefi-vars" dynamically? Would this work?

Why messy? It is how all tests using an HDD behave. You can check all extra_tests* tests.

No, we cannot put it in the machine as it would break other tests.

Looking for the name of the HDD plus the suffix "-uefi-vars" seems weird to me. Moreover, when HDD is empty, UEFI_PFLASH_VARS value is /usr/share/qemu/aavmf-aarch64-vars.bin

Actions
Copy link
 #13

Updated by ggardet_arm almost 6 years ago

Reverted BOOTFROM=cdrom as it breaks the test after the reboot, since it want to start the DVD again. Not sure how to solve this properly.

Actions
Copy link
 #14

Updated by ggardet_arm almost 6 years ago

Adding BOOTFROM=cdrom is ok on x86* but still fails on reboot for aarch64. The UEFI boot entry is: https://openqa.opensuse.org/tests/849299#step/grub_test/26 and accoring to the video and serial, it starts fwupdaa64.efi entry and then abort on exception (according to serial):

Memory Type Information settings change.
[Bds]Booting fwupdaa64.efi
FSOpen: Open '\EFI\opensuse\fwupdaa64.efi' Success
[Bds] Expand VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/HD(1,GPT,D036D25E-31B9-452C-BD87-4257E5ACB299,0x800,0xFA000)/\EFI\opensuse\fwupdaa64.efi -> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/HD(1,GPT,D036D25E-31B9-452C-BD87-4257E5ACB299,0x800,0xFA000)/\EFI\opensuse\fwupdaa64.efi
[Security] 3rd party image[0] can be loaded after EndOfDxe: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/HD(1,GPT,D036D25E-31B9-452C-BD87-4257E5ACB299,0x800,0xFA000)/\EFI\opensuse\fwupdaa64.efi.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BA5966C0
Loading driver at 0x000B8756000 EntryPoint=0x000B8757000
Loading driver at 0x000B8756000 EntryPoint=0x000B8757000 
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BA44ED18
ProtectUefiImageCommon - 0xBA5966C0
- 0x00000000B8756000 - 0x000000000000DE00
SetUefiImageMemoryAttributes - 0x00000000B8756000 - 0x0000000000001000 (0x0000000000004008)
SetUefiImageMemoryAttributes - 0x00000000B8757000 - 0x000000000000B000 (0x0000000000020008)
SetUefiImageMemoryAttributes - 0x00000000B8762000 - 0x0000000000002000 (0x0000000000004008)
Synchronous Exception at 0x00000000B875706C
PC 0x0000B875706C
PC 0x0000B87571E4
PC 0x0000B8757030
PC 0x0000BE96DF74 (0x0000BE967000+0x00006F74) [ 1] DxeCore.dll
PC 0x0000B82E2F5C (0x0000B82CB000+0x00017F5C) [ 2] UiApp.dll
PC 0x0000B82F5040 (0x0000B82CB000+0x0002A040) [ 2] UiApp.dll
PC 0x0000B82EAAD8 (0x0000B82CB000+0x0001FAD8) [ 2] UiApp.dll
PC 0x0000BBA91834 (0x0000BBA75000+0x0001C834) [ 3] SetupBrowser.dll
PC 0x0000BBA92610 (0x0000BBA75000+0x0001D610) [ 3] SetupBrowser.dll
PC 0x0000BBA77180 (0x0000BBA75000+0x00002180) [ 3] SetupBrowser.dll
PC 0x0000B82EC830 (0x0000B82CB000+0x00021830) [ 4] UiApp.dll
PC 0x0000B82F26CC (0x0000B82CB000+0x000276CC) [ 4] UiApp.dll
PC 0x0000BBA91834 (0x0000BBA75000+0x0001C834) [ 5] SetupBrowser.dll
PC 0x0000BBA92504 (0x0000BBA75000+0x0001D504) [ 5] SetupBrowser.dll
PC 0x0000BBA77180 (0x0000BBA75000+0x00002180) [ 5] SetupBrowser.dll
PC 0x0000B82CCDE0 (0x0000B82CB000+0x00001DE0) [ 6] UiApp.dll
PC 0x0000B82CE620 (0x0000B82CB000+0x00003620) [ 6] UiApp.dll
PC 0x0000B82CE544 (0x0000B82CB000+0x00003544) [ 6] UiApp.dll
PC 0x0000B82CC980 (0x0000B82CB000+0x00001980) [ 6] UiApp.dll
PC 0x0000B82CC064 (0x0000B82CB000+0x00001064) [ 6] UiApp.dll
PC 0x0000BE96DF74 (0x0000BE967000+0x00006F74) [ 7] DxeCore.dll
PC 0x0000BBA549F0 (0x0000BBA41000+0x000139F0) [ 8] BdsDxe.dll
PC 0x0000BBA42FFC (0x0000BBA41000+0x00001FFC) [ 8] BdsDxe.dll
PC 0x0000BBA44690 (0x0000BBA41000+0x00003690) [ 8] BdsDxe.dll
PC 0x0000BE96985C (0x0000BE967000+0x0000285C) [ 9] DxeCore.dll
PC 0x0000BE9687DC (0x0000BE967000+0x000017DC) [ 9] DxeCore.dll
PC 0x0000BE968024 (0x0000BE967000+0x00001024) [ 9] DxeCore.dll
[ 1] /home/abuild/rpmbuild/BUILD/ovmf-2017+git1510945757.b2662641d5/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
[ 2] /home/abuild/rpmbuild/BUILD/ovmf-2017+git1510945757.b2662641d5/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
[ 3] /home/abuild/rpmbuild/BUILD/ovmf-2017+git1510945757.b2662641d5/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe/DEBUG/SetupBrowser.dll
[ 4] /home/abuild/rpmbuild/BUILD/ovmf-2017+git1510945757.b2662641d5/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
[ 5] /home/abuild/rpmbuild/BUILD/ovmf-2017+git1510945757.b2662641d5/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe/DEBUG/SetupBrowser.dll
[ 6] /home/abuild/rpmbuild/BUILD/ovmf-2017+git1510945757.b2662641d5/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
[ 7] /home/abuild/rpmbuild/BUILD/ovmf-2017+git1510945757.b2662641d5/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
[ 8] /home/abuild/rpmbuild/BUILD/ovmf-2017+git1510945757.b2662641d5/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll
[ 9] /home/abuild/rpmbuild/BUILD/ovmf-2017+git1510945757.b2662641d5/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
X0 0xF94297A0F9029FA0   X1 0x0000000000000000   X2 0x00000000B8704D0C   X3 0x00000000BE9663E8
X4 0x0000000000000000   X5 0x00000000BBC369C8   X6 0x00000000B8762000   X7 0x0000000000000000
X8 0x00000000BC01F548   X9 0x0000000700000000  X10 0x00000000BA292000  X11 0x00000000BA425FFF
X12 0x0000000000000000  X13 0x0000000000000008  X14 0x0045005C003C0404  X15 0x006F005C00490046
X16 0x00000000BE966500  X17 0x00000000B7D2B400  X18 0x0000000000000000  X19 0x0000000000000013
X20 0x0000000000000000  X21 0x0000000000000000  X22 0x0000000000000000  X23 0x00000000BA44E198
X24 0x0000000000000000  X25 0x0000000000000000  X26 0x0000000000000000  X27 0x0000000000000000
X28 0x0000000000000000   FP 0x00000000BE966440   LR 0x00000000B87571E4  
V0 0xAFAFAFAFAFAFAFAF AFAFAFAFAFAFAFAF   V1 0x63732F6666666666 6666666666666666
V2 0x642F30406C656E6E 6168632F36406973   V3 0x0000000000000000 0000000000000000
V4 0x0000000000000000 0000000000000000   V5 0x4010040140100401 4010040140100401
V6 0x0000000000000000 0000000000000000   V7 0x0000000000000000 0000000000000000
V8 0x0000000000000000 0000000000000000   V9 0x0000000000000000 0000000000000000
V10 0x0000000000000000 0000000000000000  V11 0x0000000000000000 0000000000000000
V12 0x0000000000000000 0000000000000000  V13 0x0000000000000000 0000000000000000
V14 0x0000000000000000 0000000000000000  V15 0x0000000000000000 0000000000000000
V16 0x0000000000000000 0000000000000000  V17 0x0000000000000000 0000000000000000
V18 0x0000000000000000 0000000000000000  V19 0x0000000000000000 0000000000000000
V20 0x0000000000000000 0000000000000000  V21 0x0000000000000000 0000000000000000
V22 0x0000000000000000 0000000000000000  V23 0x0000000000000000 0000000000000000
V24 0x0000000000000000 0000000000000000  V25 0x0000000000000000 0000000000000000
V26 0x0000000000000000 0000000000000000  V27 0x0000000000000000 0000000000000000
V28 0x0000000000000000 0000000000000000  V29 0x0000000000000000 0000000000000000
V30 0x0000000000000000 0000000000000000  V31 0x0000000000000000 0000000000000000
SP 0x00000000BE966440  ELR 0x00000000B875706C  SPSR 0x80000205  FPSR 0x00000000
ESR 0x96000004          FAR 0xF94297A0F9029FE8
ESR : EC 0x25  IL 0x1  ISS 0x00000004
Data abort: Translation fault, zeroth level
Stack dump:
00000BE966340: 00000000BE966370 0000000000000010 00000000BE966380 00000000BBC308B4
00000BE966360: 00000000B8762468 00000000BBFFE1B0 00000000BE966380 0000000000000004
00000BE966380: 00000000BE9663A0 00000000BBC36BA0 800000000000000E 00000000BBFFE1B0
00000BE9663A0: 00000000BE966420 00000000B875C814 00000000BE966420 00000000BE966448
00000BE9663C0: 00000000BE966440 00000000BE96643C 00000000B8762468 00000000B8761878
00000BE9663E0: 00000000B8762428 0000000000000000 0000000000000000 00000000B8740018
00000BE966400: 00000000B870007C 0000000000000000 00000000B8AF69A0 800000000000000E
00000BE966420: 00000000BE966450 00000000B875C8B4 0000000000000000 00000000BE966478
> 00000BE966440: 00000000BE966480 00000000B87571E4 0000000000000000 0000000000000001
00000BE966460: 0000000000000000 0000000000009D78 0000000000000000 00000000BA5966C0
00000BE966480: 00000000BE9664E0 00000000B8757030 0000000000000013 0000000000000000
00000BE9664A0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
00000BE9664C0: 00000000BE966500 00000001BE96DE4C 0000000000000000 0000000000000000
00000BE9664E0: 00000000BE966500 00000000BE96DF74 00000000BA44E198 00000000BBFF0018
00000BE966500: 00000000BE966580 00000000B82E2F5C 00000000BE966530 00000000BE966678
00000BE966520: 00000000BE966680 00000000BA44E198 00000000BE966580 00000000B82E2ECC
ASSERT [ArmCpuDxe] /home/abuild/rpmbuild/BUILD/ovmf-2017+git1510945757.b2662641d5/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(271): ((BOOLEAN)(0==1))
Actions
Copy link
 #15

Updated by okurz almost 6 years ago

true, on the SLE machines that looks different as there is no "" folder and no "fwupdaa64.efi". A simple workaround might be in https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/opensusebasetest.pm#L318 to look for the right entry with send_key_until_needlematch instead of doing it blindly. An alternative might be to find out why the EFI partition content differs. Is this something coming from qemu VM parameters or depending on what is installed there in before? Because you created the images manually, maybe that's the cause?

Actions
Copy link
 #16

Updated by ggardet_arm almost 6 years ago

It seems that fwupdaa64.efi comes from the CDROM, not from HD. This test makes too much assumptions, I will try to rework this with proper send_key_until_needlematch.

Actions
Copy link
 #17

Updated by ggardet_arm almost 6 years ago

PR available to fix update_leap_15.0_Gnome (on aarch64 TW, at least) by selecting the right EFI payload: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6740

zdup-leap-15.0-gnome is broken because 'eject_cd' function does not work properly (eject cd0 in a plain qemu does work properly).

Actions
Copy link
 #18

Updated by ggardet_arm almost 6 years ago

  • Blocked by action #47303: [aarch64] 'eject_cd' does not work added
Actions
Copy link
 #19

Updated by ggardet_arm almost 6 years ago

PR available to fix zdup-Leap-15.0-gnome test in bootloader_uefi: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6747
But it shows a product bug (file conflict while zypper dup) later in zdup module: https://openqa.opensuse.org/tests/851998#step/zdup/245 but it a separate issue.

Actions
Copy link
 #20

Updated by ggardet_arm almost 6 years ago

  • Status changed from Workable to Feedback

Foursixnine uploaded 15.0 kde qcow2 image to hdd/fixed/ in o3.

Upgrade tests are now up for both gnome and kde in Tumbleweeed:

Also added to Leap 15.1 aarch64, but need to get a new snapshot to show up.

Actions
Copy link
 #21

Updated by okurz almost 6 years ago

  • Due date set to 2019-03-12
Actions
Copy link
 #22

Updated by ggardet_arm almost 6 years ago

  • % Done changed from 0 to 100

Leap 15.1 aarch64 test also run (showing product bugs):

Actions
Copy link
 #23

Updated by okurz almost 6 years ago

@ggardet_arm if you consider yourself done please set the ticket to "Resolved". Otherwise, is there anything you need help with?

Actions
Copy link
 #24

Updated by riafarov almost 6 years ago

  • Status changed from Feedback to Resolved

Looks like we are good here. @ggardet_arm feel free to create follow up tasks. It was not possible to resolve due to relation to #47303. Thanks for your work!

Actions
Copy link

Also available in: Atom PDF