Dear Maintainer, debifevm-create can be used to build Debian VMs, but it fails to build Ubuntu VMs. I tried to make it work and found following issues: 1. systemd-resolved is not installed on Ubuntu: ``` $ debefivm-create -r stonking [...] I: running --customize-hook directly: /usr/bin/../share/debvm/customize-resolved.sh /tmp/mmdebstrap.cwH3vDtSTy Failed to enable unit: Unit systemd-resolved.service does not exist E: setup failed: E: command failed: /usr/bin/../share/debvm/customize-resolved.sh W: hooklistener errored out: E: received eof on socket ``` 2. The symlinks vmlinuz and initrd.img do not exist in / but in /boot: ``` $ debefivm-create -r stonking -- --include=systemd-resolved [...] I: running special hook: download vmlinuz '/tmp/tmp.imUUTHadEa/kernel' W: hooklistener errored out: E: received error on socket ``` 3. The efi.stub package is not installed by default. 4. dracut should be used instead of initramfs-tools on Ubuntu 26.04 and newer. ...and maybe more.
Hi Benjamin, The error message displayed here is very suboptimal, because it does not hint at the root of the problem. When the hook runs, it examines the libnss-resolve version and when it fails to find the package, it concludes that an old systemd version is in use, but stonking is recent. In theory, the main script should have installed libnss-resolve, but that can go wrong when you fail to pass the right components. I have improved the hook to explicitly install libnss-resolve when the systemd version is recent. When you see an installation failure of libnss-resolve, it should be much easier to connect the failure to the missing components. Do you think this is enough to handle this aspect? https://salsa.debian.org/helmutg/debvm/-/commit/8369544a773e572ab8fd46a53128836d1060a04e Can you file a bug against the relevant Ubuntu package to restore the symlinks and record the bug here? This is tricky. What you see is caused by failure to pass required components (as with libnss-resolve), but it is more difficult to address this in a better way. Since the packages got renamed, I match them using ?narrow and that makes them go missing when components are missing. Their use happens via a download hook, so I cannot easily branch there. I'm also hesitant to add another hook just for validating that the efi stub was properly installed. In the end, this will likely not be practically relevant, because the resolved failure comes first and once you fix that, the stub is there. Do you agree with dropping this aspect? First and foremost, you can pass --include=dracut and that'll stop debvm from installing initramfs-tools. That's a workaround. The real issue you see is that dracut has become the default and debvm should use the default generator. I think this needs to be solved at a higher level. In order to sanely select the initramfs tool, we need a default-linux-initramfs-tool virtual package and dracut should be the only one providing it. You see dracut exists for a long time, but only recently has become the default. If I were to just prefer dracut over initramfs-tools, I would be breaking older releases. Can you get this going on the Ubuntu side and record the bug here? Helmut
Hi Helmut, Yes, that's enough. There is no /vmlinuz symlink any more since Ubuntu 20.04 (focal). I checked where the symlink comes from. /etc/kernel/postinst.d/xx-update- initrd-links (from linux-base) creates the symlink by calling linux- update-symlinks. linux-update-symlinks has a link_in_boot option which is set to true on Ubuntu and false on Debian by default. So debefivm-create could explicitly set link_in_boot in /etc/kernel- img.conf. Yes. I agree. Do we really need a default-linux-initramfs-tool virtual package? Couldn't debvm determine the default initramfs tool by looking at the kernel package? On Debian the kernel depends on the initramfs tool, but on Ubuntu the kernel only recommends the initramfs tool. Example Debian trixie: * linux-image-generic is provided by linux-image-amd64 * linux-image-amd64 depends on linux-image-6.12.94+deb13-amd64 * linux-image-6.12.94+deb13-amd64 depends on "initramfs-tools (>= 0.120+deb8u2) | linux-initramfs-tool" -> initramfs-tools Example Debian unstable: * linux-image-generic is provided by linux-image-amd64 * linux-image-amd64 depends on linux-image-7.0.13+deb14-amd64 * linux-image-7.0.13+deb14-amd64 depends on "dracut | initramfs-tools (>= 0.120+deb8u2) | linux-initramfs-tool" -> dracut Example Ubuntu 26.04 resolute: * linux-image-generic depends on linux-image-7.0.0-22-generic * linux-image-7.0.0-22-generic recommends "dracut | linux-initramfs-tool" -> dracut Example Ubuntu 24.04 noble: * linux-image-generic depends on linux-image-6.8.0-124-generic * linux-image-6.8.0-124-generic recommends "initramfs-tools | linux-initramfs-tool" -> initramfs-tools
Hi Benjamin, Before looking into debefivm-create, I spent an additional look at debvm-run. It also fails booting current Ubuntu, but for different reasons. There /boot/vmlinuz is actually being tried. But it also detects the VM architecture from /bin/true, which happens to be a symlink and as a result debugfs cannot cat it, so elf-arch sees an empty file and concludes an empty architecture. From there things don't go well. I improved the debvm-run side to handle this case. https://salsa.debian.org/helmutg/debvm/-/commit/ae3d0affff8e9127b4b226f12397aa0d9272edcd This feels like being between a rock and a hard place. Setting link_in_boot deviates from Ubuntu defaults and I also cannot compute the name dynamically as it happens is being used inside a download hook. I would like to find a better compromise than the ones we are faced with. Any ideas? At this point, I'm not sure whether the extra effort spent at parsing the kernel packag's depends is well invested. initramfs-tools appears to still work on stonking. I am considering patches (and MRs running CI) to this end, but they need to work with stretch and chrootless. In any case, I can boot stonking as a debvm (not debefivm) with the changes in git. Helmut