action #62102

aarch64.o.o did not come up after nightly upgrade

Added by okurz about 1 month ago. Updated 20 days ago.

Status:WorkableStart date:14/01/2020
Priority:NormalDue date:
Assignee:okurz% Done:

0%

Category:-
Target version:openQA Project - Current Sprint
Duration:

Description

after nightly upgrade I received the email alert from my ping test. Power cycling does not help as the kernel can not but. Something about an unreferenced symbol or something. Booting older snapshot from grub menu selected over ipmi SOL.

History

#1 Updated by okurz about 1 month ago

Trying with transactional-upgrade dup && reboot ends up in the same.

Message when trying to load the kernel:

Loading Linux 4.12.14-lp151.28.36-default ...
error: symbol `grub_efi_allocate_any_pages' not found.
Loading initial ramdisk ...                           
error: symbol `grub_efi_allocate_any_pages' not found.

and then returns to grub.

Booted into a snapshot once again and trying with an older kernel: transactional-update pkg install kernel-default-4.12.14-lp151.28.32.1 from zypper search --details kernel-default. In the new booted session I did transactional-update shell and in there zypper al kernel-default and zypper dup.

Still failed to boot, problem is not in kernel. Retrying with zypper al grub2 grub2-arm64-efi dracut. Also did a zypper patch and reboot as well as zypper dup and reboot. This worked so far. Removed lock from dracut and trying upgrade: "dracut 044.2-lp151.2.3.1 -> 044.2-lp151.2.9.1". dracut was also fine, trying grub2. grub2 also fine, so it's most likely grub2-arm64-efi or it was a transient problem fixed by the multiple reinstalls and reboots. I will let the system be for now as it's pretty busy with testing.

#2 Updated by okurz 24 days ago

  • Status changed from In Progress to Blocked

Currently no tests running, executing zypper rl grub2-arm64-efi && transactional-update dup reboot. Failed again.
The upgrade grub2-arm64-efi 2.02-lp151.21.6.1 -> 2.02-lp151.21.9.1 triggers the problem. I added the lock back.

Reported bug https://bugzilla.opensuse.org/show_bug.cgi?id=1162320

#3 Updated by okurz 20 days ago

  • Status changed from Blocked to Workable

We can apply the workaround as mentioned in https://bugzilla.opensuse.org/show_bug.cgi?id=1122591#c28 :

cd /boot/grub2
mv arm64-efi arm64-efi.bk
btrfs subvolume create /boot/grub2/arm64-efi
cp -r arm64-efi.bk/* arm64-efi/

Also available in: Atom PDF