Hi Benjamin, On Mon, Jun 29, 2026 at 03:35:16PM +0200, Benjamin Drung wrote: > On Fri, 2026-06-26 at 08:15 +0200, Helmut Grohne wrote: > > 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.
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 > 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. 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? > 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 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
