ARMv7 build has been broken in private OBS instance
Hi, I am running a private OBS instance with an ARM worker based on Cortex-A53 board. obs-api-2.10.10-lp152.63.1.noarch Worker version is obs-worker-2.11~alpha.20210609T113256.127f886c97-12468.1.noarch Everything worked fine until today I found that the worker is broken. It cannot boot the KVM machine. I see the silence after: [ 32s] /usr/bin/qemu-system-aarch64 -nodefaults -no-reboot -nographic -vga none -cpu host,aarch64=off -enable-kvm -M virt,gic-version=host -object rng-random,filename=/dev/random,id=rng0 -device virtio-rng-device,rng=rng0 -runas qemu -net none -kernel /var/cache/obs/worker/root_1/.mount/boot/kernel -initrd /var/cache/obs/worker/root_1/.mount/boot/initrd -append root=/dev/disk/by-id/virtio-0 rootfstype=ext4 rootflags=noatime ext4.allow_unsupported=1 mitigations=off panic=1 quiet no-kvmclock elevator=noop nmi_watchdog=0 rw rd.driver.pre=binfmt_misc console=ttyAMA0 init=/.build/build -m 3072 -drive file=/var/cache/obs/worker/root_1/root,format=raw,if=none,id=disk,cache=unsafe -device virtio-blk-device,drive=disk,serial=0 -drive file=/var/cache/obs/worker/root_1/swap,format=raw,if=none,id=swap,cache=unsafe -device virtio-blk-device,drive=swap,serial=1 -serial stdio -chardev socket,id=monitor,server,nowait,path=/var/cache/obs/worker/root_1/root.qemu/monitor -mon chardev=monitor,mode=readline -smp 4 Then I've found that kernel and initrd images are for aarch64 architecture in spite of -cpu host,aarch64=off argument. This is a case of my qemu failure. I suppose this is somehow connected to the new upstream OBS ARM workers, which are not able to run armv7 kernels inside VMs. Is it a known issue? How could I recover service operation? -- With best regards, Matwey V. Kornilov
20.07.2021 11:47, Matwey V. Kornilov пишет:
Hi,
I am running a private OBS instance with an ARM worker based on Cortex-A53 board.
obs-api-2.10.10-lp152.63.1.noarch
Worker version is
obs-worker-2.11~alpha.20210609T113256.127f886c97-12468.1.noarch
Everything worked fine until today I found that the worker is broken. It cannot boot the KVM machine. I see the silence after:
[ 32s] /usr/bin/qemu-system-aarch64 -nodefaults -no-reboot -nographic -vga none -cpu host,aarch64=off -enable-kvm -M virt,gic-version=host -object rng-random,filename=/dev/random,id=rng0 -device virtio-rng-device,rng=rng0 -runas qemu -net none -kernel /var/cache/obs/worker/root_1/.mount/boot/kernel -initrd /var/cache/obs/worker/root_1/.mount/boot/initrd -append root=/dev/disk/by-id/virtio-0 rootfstype=ext4 rootflags=noatime ext4.allow_unsupported=1 mitigations=off panic=1 quiet no-kvmclock elevator=noop nmi_watchdog=0 rw rd.driver.pre=binfmt_misc console=ttyAMA0 init=/.build/build -m 3072 -drive file=/var/cache/obs/worker/root_1/root,format=raw,if=none,id=disk,cache=unsafe -device virtio-blk-device,drive=disk,serial=0 -drive file=/var/cache/obs/worker/root_1/swap,format=raw,if=none,id=swap,cache=unsafe -device virtio-blk-device,drive=swap,serial=1 -serial stdio -chardev socket,id=monitor,server,nowait,path=/var/cache/obs/worker/root_1/root.qemu/monitor -mon chardev=monitor,mode=readline -smp 4
Then I've found that kernel and initrd images are for aarch64 architecture in spite of -cpu host,aarch64=off argument. This is a case of my qemu failure. I suppose this is somehow connected to the new upstream OBS ARM workers, which are not able to run armv7 kernels inside VMs.
Is it a known issue? How could I recover service operation?
I suppose that 4cfdac5d77790105bb9d7a9a0491a17a09dc7854 should be backported to 2.10 branch to fix this issue.
Hey, On 20.07.21 10:47, Matwey V. Kornilov wrote:
Is it a known issue? How could I recover service operation?
Not sure about your problem but have a look at the thread ARM-32 builds not working on ARM-64 machine, again from a couple of days ago. Kyle mentioned he needed to backport a patch. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
22.07.2021 13:42, Henne Vogelsang пишет:
Hey,
On 20.07.21 10:47, Matwey V. Kornilov wrote:
Is it a known issue? How could I recover service operation?
Not sure about your problem but have a look at the thread
ARM-32 builds not working on ARM-64 machine, again
from a couple of days ago. Kyle mentioned he needed to backport a patch.
Henne
Yes, I saw this. But that thread is unrelated to my issue.
20.07.2021 11:47, Matwey V. Kornilov пишет:
Hi,
I am running a private OBS instance with an ARM worker based on Cortex-A53 board.
obs-api-2.10.10-lp152.63.1.noarch
I updated to obs-api-2.10.11-lp152.78.3.noarch and the issue still remains here.
Worker version is
obs-worker-2.11~alpha.20210609T113256.127f886c97-12468.1.noarch
Everything worked fine until today I found that the worker is broken. It cannot boot the KVM machine. I see the silence after:
[ 32s] /usr/bin/qemu-system-aarch64 -nodefaults -no-reboot -nographic -vga none -cpu host,aarch64=off -enable-kvm -M virt,gic-version=host -object rng-random,filename=/dev/random,id=rng0 -device virtio-rng-device,rng=rng0 -runas qemu -net none -kernel /var/cache/obs/worker/root_1/.mount/boot/kernel -initrd /var/cache/obs/worker/root_1/.mount/boot/initrd -append root=/dev/disk/by-id/virtio-0 rootfstype=ext4 rootflags=noatime ext4.allow_unsupported=1 mitigations=off panic=1 quiet no-kvmclock elevator=noop nmi_watchdog=0 rw rd.driver.pre=binfmt_misc console=ttyAMA0 init=/.build/build -m 3072 -drive file=/var/cache/obs/worker/root_1/root,format=raw,if=none,id=disk,cache=unsafe -device virtio-blk-device,drive=disk,serial=0 -drive file=/var/cache/obs/worker/root_1/swap,format=raw,if=none,id=swap,cache=unsafe -device virtio-blk-device,drive=swap,serial=1 -serial stdio -chardev socket,id=monitor,server,nowait,path=/var/cache/obs/worker/root_1/root.qemu/monitor -mon chardev=monitor,mode=readline -smp 4
Then I've found that kernel and initrd images are for aarch64 architecture in spite of -cpu host,aarch64=off argument. This is a case of my qemu failure. I suppose this is somehow connected to the new upstream OBS ARM workers, which are not able to run armv7 kernels inside VMs.
Is it a known issue? How could I recover service operation?
participants (2)
-
Henne Vogelsang -
Matwey V. Kornilov