ARM64 server gets stuck on "bpfilter write fail: -32" when activating Linuxkit (Alpine). #198
Comments
howard-yeh
changed the title
|
Hey @howard-yeh, thanks for reporting this. I've been able to reproduce this locally. I have found linuxkit/linuxkit#3701. I'm going to change some kernel configs and test. Will update here. Also, going to move this issue to the Hook repo.. |
|
This may be more cosmetc than it seems, I am trying to image a RPi4 and I saw the same mesages. I'm not sure what else fails, but for me, once I set the time to be correct-ish, it downloaded the images immediately and tried to image my disk. I have another issue with that, but I wonder if setting the time is a workaround that works for you? |
|
Hi @jacobweinstock , thanks for replying this. |
|
Just that I ran |
|
@ClashTheBunny In my case, the system time is correct, but the error still ran out. Anyway, thanks for your feedback =) |
|
@jacobweinstock Got the same, but on QEMU/KVM arm64 VM. Other VMs run Linux normally on the same host. Here's a complete bootlog: and then hangs. This is the VM libvirt xml definition: <domain type="kvm" xmlns:ns2="http://libosinfo.org/xmlns/libvirt/domain/1.0">
<name>demo.local</name>
<cpu check="partial" mode="host-passthrough">
<topology cores="2" dies="1" sockets="1" threads="1"/>
</cpu>
<currentMemory unit="KiB">8388608</currentMemory>
<features>
<acpi/>
</features>
<memory unit="KiB">8388608</memory>
<os>
<type arch="aarch64" machine="virt">hvm</type>
<loader readonly="yes" type="pflash">/usr/share/AAVMF/AAVMF_CODE.fd</loader>
<nvram>/var/lib/libvirt/qemu/nvram/demo.local_VARS.fd</nvram>
</os>
<resource>
<partition>/machine</partition>
</resource>
<vcpu>2</vcpu>
<clock offset="utc"/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<video>
<model type="none"/>
</video>
<controller model="none" type="usb"/>
<channel type="unix">
<target name="org.qemu.guest_agent.0" type="virtio"/>
</channel>
<rng model="virtio">
<backend model="random">/dev/urandom</backend>
<driver model="virtio-transitional"/>
</rng>
<memballoon model="virtio-transitional"/>
<input bus="virtio" type="mouse"/>
<input bus="virtio" type="keyboard"/>
<console type="pty">
<target port="0" type="serial"/>
</console>
<disk device="disk" type="file">
<driver cache="unsafe" name="qemu" type="qcow2"/>
<source file="/var/lib/libvirt/images/demo.local/root__pxeuefi_arm64.qcow2"/>
<target bus="virtio" dev="vda"/>
<serial>root_disk_serial</serial>
</disk>
<disk device="disk" model="virtio-transitional" type="file">
<driver name="qemu" type="raw"/>
<source file="/var/lib/libvirt/images/demo.local/demo.local.cidata.iso"/>
<target bus="virtio" dev="vdb"/>
<readonly/>
<serial>cidata_serial</serial>
</disk>
<interface type="bridge">
<mac address="52:54:00:01:03:01"/>
<source bridge="lan"/>
<model type="virtio"/>
<link state="up"/>
<boot order="1"/>
</interface>
</devices>
</domain>I see the kernel is of slightly advanced age (5.10.85) -- any way I can help update this? Alternatively, I'm an Armbian developer, and was considering that maybe Armbian could provide a kernel & initrd for Tinkerbell -- across multiple/all architectures, and offering an easy vendor/custom kernel solution, somewhat becoming the "3rd OSIE" -- is this something you find interesting? |
That sounds useful. I'd love to see a PoC that demonstrates it in action. On the issue, there's a post in Ubuntu forums about the same error message https://ubuntuforums.org/showthread.php?t=2472909. I don't know if its the same problem but trying to update the kernel to 5.19 seems like a worthwhile exercise. |
I made a thinko: what hook needs is a container image with the kernel vmlinuz and modules; linuxkit itself generates the initrd. Thus there'd be no "3rd OSIE", just a different set of possible kernels+modules for Hook itself.
I'm working on something generic that can take kernels from Debian/Ubuntu/Armbian and prepare the needed bits for Hook/linuxkit. I'm pretty sure this could work for EFI kernels & bootloaders across both x86 and aarch64 -- I'm uncertain about non-EFI booting (eg u-boot PXE with a DTB / fdt, and how that relates to iPXE on aarch64), but let's assume that's out of scope. Also, before digging into using an external kernel, I took a dive into the |
|
|
Hey @howard-yeh and @ClashTheBunny. We just landed some big changes to how we build HookOS, thanks to @rpardini ! The latest development release (https://github.com/tinkerbell/hook/releases/tag/latest) is working for me. Mind trying with this If/when you have some cycles to test? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I provisioned the ARM64 server, the admin console stucked with the following error messages
[ 21.345242] arm_spe_pmu arm,spe-v1: profiling buffer inaccessible. Try passing "kpti=off" on the kernel command line
[ 21.364371] arm_spe_pmu: probe of arm,spe-v1 failed with error -1
and it stucks looping in "bpfilter: write fail -32".
Here's the related issue that I found: AmpereComputing/ampere-lts-kernel#21
Is there any possible solution for this case?
BTW, the x86 server can be provisioned correctly.
Expected Behaviour
Activate hook-bookit and hook-docker containers and enter os console.
Steps to Reproduce (for bugs)
Your Environment
Tinkerbell version: Latest (v0.4.2)
Arch: ARM64v8
The text was updated successfully, but these errors were encountered: