Issue with images:debian/forky/cloud/amd64 VM image

1

I am launching this new forky image (21eb8dc3381b | no | Debian forky amd64 (20260205_05:24) | x86_64 | VIRTUAL-MACHINE | 389.77MiB)

and it fails to get past the initramfs. It doesn’t drop into an emergency shell (because root is locked?) so I can’t look at the rdsosreport.txt file to see what went wrong.

Any ideas?

The trixie VM is fine. I used typescript to capture the text console output, below, for what it’s worth. I cleaned up captured terminal codes from that, BTW, in case I deleted too much.

The instance default profile is after the text console output.

incus launch images:debian/forky/cloud/amd64 --vm debian-14-amd64-0 --target p0 --console
Launching debian-14-amd64-0
To detach from the console, press: <ctrl>+a q
BdsDxe: loading Boot0002 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/Scsi(0x0,0x1)
BdsDxe: starting Boot0002 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/Scsi(0x0,0x1)
  Booting `Debian GNU/Linux'

Loading Linux 6.18.5+deb14-amd64 ...
Loading initial ramdisk ...
start=d23920e900ef4fd38382c95b62b1c37b;user=root;hostname=distrobuilder-8905777e-9556-4f54-addf-b89e86735889;machineid=5b3b708d3a73456faf22a50f1bad70d1;bootid=92bbaff5ef4d452bbfbe5033ef633b59;pid=1;pidfdid=2;comm=systemd;type=boote\[e[0;1;31mFAILEDe[0m] Failed to mount e[0;1;39msysroot.mounte[0m - /sysroot.
DEPENDe[0m] Dependency failed for e[0;1;39minitrd-root-fs.targete[0m - Initrd Root File System.
DEPENDe[0m] Dependency failed for e[0;1;39minitrd-parse-etc.servicee[0m - Mountpoints Configured in the Real Root.

Generating "/run/initramfs/rdsosreport.txt"


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.



Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

Failed to connect to system scope bus via local transport: No such file or directorye[0m

Generating "/run/initramfs/rdsosreport.txt"


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.



Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

$ exit

Here is the profile I’m using:

config:
  limits.cpu: "4"
  limits.memory: 8GiB
description: Default Incus profile for project github-runners
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: incusbr0
    type: nic
  root:
    path: /
    pool: local
    size: 50GiB
    type: disk
2

Forky is pre-release and will be for quite a while longer.
We don’t typically build such images at all, though we’ve been convinced to make an exception for Debian :slight_smile:

Anyway, all that to say, having images get broken for pre-release software isn’t unexpected. Our image validation logic is configured to ignore failures on forky for that reason.

From the console output you’re showing, it looks like Debian is moving from initramfs-tools over to dracut and may be running into some corner cases there.

3

I was not expecting much for that reason, but thought I would ask.

Heh. I ran into this because I’m trying to stand up self-hosted github runners to be able to build incus install images for forky using you zabbly/incus packaging repo. If I’m reading the github action build.yaml correctly I need a debian-14 runner, correct?

Maybe I’ll try installing forky from ISO into and empty VM and see how my luck goes.

Or maybe I should just dust off my debian package build skills, which were never great, and just build on my forky laptop.

Thanks

4

Ah yeah, my packages indeed use our images as the base for the Github self-hosted runners (using GitHub - stgraber/gh-actions-manager: Github Actions runner manager for Incus).

I must say I’ve not really paid attention to Debian’s plans around the initrd handling in forky, but maybe @gibmat knows what’s going on there.