aarch64.o.o did not come up after nightly upgrade
|Target version:||openQA Project - Current Sprint|
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.
#1 Updated by okurz about 1 month ago
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-lp22.214.171.124 from
zypper search --details kernel-default. In the new booted session I did
transactional-update shell and in there
zypper al kernel-default and
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-lp126.96.36.199 -> 044.2-lp188.8.131.52". 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.
- 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-lp184.108.40.206 -> 2.02-lp220.127.116.11 triggers the problem. I added the lock back.
- 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/