Bug 1180408 - Installation fails on aarch64 in openQA since snapshot 20201224
Installation fails on aarch64 in openQA since snapshot 20201224
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Installation
Current
aarch64 Other
: P5 - None : Major (vote)
: ---
Assigned To: Steffen Winterfeldt
Jiri Srain
https://openqa.opensuse.org/tests/152...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-12-28 15:17 UTC by Guillaume GARDET
Modified: 2021-01-07 13:45 UTC (History)
6 users (show)

See Also:
Found By: openQA
Services Priority:
Business Priority:
Blocker: Yes
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 2020-12-28 15:17:45 UTC
## Observation

openQA test in scenario opensuse-Tumbleweed-DVD-aarch64-create_hdd_gnome@aarch64 fails in
[await_install](https://openqa.opensuse.org/tests/1527346/modules/await_install/steps/135)

The problem is grub2-install cannot find EFI directory.

I suspect the yast2-storage-ng update: https://build.opensuse.org/request/show/858168

## Test suite description
image creation job used as parent for other jobs testing based on existing installation. GUI-Installation and selecting the gnome desktop during installation.



## Reproducible

Fails since (at least) Build [20201224](https://openqa.opensuse.org/tests/1526989)


## Expected result

Last good: [20201218](https://openqa.opensuse.org/tests/1515964) (or more recent)


## Further details

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensuse&flavor=DVD&machine=aarch64&test=create_hdd_gnome&version=Tumbleweed)
Comment 1 Josef Reidinger 2020-12-30 09:31:27 UTC
Yeah, partitioning is obviously wrong as it creates boot partition for legacy and not EFI partition as it should.

Ancor can you check why  it stop working?

Only suspicion thing I see is 

2020-12-25 15:54:07 <1> install(3175) [libstorage] Arch.cc(probe):127 arch:aarch64 ppc-mac:false ppc-pegasos:false ppc-power-nv:false efiboot:false page-size:4096

so it probably does not detect EFI in libstorage?
Comment 2 Fabian Vogt 2021-01-04 10:44:17 UTC
install.inf has "EFI: 0", so the issue is that linuxrc fails to detect the presence of EFI. This is because it uses the presence of "/sys/firmware/efi/vars" (https://github.com/openSUSE/linuxrc/blob/b256b24091d808d6a4fecd0e711e40d379f2f73d/linuxrc.c#L1081), which was dropped for non-x86 archs in kernel 5.10: https://github.com/torvalds/linux/commit/963fabf37f6a94214a823df0a785e653cb8ad6ea

Reassigning.
Comment 3 Guillaume GARDET 2021-01-05 14:35:58 UTC
The fix is trivial.
We need to check for '/sys/firmware/efi/efivars/' since '/sys/firmware/efi/vars/' is gone on non-x86 (and deprecated for a long time on x86).
Comment 4 Guillaume GARDET 2021-01-05 14:41:54 UTC
PR available: https://github.com/openSUSE/linuxrc/pull/237
Comment 5 Fabian Vogt 2021-01-05 14:44:08 UTC
(In reply to Guillaume GARDET from comment #3)
> The fix is trivial.
> We need to check for '/sys/firmware/efi/efivars/' since
> '/sys/firmware/efi/vars/' is gone on non-x86 (and deprecated for a long time
> on x86).

Not all systems have efivars, see bug 1174029.
Comment 6 Guillaume GARDET 2021-01-05 14:54:30 UTC
(In reply to Fabian Vogt from comment #5)
> Not all systems have efivars, see bug 1174029.

That's a separate issue, but thanks for the link.
My patch allows to get back to the pre-5.10 state, and will allow to have a working installer on proper EFI systems and will let Tumbleweed for Arm rolling again.
But I agree, using a proper detection (libefivars?) would probably be better.
Comment 7 Steffen Winterfeldt 2021-01-07 13:00:34 UTC
I've merged the pr from comment 4.

Thanks!