Hello,
I have successfully converted a Debian 12 image (nocloud-arm64) to a fresh dietpi image. It boots using arm64 kvm and qemu emulation. But with KVM it is at least 10x faster.
Could you folks let me know if anyone is interested? I will then share the image.
It was not so straightforward as after my first attempts, networking did not work (but now it does). Maybe if there is sufficient interest, it would be worth adding this image?
Cheers!
1 Like
As I understand, the image would be used e.g. within Proxmox on Raspberries etc.
I assume there are only few users having this environment.
Or any type of virtualized environment on ARM. I have been using it on an rk3588 with virt-manager.
1 Like
Hello,
I have installed Proxmox for ARM64 under DietPiOS on a Raspberry Pi 5 and use it to run various ARM64 VMs, mainly under DietPiOS (e.g. a DietPiOS ARM64 VM with Openmediavault 7.X installed).
You can also generate various ParrotOS.6.2 ARM64 VMs from a Debian12 ARM64 VM using an installer script, similar to DietPi.
Kali Linux also has an ARM64 live ISO that you can boot under RaspberryPi Proxmox.
So everything can be used in a variety of ways.
VM use under ARM64 seems to be rare, and you have to rely on “homebrew” for that.
If the Proxmox-ARM64 installation could be integrated into the DietPi installer and a blank DietPiOS-ARM64-VM could be provided, then its use might be more widespread. Adding the ARM64 VM to the DietPi installer script (copying the “Generic Device” section as an ARM64 VM) would be desirable.
Request is also here: Image | Add support for ARMv8 VMs · Issue #5637 · MichaIng/DietPi · GitHub
I just never found the time to implement it, though collected ideas about how it can be done.
I can send my changed conversion script if you’d like @MichaIng
1 Like
That would be great, as a basis for me, when implementing it, so I may have some take aways from your solution.
dietpi-installer-shimmed.txt (103.4 KB)
Here it is. I changed the packages that are not uninstalled by default and the tty that is left activated. It should work for “Generic Device” (22). Getting some “could not connect to dbus” errors while shutting down the VM but they don’t seem to affect anything.
So you basically just enable the RPi specific serial console and install an alternative network stack, right? For what is the alternative network tool needed? Does not not work with ifupdown
alone?
About the error on shutdown, either assure systemd-logind
is masked, or instal dbus
:
systemctl mask --now systemd-logind
or
apt install dbus
If you aim to use ACPI functionality, systemd-logind
is required. We hence enabled it for all VM images, effective until next release. We’d to the same for ARMv8 VM images, once implemented.
If I used the default installer the networking was not working after conversion (with ifupdown probably, yes). So I compared the manually installed packages list in the starting and the converted image and looked for network related stuff, netplan was the one that seemed fitting and leaving it solved the problem.
This serial console is the one used by qemu, I don’t know about other virtualization solutions.
I’m not sure what acpi is for, probably shutting the vm off from the host? Yes, it does not seem to work and would be useful.
Right, to issue regular shutdowns and reboots from the host. Else it can only hard kill the VM, while a regular shutdown can then only be done from the guest.
1 Like
https://cloud.debian.org/images/cloud/bookworm/latest/
Here is the link to the images, I used the nocloud qcow2 one. Please let me know if this still works for you.
I ran 1 more command after converting:
apt-mark auto linux-image-6.1.*
- because linux-image-arm64
provides this.
1 Like
Indeed, when I installed dbus and also unmasked systemd-logind
, everything works. Is it a problem for dietpi that this alternative network stack netplan.io
is installed?
Network configuration via dietpi-config
(which uses ifupdown
) may not work, colliding with the other installed network stack. There is surely a way to avoid installing them, and configure the network via ifupdown
resp. /etc/network/interface(.d/)
only.
Hello MichIng,
I have been running over 1 year of DietPi-ARM64-VMs
successfully with Proxmox 8 on a RaspberryPi 5, among others
also a DietPi-ARM64-VM as an Openmediavault 7 NAS server which also works wonderfully.
Unfortunately, these VMs, which come from a Debian installation with the DietPi- installer script are only displayed as “Generic Device (aarch64)”, which is actually only a cosmetic problem.
Unfortunately, these VMs, which come from a Debian installation with the DietPi- installer script are only displayed as “Generic Device (aarch64)”, which is actually only a cosmetic problem.
The first and easiest measure would be if you could adapt the script (e.g. by duplicating parts and naming the part accordingly) so that the VM is displayed as “Virtual Machine (aarch64)”.
I use a small minimal DietPi-ARM64-VM with only CLI as master which can be copied and modified as a Proxmox backup to other Rpi5 or Rpi4 machines running Proxmox.
Backup and Restore of the VMs are very small, quick and easy. I don’t want to be without this anymore
Greetings
Ludger
PS: sorry, i’m from Germany, my English is not the yellow from the egg .
I know little about how these things work, as much as I would like to help. Have you tested the script yourself?
Not yet, fiddling with other stuff at the moment. I would just implement ARM VM support into our build/installer scripts directly, see whether it works, and in case compare the result/implementation with your script, to check missing parts. But will likely not be able to start with this earlier than in 2 weeks, when I am home again.