Project

General

Profile

Actions

action #51953

closed

action #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.

Status:
Resolved
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
2019-05-24
Due date:
% Done:

0%

Estimated time:

Description

We could use QEMU and qemu-uefi-aarch64 from Virtualization repo to get the latest and greatest improvements.

Actions #1

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? :)

Actions #2

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.

Actions #3

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?

Actions #4

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.

Actions #5

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

Actions #6

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

Actions #7

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?

Actions #8

Updated by ggardet_arm almost 5 years ago

Ok, let's close this ticket, if all is ok tomorrow morning.
Thanks.

Actions #9

Updated by okurz almost 5 years ago

  • Status changed from Feedback to Resolved

all still working fine

Actions

Also available in: Atom PDF