Unable to boot from NVMe after flashing SPI

NinjaEule · 20 December 2025 18:29

I have searched the existing open and closed issues

Required Information

DietPi version | Core:9 Sub:20 RC:1 branch:master owner:MichaIng
Distro version | trixie
Kernel version | Linux DietPi 6.1.115-vendor-rk35xx #1 SMP Mon Dec 1 08:58:34 UTC 2025 aarch64 GNU/Linux
Architecture | arm64
SBC model | ROCK 5B (aarch64)
Power supply used | 30 W (5V-3A 9V-3A 12V-2.5A 15V-2A 20V-1.5A)
SD card used | Toshiba 4GB HC 4
NVMe used | Kingston NV2 NVMe PCIe 4.0 1TB M.2 2280 -SNV2S/1000G

Additional Information

Software title | u-boot
preinstalled in dietpi-config

Steps to reproduce

cloned dietpi install from SD to NVMe using modified version of Adafruit-Pi-ExternalRoot-Helper
Flashed SPI with U-Boot using dietpi-config
Removed SD card and tried to boot

Expected behavior

DietPi should now boot from the NVMe

Actual behaviour

Boot runs until

 Begin: Waiting for root file system … Begin: Running /script/local-block … done.

[  7.171956 vendor storage:20190527 ret = -1

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

[  15.059717] platform mtd_vendor_storage: deferred probe pending

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

Begin: Running /script/local-block … done.

done.

Gave up waiting for root file system device. Common problems:

- Boot args (cat /proc/cmdline)

  - Check rootdelay= (did the system wait long enought?)

- Missing modules (cat /proc/modules: is /dev)

ALERT! UUID=daf769e9-9da9-41a3-9754-057cbb758ae9 does not exist.

(inittranfs] _

Unable to shut down the board, even when removing power after resupplying power to the board, boot continues.

After reinserting the mircroSD card, boot with the error Line 32: exec: kodi: not found

Which causes login to be skipped. The issue stays even after reboot.

Extra details

Verified boot loader install:

root@DietPi:~# dpkg -l | grep linux-u-boot-rock-5b-vendor
ii linux-u-boot-rock-5b-vendor  26.02.0-trunk-dietpi1     arm64    Das U-Boot for rock-5b
root@DietPi:~# dd if=/dev/mtd0 bs=1M count=1 2>/dev/null | wc -c
1048576

Verified NVMe recognized:

root@DietPi:~# lsblk
NAME         MAJ:MIN  RM    SIZE RO TYPE MOUNTPOINTS
mtddblock0   31:0      0     16M  0 disk
mmcblk1      179:0     0    3.6G  0 disk
L_mmcblk1p1  179:1     0    3,6G  0 part /
nvme0n1      259:0     0  931.5G  0 disk 
L_nvme0n1pi  259:0     0  931.5G  0 part
root@DietPi:~# fdisk -l
Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes/4096 bytes


Disk /dev/mtdblock0: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk Identifier: 70FB9CF8-2D43-4BA8-965B-6B6CA842EA5D
Device           Start   End  Sectors Size Type
/dev/mtdblock0p1   64   7167     7104 3,5M Linux filesystem
/dev/mtdblock0p2 7168   7679      512 256K Linux filesystem
/dev/mtdblock0p3 7680   8063      384 192K Linux filesystem
/dev/mtdblock0p4 8064   8127       64  32K Linux filesystem
/dev/mtdblock0p5 8128   8191       64  32K Linux filesystem
/dev/mtdblock0p6 8192  16383     8192   4M Linux filesystem
/dev/mtdblock0p7 16384 32734    16351   8M Linux filesystem


Disk /dev/nvmeθp1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: KINGSTON SNV2S1000G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4487BD0D-8906-489A-B124-EB858D834C2C
Device        Start        End    Sectors Size   Type
/dev/nvme0n1p1 2048 1953523711 1953521664 931,5G Linux filesystem

Disk /dev/mmcblk1: 3,64 GiB, 3904897024 bytes, 7626752 sectors
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk Identifier: B23DC6C9-B0A5-4C6F-AEFF-1C614648E8F4

Device         Start     End Sectors Size Type
/dev/mmcblk1p1 32768 7626718 7593951 3,6G Linux filesystem

Jappe · 20 December 2025 23:16

NinjaEule:

root@DietPi:~# lsblk
NAME         MAJ:MIN  RM    SIZE RO TYPE MOUNTPOINTS
mtddblock0   31:0      0     16M  0 disk
mmcblk1      179:0     0    3.6G  0 disk
L_mmcblk1p1  179:1     0    3,6G  0 part /
nvme0n1      259:0     0  931.5G  0 disk 
L_nvme0n1pi  259:0     0  931.5G  0 part

IDK if this is a copy error, but it should be nvme0np1 and not ...pi?! Also another “typo” later in initranfs, hm you scraped the text from a screenshot maybe? So it’s just a copy error.

NinjaEule:

Gave up waiting for root file system device. Common problems:

- Boot args (cat /proc/cmdline)

  - Check rootdelay= (did the system wait long enought?)

- Missing modules (cat /proc/modules: is /dev)

ALERT! UUID=daf769e9-9da9-41a3-9754-057cbb758ae9 does not exist.

(inittranfs] _

Can you check the UUID of the nvme drive

blkid /dev/nvme0n1p1

And then check what you have set in your extlinux.conf and /etc/fstab and maybe also raise the rootdelay to 10, if not already set (also in extlinux.conf)

NinjaEule · 21 December 2025 23:28

Yeah, pi and inittranfs are copy mistakes. I use Google Lens to copy text from photos once the text becomes to long enough that it’s faster to do it this way and check for error than type everything by hand. For inittranfs the picture was a bit blurry and Lens often has problems with distinguishing between i & 1, B & 8, e & 0, 5 & S, u & v and 0 & 8. Looks like I missed one of the errors. I ran blkid /dev/nvme0n1p1 with following result

/dev/nvmeθn1p1: LABEL=“rootfs” UUID=“5cb140af-126a-412f-9a2c-0548132449c2” BLOCK_SIZE=“4096” TYPE=“ext4” PARTLABEL=“primary” PARTUUID=“a35644908-2068-47cf-98b3-8a17ab471a14”

I tried to check extlinux.conf but couldn’t find it

whereis extlinux.conf as well as whereis extlinux gives the response extlinux.conf: andextlinux:

/etc/fstab has the following content

You can use “dietpi-drive_manager” to setup mounts.

NB: It overwrites and re-creates physical drive mount entries on use.

#----------------------------------------------------------------
NETWORK
#----------------------------------------------------------------

#----------------------------------------------------------------
TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=3838M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid

#----------------------------------------------------------------
MISC: ecryptfs, vboxsf, glusterfs, mergerfs, bind, Btrfs subvolume
#----------------------------------------------------------------

#----------------------------------------------------------------
SWAP SPACE
#----------------------------------------------------------------

#----------------------------------------------------------------
PHYSICAL DRIVES
#----------------------------------------------------------------
UUID=daf769a9-9da9-41a3-9754-057cbb758ae9 / ext4 noatime,lazytime,rw 0 1

Jappe · 22 December 2025 11:15

OK I’m not completely sure how the Radxa devices are booting on Dietpi, I’m not so familiar with the Radxa devices.

It looks like there is rootdev=UUID= also set in /boot/dietpiEnv.txt which then creates the entry for the fstab.
And I guess you would also need to change rootdev inside /boot/boot.cmd and then recreate the boot.src file.
In the comments of boot.cmd the command is specified.

mkimage -C none -A arm64 -T script -d /boot/boot.cmd /boot/boot.scr

I also just found out that you could have flashed the SPI with dietpi tools.For your device you should see an option in dietpi config tool: dietpi-config 3

NinjaEule · 23 December 2025 00:09

Thanks, that did work.

I actually did use the option in the dietpi config to flash the SPI.

At first, I tried installing u-boot from their GitHub repository and follow the commands written there, but when I tried make rock-5b_defconfig I got the error -bash: make: command not found despite me using cd u-boot before. So before creating this issue, I looked for other threads with a similar problem and stumbled onto this article, with this solution:

Orange Pi 5 systems will get a kernel and U-Boot update with next DietPi update, which should also enable NVMe support, after flashing the new bootloader binary to SPI via dietpi-config > Advanced Settings > Update SPI bootloader: Orange Pi 5/ROCK 5B | Kernel update and migration by MichaIng · Pull Request #6532 · MichaIng/DietPi · GitHub

So I tried it, but that wasn’t enough to get NVMe boot to work, so I created this issue.

I’m not sure if the SPI flash is necessary after editing /boot/dietpiEnv.txt & /boot/boot.cmd and recompiling boot.cmd & boot.src with mkimage -C none -A arm64 -T script -d /boot/boot.cmd /boot/boot.scr or wether my first flash was enough. This time I also used the option above and flashed the bootloader to the storage device which was the nvme. Not sure if that’s necessary but it can’t hurt.

Jappe · 23 December 2025 02:07

FYI you would need to install make to use make apt install make.
But it’s just easier to use dietpi-config.

Hmm yes I think you are right, the stock board comes already with u-boot on SPI which should handle already booting via NVME.
But it also does not hurt I guess.

So for future readers:
Just move the rootFS and edit dietpiEnv.txt and boot.cmd and recreate boot.scr

You know what, the whole journey with the adafruit tool was maybe also unecessary, I had another look into the scriots and found this:

github.com/MichaIng/DietPi

dietpi/dietpi-drive_manager?plain=1

c2311a265


      
          			else
          				TARGETMENUID=2 # Format menu
          			fi
          
          		# Resize
          		elif [[ $G_WHIP_RETURNED_VALUE == 'Resize' ]]
          		then
          			Resize_FS
          
          		# Transfer RootFS
          		elif [[ $G_WHIP_RETURNED_VALUE == 'Transfer RootFS' ]]
          		then
          			# Check whether required kernel command line config file is present
          			if [[ $G_HW_MODEL -le 9 && ! -f '/boot/cmdline.txt' ]]
          			then
          				G_WHIP_MSG '[ INFO ] /boot/cmdline.txt not found
          \nThe required /boot/cmdline.txt file to adjust the root filesystem entry for the kernel has not been found.
          \nTransferring the root filesystem is not supported on your device. Aborting...'
          				return 1
          
          			elif [[ $G_HW_MODEL -gt 9 && ! -f '/boot/boot.ini' ]]

maybe you can check if you have this option available on your radxa device in dietpi-drive_manager

MichaIng · 23 December 2025 14:44

boot.scr does not need to be changed, just assure that /boot/dietpiEnv.txt contains the correct UUID. extlinux.conf does not exist on our images. It would be an alternative to boot.scr.

EDIT: It looks like the helper script you used does not really clone the SD card (which would have preserved UUIDs) but created a new filesystem and copied over the files. So yeah, in such case, in addition to /etc/fstab, the rootfs UUID in bootloader config/env/script always needs to be updated as well, which is in /boot/dietpiEnv.txt on almost all DietPi SBC images.