Diagnose common problems safely

A safe troubleshooting method

1. Identify the layer

   Is the issue with the Spectre host, GNOME display, VirtualBox integration, the Podman engine, the Kali container or a specific Kali package?

2. Collect read-only evidence

   Record exact errors and service status before modifying anything.

3. Prefer reversible fixes

   For a stopped container, try starting the existing container rather than deleting and recreating it.

4. Verify the result

   Repeat the same non-destructive check and record the outcome.

The desktop will not boot

Confirm the VM has enough memory and disk space, the virtual disk is attached, the installer ISO is detached after installation, and the VM is using the intended Debian 64-bit settings. If boot stops with a visible error, record the screen or log rather than repeatedly reinstalling.

journalctl -b -p warning --no-pager -n 60

Hardware and firmware differences can require additional work. Only VirtualBox evaluation results are documented here.

The desktop resolution stays fixed

First check that the issue is in VirtualBox. Then verify the Spectre conditional userspace service and its processes. The service can be irrelevant on other hypervisors.

systemctl is-active spectre-vbox-display.service

pgrep -af "VBoxDRMClient|VBoxService"

systemd-detect-virt || true

The tested system had an active service with both userspace clients. Do not compile or install third-party guest kernel modules against the custom kernel without matching verified headers.

ToolHub does not initialize

Initialization needs a network connection to pull the official Kali image. Check DNS, proxy restrictions, available storage and Podman status. One successful container pull does not guarantee that every package is available later.

podman info --format "{{.Host.Security.Rootless}}"

podman ps -a --format "{{.Names}} | {{.Status}}"

If no container exists, ToolHub may need to initialize it. If one already exists, preserve it and use the safe startup procedure below.

Kali container stopped after reboot

A stopped Kali container is not the same as lost packages. The project test showed Nmap remained installed after restart even though the container had exited with code 137 during reboot.

podman inspect spectre-kali-toolbox --format "Exit={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}}"

podman start spectre-kali-toolbox

podman exec spectre-kali-toolbox nmap --version

Exit 137 signals SIGKILL. When OOMKilled=false, out-of-memory killing is not reported by Podman; this does not uniquely identify the shutdown cause. If code 137 recurs during normal use, review logs and memory pressure.

Package installation fails

Package names and available versions depend on Kali Rolling. The offline catalog is useful for browsing but is not a guarantee that a current package has the same name or dependencies. First check network connectivity and the container package metadata.

podman exec spectre-kali-toolbox apt-get update

podman exec spectre-kali-toolbox apt-cache policy nmap

If APT reports a lock, identify the active process rather than deleting lock files. Avoid adding Kali repositories to your Debian-family host.

Rootless permissions error

A failing rootless container can reflect missing or inconsistent subordinate UID/GID ranges. The evaluated 1.0 build includes a provisioning service to set up those mappings. Use read-only checks first.

systemctl show spectre-rootless-podman-subids.service -p Result -p ExecMainStatus

grep "^$(id -un):" /etc/subuid /etc/subgid

If the service fails, capture the journal output and investigate the exact failure; do not manually overwrite the mapping files on an installation with existing containers.

journalctl -b -u spectre-rootless-podman-subids.service --no-pager -n 50

Collect a useful bug report

• Linux Spectre version and ISO checksum, if known.
• Whether the installation is a live session, a VM or physical hardware.
• Kernel version from uname -r.
• Exact command performed and full error text.
• Container state, relevant service status and whether the issue survives reboot.
• Steps that reliably reproduce the issue.

uname -r && systemd-detect-virt || true
podman ps -a --format "{{.Names}} | {{.Status}}"
systemctl is-active spectre-vbox-display.service || true

Related pages

For a clean starting point see installation; for container behavior see ToolHub; for service details see system architecture.