Gen. x86 PC ISO installer should detect when running in a VM, not print CPU temp
When installing DietPi Bookworm (UEFI) from the generic PC x86_64 ISO in a VM (in my case VMWare Workstation), it tries to detect the temperature of the CPU and prints an erroneous value to the console. See screenshot below.
I think it would be a good quality of life improvement if generic PC version of DietPI detected that it is running in a hypervisor on first boot. It can then minimally not try to detect the CPU temperature, or potentially even offer to install the applicable guest additions (open-vm-tools, qemu-agent, etc.)
I realize that the above is only an issue because I used the PC ISO instead of using the provided VMWare image. However, at least in my case, it was preferable to install from ISO.
You should not use a "native" PC image on a VM, but one of our VM images instead. This one should fit: https://dietpi.com/downloads/images/DietPi_VMX-x86_64-Bookworm.tar.xz (VMware/ESXi on our download page).
However, at least in my case, it was preferable to install from ISO.
I remember someone else had the same use case. ESXi can import OVA appliances, and Workstation Player/Pro can start VMX appliances. In which case is an installer image preferable? And was it necessary to have a UEFI image, or would MBR/BIOS work as well? We could generate those with true VM images embedded as well. It would then do all the things you asked for, like installing QEMU guest agent automatically on first boot, if it finds a QEMU communication node.
However, what you can do now is tell DietPi that this is a VM:
echo 20 > /etc/.dietpi_hw_model_identifier
And purge some packages which do not make sense on VMs:
G_AGP intel-microcode amd64-microcode hdparm iw wireless-tools wpasupplicant wireless-regdb crda firmware-linux-free firmware-misc-nonfree firmware-realtek firmware-atheros firmware-brcm80211 firmware-iwlwifi
/boot/dietpi/func/dietpi-set_hardware serialconsole disable
The login banner can be adjusted with dietpi-banner.
Thank you for the detailed response and for the workarounds.
I mainly wanted to use an ISO installer because it's a convenient and familiar workflow, and because it would create a partition to occupy the entirety of the disk automatically, without having to manually do it later (or using dietpi-drive_manager). As for legacy vs UEFI, I don't think it matters here, It's just what I happened to be using.
In the meantime we have VM installer images, so there should be no need to use native PC images for VMs anymore.