action #51953
closedaction #50447: [aarch64] Update aarch64 machine on o3
[aarch64] Use QEMU and qemu-uefi-aarch64 from Virtualization repo
Added by ggardet_arm almost 5 years ago. Updated almost 5 years ago.
0%
Description
We could use QEMU and qemu-uefi-aarch64 from Virtualization repo to get the latest and greatest improvements.
Updated by okurz almost 5 years ago
- Status changed from New to Feedback
- Assignee set to okurz
ggardet_arm wrote:
We could use QEMU and qemu-uefi-aarch64 from …
sure, we could, but shouldn't we rather rely on something more stable for the production environment? I would prefer to keep the latest released version of Leap as we try to have for all the workers and not have more differences than necessary. If the latest package in Leap would miss any updates then why not create maintenance updates? :)
Updated by ggardet_arm almost 5 years ago
Qemu update is not so important. What I miss are:
- qemu-uefi-aarch32 package installed
- up-to-date qemu-uefi-aarch64 which includes UEFI binaries with keys for secureboot testing.
I will try to get a maintenance update for the last one. I created https://bugzilla.opensuse.org/show_bug.cgi?id=1137216 for that.
Updated by okurz almost 5 years ago
cool. Ok, I can enable a repository and install from there on the worker however I am not quite sure which one: https://build.opensuse.org/project/show/Virtualization does not have aarch64 enabled for building against openSUSE_Leap_15.1 . We could add the "Factory_ARM" repo but that is probably a bit messy and may end up with problems, especially since we want to rely on the automatic updating of the worker. Also, I could not find qemu-uefi-aarch32 anywhere, e.g. https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=ALL&q=qemu-uefi-aarch32 does not list it anywhere. Is it actually built or was that rather a plan by you to do in the future?
Updated by ggardet_arm almost 5 years ago
qemu-uefi-aarch32 is built from armv7l, see: https://build.opensuse.org/package/binaries/Virtualization/ovmf/openSUSE_Factory_ARM
Let's see how the bug goes. If the update is not accepted, we should ask Virtualization project maintainers to enable build for aarch64 and armv7l. Otherwise, Factory_ARM will be ok for noarch packages.
Updated by okurz almost 5 years ago
well, the maintenance update involving SLE submission might take very long. You handle that in the bug, that is good. Still, we can add the repo on the aarch64 worker. So what I did:
zypper ar -f -p 105 https://download.opensuse.org/repositories/Virtualization/openSUSE_Factory_ARM/Virtualization.repo
transactional-update shell
in the transactional shell session:
# fix network
netconfig update -f
zypper -n in qemu-uefi-aarch32
exit
and rebooted the machine.
worker is up again and works on jobs fine
Updated by okurz almost 5 years ago
As discussed with ggardet_arm also installing qemu-uefi-aarch64 from the Virtualization repo:
transactional-update shell
netconfig update -f
zypper -n in qemu-uefi-aarch64-2019+git1552059899.89910a39dcfd-103.3
yields
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following package is going to be upgraded:
qemu-uefi-aarch64
The following package is going to change vendor:
qemu-uefi-aarch64 openSUSE -> obs://build.opensuse.org/Virtualization
1 package to upgrade, 1 to change vendor.
Overall download size: 11.5 MiB. Already cached: 0 B. After the operation, additional 264.0 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
Retrieving package qemu-uefi-aarch64-2019+git1552059899.89910a39dcfd-103.3.noarch (1/1), 11.5 MiB (394.0 MiB unpacked)
Retrieving: qemu-uefi-aarch64-2019+git1552059899.89910a39dcfd-103.3.noarch.rpm ............
…
rebooting
Updated by okurz almost 5 years ago
Booted and running fine.
@ggardet_arm I guess this is as much as we wanted to do. Let's at least wait out the nightly update cycle and see if that breaks anything. Otherwise we can close the ticket and await any further needed bigger changes which would actually demand a new qemu version and such, ok?
Updated by ggardet_arm almost 5 years ago
Ok, let's close this ticket, if all is ok tomorrow morning.
Thanks.