Hi Helmut, On Fri, 2026-06-26 at 08:15 +0200, Helmut Grohne wrote: > Hi Benjamin, > > On Fri, Jun 26, 2026 at 12:53:21AM +0200, Benjamin Drung wrote: > > 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 > > ``` > > 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 >
Yes, that's enough. > > 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 > > ``` > > Can you file a bug against the relevant Ubuntu package to restore the > symlinks and record the bug here? 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. > > 3. The efi.stub package is not installed by default. > > 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? > Yes. I agree. > > 4. dracut should be used instead of initramfs-tools on Ubuntu 26.04 and > > newer. > > 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? 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 -- Benjamin Drung Debian & Ubuntu Developer
