Hi,
I’m reporting an issue I encountered on a brand-new NVIDIA DGX Spark during the initial setup / OOBE process.
The system completed the initial setup and package update, then rebooted. On the next boot it failed with a kernel panic:
VFS: Unable to mount root fs on unknown-block(0,0)
The machine also spent a long time attempting PXE boot before eventually reaching the failed local boot path.
I disabled PXE in UEFI and booted an Ubuntu ARM64 live USB to inspect the internal installation.
The installed root filesystem was intact, but I found that the newly installed kernel:
7.0.0-1019-nvidia
had:
/boot/vmlinuz-7.0.0-1019-nvidia
but was missing:
/boot/initrd.img-7.0.0-1019-nvidia
The previous kernel:
6.17.0-1014-nvidia
still had both kernel and initrd and could boot successfully.
After chrooting into the installed system, dpkg showed the new kernel package in a partially configured state.
The relevant package was:
linux-image-7.0.0-1019-nvidia
and configuration was failing in the DKMS post-install path.
The NVIDIA driver stack installed by the update was:
nvidia-driver-580-open 580.178.04
nvidia-dkms-580-open 580.178.04
What looked suspicious is that the NVIDIA DKMS package postinst and the kernel DKMS hook were using different architecture strings.
The NVIDIA package postinst used Debian architecture:
arm64
while the kernel postinst DKMS path was operating with:
aarch64
On this system, those refer to the same architecture family, but DKMS appeared to treat them as distinct bookkeeping entries.
During repair I saw the kernel postinst fail with a message equivalent to:
Module nvidia/580.178.04 already installed on kernel 7.0.0-1019-nvidia (aarch64)
Use --force to override
while the NVIDIA DKMS package had previously built/registered the module under arm64.
This caused the kernel package configuration to fail and, in the failed OOBE state, the initramfs for the new kernel had not been created.
The immediate recovery steps were:
sudo update-initramfs -c -k 7.0.0-1019-nvidia
sudo update-grub
and then forcing DKMS for the kernel:
sudo dkms autoinstall --force -k 7.0.0-1019-nvidia
After that:
sudo dpkg --configure linux-image-7.0.0-1019-nvidia
completed successfully.
The system could then boot kernel:
7.0.0-1019-nvidia
However, to avoid the same DKMS issue recurring, I later migrated away from DKMS and installed the precompiled kernel modules instead:
linux-modules-nvidia-580-open-7.0.0-1019-nvidia
linux-modules-nvidia-580-open-nvidia-hwe-24.04
and removed:
nvidia-dkms-580-open
I also removed stale DKMS modules from:
/lib/modules/7.0.0-1019-nvidia/updates/dkms
so that modinfo now resolves to the precompiled Canonical-signed NVIDIA module.
Current working state:
Kernel: 7.0.0-1019-nvidia
NVIDIA driver: 580.178.04
CUDA: 13.0
GPU: NVIDIA GB10
DKMS status: empty
dpkg --audit: clean
The system is now booting normally.
The reason I’m posting is that this happened during the initial OOBE/update flow on a new DGX Spark, without any manual kernel modification before the failure.
The sequence strongly suggests that the failed kernel post-install / DKMS architecture bookkeeping conflict left the new kernel without a valid initrd, which then caused the root filesystem mount panic on reboot.
Has anyone else seen this on DGX Spark with the 7.0.0-1019-nvidia kernel and NVIDIA 580.178.04?
In particular, I’d be interested to know whether the arm64 vs aarch64 DKMS handling is a known issue in the current Spark OTA stack, and whether NVIDIA recommends using the precompiled linux-modules-nvidia-* packages instead of nvidia-dkms-* on DGX Spark.
I can provide the full dpkg, DKMS, initramfs, and boot logs if useful.
Thanks.