Bug 1101023 - In openQA 'grub2' test fails for aarch64 ISO (DVD+NET) because UEFI bootloader does not find openSUSE from HDD
In openQA 'grub2' test fails for aarch64 ISO (DVD+NET) because UEFI bootload...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Installation
Current
aarch64 Other
: P5 - None : Critical (vote)
: ---
Assigned To: Gary Ching-Pang Lin
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-07-12 12:29 UTC by Guillaume GARDET
Modified: 2020-07-26 16:29 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume GARDET 2018-07-12 12:29:34 UTC
In openQA, 'grub2' test fail for aarch64 ISO (DVD+NET) because UEFI bootloader does not find installed openSUSE from HDD.

Example of test failure: 
https://openqa.opensuse.org/tests/overview?distri=opensuse&version=Tumbleweed&build=20180709&groupid=3

In a broken system, we get from UEFI on serial0.txt:
[Bds]=============Begin Load Options Dumping ...=============
  Driver Options:
  SysPrep Options:
  Boot Options:
    Boot0000: UiApp 		 0x0109
    Boot0001: UEFI QEMU QEMU CD-ROM  		 0x0001
    Boot0002: UEFI Misc Device 		 0x0001
    Boot0003: UEFI Misc Device 2 		 0x0001
    Boot0004: UEFI Misc Device 3 		 0x0001
    Boot0005: UEFI PXEv4 (MAC:525400123456) 		 0x0001
    Boot0006: EFI Internal Shell 		 0x0001
  PlatformRecovery Options:
    PlatformRecovery0000: Default PlatformRecovery 		 0x0001
[Bds]=============End Load Options Dumping=============

Whereas, we should get:
[Bds]=============Begin Load Options Dumping ...=============
  Driver Options:
  SysPrep Options:
  Boot Options:
    Boot0007: opensuse 		 0x0001
    Boot0000: UiApp 		 0x0109
    Boot0001: UEFI QEMU QEMU CD-ROM  		 0x0001
    Boot0002: UEFI Misc Device 		 0x0001
    Boot0003: UEFI Misc Device 2 		 0x0001
    Boot0004: UEFI Misc Device 3 		 0x0001
    Boot0005: UEFI PXEv4 (MAC:525400123456) 		 0x0001
    Boot0006: EFI Internal Shell 		 0x0001
  PlatformRecovery Options:
    PlatformRecovery0000: Default PlatformRecovery 		 0x0001
[Bds]=============End Load Options Dumping=============

Note the 'opensuse' entry we are missing now.

Snapshot Build20180625 was fine and snapshot Build20180704 (and later) are broken.
Comment 1 Guillaume GARDET 2018-07-13 13:58:48 UTC
I reproduced the problem locally and compared the broken installation with the working installation.
Partitions are fines and EFI/opensuse/grubaa64.efi file is there.

According to y2log from openQA https://openqa.opensuse.org/tests/705940#downloads :
  2018-07-12 21:05:29 <1> linux-r5my(2901) [Ruby] lib/cheetah.rb:158 Executing "/usr/sbin/grub2-install --target\=arm64-efi --force --skip-fs-probe".
  2018-07-12 21:05:29 <3> linux-r5my(2901) [Ruby] lib/cheetah.rb:206 Error output: Installing for arm64-efi platform.
  2018-07-12 21:05:30 <3> linux-r5my(2901) [Ruby] lib/cheetah.rb:206 Error output: Could not prepare Boot variable: Function not implemented
  2018-07-12 21:05:30 <3> linux-r5my(2901) [Ruby] lib/cheetah.rb:206 Error output: Installation finished. No error reported.

So, there is something wrong with EFI on installation.
Comment 2 Guillaume GARDET 2018-07-13 14:51:30 UTC
For the record, openSUSE:Factory:ARM/efivar has been updated from version 31 to 36 (and efibootmgr uses it). It could be the cause.

It may be related to this bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1100077
Comment 3 Gary Ching-Pang Lin 2018-07-16 04:21:23 UTC
It's caused by the efivar update. In efivar 36, it makes the device parsers mandatory. However, the device parsers are flawed in several cases and caused some troubles. Since fwupd needs efivar >= 34, one possible workaround is to downgrade efivar to 35 and fix the bugs in 36 later.
Comment 4 Gary Ching-Pang Lin 2018-07-19 03:00:59 UTC
I created an AArch64 VM with the following command:

qemu-system-aarch64 -enable-kvm -m 1024 -cpu host \
  -machine virt,usb=off,its=off \
  -bios qemu-uefi-aarch64.bin \
  -S \
  -serial file:serial.log \
  -monitor stdio \
  -device virtio-gpu-pci \
  -vnc :94,share=force-shared \
  -device usb-ehci -device usb-kbd -device usb-tablet \
  -device virtio-scsi-pci,id=scsi0 \
  -device virtio-blk-device,drive=hd1,bootindex=0,serial=1 \
  -drive file=disk.img,cache=unsafe,if=none,id=hd1,format=qcow2,discard=on

After installing Tumbleweed 20180709, the bug can be reproduced reliably with

# efibootmgr -c -d /dev/vda1 -l "\\EFI\\opensuse\\grubaa64.efi" -v -v -v

I always got this error message:

linux.c:454 device_get(): unknown storage interface: Succes

efivar probably has the problem to recognize virtio-blk in AArch64.
Comment 5 Gary Ching-Pang Lin 2018-07-19 04:04:38 UTC
I filed the upstream bug:
https://github.com/rhboot/efivar/issues/113
Comment 6 Gary Ching-Pang Lin 2018-07-20 04:37:45 UTC
This bug is actually fixed in the efivar git HEAD. It introduced a new ACPI root parser which can parse the path correctly. So, at least efivar 37 won't break virtio-blk in ARM64.
Comment 7 Dirk Mueller 2018-07-21 10:13:51 UTC
I've temporarily reverted to efivar 31 in openSUSE:Factory:ARM to mitigate this issue
Comment 8 Guillaume GARDET 2018-07-23 06:48:43 UTC
(In reply to Dirk Mueller from comment #7)
> I've temporarily reverted to efivar 31 in openSUSE:Factory:ARM to mitigate
> this issue

Gary mentioned that 'fwupd needs efivar >= 34' so, 31 is not suitable.
'efivar revert to 35' finally reached Factory, so we can just update Factory:ARM to the latest snapshot.
Comment 9 Guillaume GARDET 2018-07-24 06:53:33 UTC
Reverting to efivar 35 fixed the boot in openQA Tumbleweed snapshot 20180722:
https://openqa.opensuse.org/tests/overview?distri=opensuse&version=Tumbleweed&build=20180722&groupid=3

efivar 36 must be skipped and next efivar (37) should be ok since upstream fixed it in current master.
Comment 11 Swamp Workflow Management 2020-07-22 10:21:02 UTC
SUSE-RU-2020:2000-1: An update that has four recommended fixes can now be installed.

Category: recommended (important)
Bug References: 1100077,1101023,1120862,1127544
CVE References: 
Sources used:
SUSE Linux Enterprise Module for Basesystem 15-SP2 (src):    efivar-37-6.3.1
SUSE Linux Enterprise Module for Basesystem 15-SP1 (src):    efivar-37-6.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 12 Swamp Workflow Management 2020-07-26 16:26:55 UTC
openSUSE-RU-2020:1069-1: An update that has four recommended fixes can now be installed.

Category: recommended (important)
Bug References: 1100077,1101023,1120862,1127544
CVE References: 
Sources used:
openSUSE Leap 15.1 (src):    efivar-37-lp151.2.3.1
Comment 13 Swamp Workflow Management 2020-07-26 16:29:09 UTC
openSUSE-RU-2020:1073-1: An update that has four recommended fixes can now be installed.

Category: recommended (important)
Bug References: 1100077,1101023,1120862,1127544
CVE References: 
Sources used:
openSUSE Leap 15.2 (src):    efivar-37-lp152.3.3.1