action #46868
closed[aarch64][functional][y][migration] enable migration tests on aarch64
Added by ggardet_arm over 5 years ago. Updated about 5 years ago.
100%
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
Updated by ggardet_arm over 5 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
Updated by okurz over 5 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
Updated by okurz over 5 years ago
- Related to coordination #39302: [qe-core][functional][opensuse][epic][medium] uefi upgrade tests on TW+Leap (was: missing assets) added
Updated by okurz over 5 years ago
- Related to action #39305: [functional][u] 42.3 upgrade tests use GM image instead of updated one added
Updated by okurz over 5 years ago
- Related to action #36469: [opensuse][migration] Tumbleweed: Test upgrade path Leap 15.0 -> Tumbleweed added
Updated by okurz over 5 years ago
- Related to action #30385: [opensuse][migration]TW/zdup: version_switch_upgrade_target fails, as variables are not prepared added
Updated by okurz over 5 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.
Updated by okurz over 5 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.
Updated by ggardet_arm over 5 years ago
aarch64 Leap 15.0 images of GNOME are now available on o3:
Updated by ggardet_arm over 5 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
Updated by okurz about 5 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?
Updated by ggardet_arm about 5 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
Updated by ggardet_arm about 5 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.
Updated by ggardet_arm about 5 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))
Updated by okurz about 5 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?
Updated by ggardet_arm about 5 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.
Updated by ggardet_arm about 5 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).
Updated by ggardet_arm about 5 years ago
- Blocked by action #47303: [aarch64] 'eject_cd' does not work added
Updated by ggardet_arm about 5 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.
Updated by ggardet_arm about 5 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:
update_leap_15.0_kde: https://openqa.opensuse.org/tests/854149update_leap_15.0_gnome: https://openqa.opensuse.org/tests/852366zdup-Leap-15.0-gnome: https://openqa.opensuse.org/tests/853604
Also added to Leap 15.1 aarch64, but need to get a new snapshot to show up.
Updated by ggardet_arm about 5 years ago
- % Done changed from 0 to 100
Leap 15.1 aarch64 test also run (showing product bugs):
- update_Leap_15.0_gnome: https://openqa.opensuse.org/tests/858295
- update_Leap_15.0_kde: https://openqa.opensuse.org/tests/858296
- zdup-Leap-15.0-gnome: https://openqa.opensuse.org/tests/858294
Updated by okurz about 5 years ago
@ggardet_arm if you consider yourself done please set the ticket to "Resolved". Otherwise, is there anything you need help with?
Updated by riafarov about 5 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!