# Orange Pi 5 Network Connectivity Lost - Fresh SD Card Also Fails to Connect
**URL:** https://dietpi.com/forum/t/orange-pi-5-network-connectivity-lost-fresh-sd-card-also-fails-to-connect/24613
**Category:** Troubleshooting
**Created:** [29 October 2025 06:30 UTC](https://dietpi.com/forum/t/orange-pi-5-network-connectivity-lost-fresh-sd-card-also-fails-to-connect/24613 "2025-10-29T06:30:59Z")
**Posts on this page:** 4
**Page:** 2
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [13 November 2025 17:05 UTC](https://dietpi.com/forum/t/orange-pi-5-network-connectivity-lost-fresh-sd-card-also-fails-to-connect/24613/21 "2025-11-13T17:05:51Z")
Which shouldn’t be needed. At least my OPi5 is booting from nvme directly.
---
### Author:  [@Renoria](https://dietpi.com/forum/u/Renoria)
#### Post date: [14 November 2025 06:11 UTC](https://dietpi.com/forum/t/orange-pi-5-network-connectivity-lost-fresh-sd-card-also-fails-to-connect/24613/22 "2025-11-14T06:11:08Z")
yeah it used to boot from NVME previously for me too. I am also stuck in Armbian for now, not sure how to get this resolved
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [20 November 2025 23:33 UTC](https://dietpi.com/forum/t/orange-pi-5-network-connectivity-lost-fresh-sd-card-also-fails-to-connect/24613/23 "2025-11-20T23:33:31Z")
Sorry for the late reply. I just successfully booted from USB, with U-Boot from 2025-10-12 on the bootloader on SPI flash.
But reboots did not work well, it always ended before starting the init system somehow. Last serial console output:
```auto
[35.104626] scsi 0:0:0:0: Direct-Access Corsair Voyager 3.0 000A PQ: 0 ANSI: 6
[35.105746] sd 0:0:0:0: Attached scsi generic sg0 type 0
[35.153204] sd 0:0:0:0: [sda] 62554112 512-byte logical blocks: (32.0 GB/29.8 GiB)
[35.155231] sd 0:0:0:0: [sda] Write Protect is off
[35.156794] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[35.182062] sda: sda1
[35.182726] sd 0:0:0:0: [sda] Attached SCSI removable disk
[35.592762] rk-pcie fe190000.pcie: PCIe Link Fail, LTSSM is 0x3, hw_retries=0
[35.733328] EXT4-fs (sda1): mounting with "discard" option, but the device does not support discard
[35.733399] EXT4-fs (sda1): mounted filesystem without journal. Quota mode: none.
[36.045600] systemd[1]: System time advanced to built-in epoch: Wed 2025-09-03 18:38:20 UTC
[36.118509] NET: Registered PF_INET6 protocol family
[36.119613] Segment Routing with IPv6
[36.119637] In-situ OAM (IOAM) with IPv6
```
```auto
[35.005101] scsi 0:0:0:0: Direct-Access Corsair Voyager 3.0 000A PQ: 0 ANSI: 6
[35.006661] sd 0:0:0:0: Attached scsi generic sg0 type 0
[35.071009] sd 0:0:0:0: [sda] 62554112 512-byte logical blocks: (32.0 GB/29.8 GiB)
[35.073186] sd 0:0:0:0: [sda] Write Protect is off
[35.075180] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[35.103739] sda: sda1
[35.104548] sd 0:0:0:0: [sda] Attached SCSI removable disk
[35.529828] rk-pcie fe190000.pcie: PCIe Link Fail, LTSSM is 0x3, hw_retries=0
[36.439461] EXT4-fs (sda1): mounting with "discard" option, but the device does not support discard
[36.439508] EXT4-fs (sda1): mounted filesystem with ordered data mode. Quota mode: none.
[36.742124] systemd[1]: System time advanced to built-in epoch: Wed 2025-09-03 18:38:20 UTC
[36.796966] NET: Registered PF_INET6 protocol family
[36.798092] Segment Routing with IPv6
[36.798118] In-situ OAM (IOAM) with IPv6
[36.811327] vendor storage:20190527 ret = -1
```
Two reboots, nearly identical, just last line came on top on second reboot.
Next, my USB WiFi dongle did not work on the vertical USB 2.0 port (the storage dongle is attached to the upper USB 3.0 port). No device is detected at all, as if it is not powered.
… okay, it shares the controller with the USB-C port. Adding the `dwc3-host` overlay makes it functional. New images will ship with this overlay enabled by default: [Orange Pi 5: switch USB-C + vertical USB 2.0 port to host mode · MichaIng/DietPi@592a56d · GitHub](https://github.com/MichaIng/DietPi/commit/592a56d)
If you are bugged by this:
```sh
G_SUDO G_CONFIG_INJECT 'overlays=' 'overlays=dwc3-host' /boot/dietpiEnv.txt
```
or add `dwc3-host` separated by space to this line, if you have another overlay enabled already.
Now trying to update the SPI bootloader via `dietpi-config` \> Advanced Options \> Flash SPI bootloader. Relevant for your case, select the bottom option for NVMe, since the upper one is for SATA M.2 SSDs. But I see from earlier posts you did that.
I am no friend of these radiolists. A `--menu` would make more sense, where one does not need the extra backspace hit to toggle an entry. I’ll change this in our fork. I’ll also see whether I can give the second option an `_nvme` suffix, to make the difference clearer.
The reboot issue is probably specific to USB boot or my USB dongle, it remains. I always need to power cycle to get post the point. The two error message from PCIe and vendor storage appear as well on successful boot, the first surely since no card is attached to the M.2 socket. The rootfs gets successfully mounted, no other error message, hence no idea why it does just not load the init system 🤔.
In your case, the initramfs indeed failed to mount the rootfs, based on your screenshots above. To compare, here again a failing boot in my case with serial console as primary console, to contain everything you see on HDMI:
```auto
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Waiting for root file system ... [64.435720] scsi 0:0:0:0: Direct-Access Corsair Voyager 3.0 000A PQ: 0 ANSI: 6
[64.437145] sd 0:0:0:0: Attached scsi generic sg0 type 0
[64.549907] sd 0:0:0:0: [sda] 62554112 512-byte logical blocks: (32.0 GB/29.8 GiB)
[64.552269] sd 0:0:0:0: [sda] Write Protect is off
[64.554158] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[64.575122] sda: sda1
[64.575948] sd 0:0:0:0: [sda] Attached SCSI removable disk
[64.912567] rk-pcie fe190000.pcie: PCIe Link Fail, LTSSM is 0x3, hw_retries=0
Begin: Running /scripts/local-block ... done.
done.
Begin: Will now check root file system ... fsck from util-linux 2.41
[/sbin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -y -C0 /dev/sda1
e2fsck 1.47.2 (1-Jan-2025)
/dev/sda1: clean, 19206/1835520 files, 423951/7815163 blocks
done.
[65.071895] EXT4-fs (sda1): mounting with "discard" option, but the device does not support discard
done.
[65.071933] EXT4-fs (sda1): mounted filesystem with ordered data mode. Quota mode: none.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.
[65.435711] NET: Registered PF_INET6 protocol family
[65.437984] Segment Routing with IPv6
[65.438057] In-situ OAM (IOAM) with IPv6
```
I have “mounted filesystem”, you have “No such device” and “Failed to mount”, weirdly after `fsck` successfully checked this very same device. So U-Boot found the NVMe, the initamfs did so, but after `fsck`, it fails to actually mount it.
The thing is, the bootloader should be moreless the same since a long time. Though Radxa is doing quite some commits. I do not see something related to PCIe from that time around, but very recently (not in our U-Boot build yet), they added a new Rockchip PCIe controller driver. But is is not used by RK3588 boards, but only by the ROCK 4 ones which explicitly enable this driver in their build config: [Commits · radxa/u-boot · GitHub](https://github.com/radxa/u-boot/commits/next-dev-v2024.10/)
And for RK3399 SBCs, we do not use the Radxa sources anyway, but mainline U-Boot.
Armbian did not change Orange Pi 5 (U-Boot) config or device tree or patches for this board either: [build/patch/u-boot/legacy/u-boot-radxa-rk35xx at main · armbian/build · GitHub](https://github.com/armbian/build/tree/main/patch/u-boot/legacy/u-boot-radxa-rk35xx)
Regarding reboot vs power cycle: Our filesystem expansion script sadly needs to reboot 2 times on GPT partitioned images: once after expanding the last partition, which the kernel cannot be informed about while the filesystem is mounted (even R/O), and once after the ext4 journal has been created in case the image uses an initramfs, since otherwise its `fsck` on next reboot causes a filesystem corruption, requiring another power cycle to solve. Normally this would be a problem, but on the one hand, at least USB (3.0) boot in my case is veeery slow, as can be seen from the logs above the bootloader requires ~30 seconds before loading the kernel, and ~60 seconds after I enabled the USB host mode overlay, no idea how this has such an effect. I hope it is faster on NVMe. But probably you have the same reboot issue right now? Do you have a UART adapter to check serial console output? If you see LEDs indicating activity at first, but then it stays at solid red and no green blinking, after 1 minute or so, power cycle. Then, if the same happens again, power cycle again. So you would have worked around the reboot issue for the two expected reboots, after which it would boot up into first run setup and network.
… one more thing, when you say
```auto
dietpi-config → Advanced Options → Update SPI bootloader → rkspi_loader.img
```
You really toggled `rkspi_loader.img` with backspace, so it has this asterisk?
Because if not, if you just hit return when it is highlighted, it would pick the first one, which annoyingly is the SATA image. Not sure about the impact in that case, whether it would not detect the SSD at all, or whether it can result in your case of boot into initramfs + fsck but failing mount.
I just extended a commit in our fork to also switch this to a menu, which makes the selection easier and less error-prone: [rockchip64: prevent SPI flash from exiting parent shell · MichaIng/build@98c77b4 · GitHub](https://github.com/MichaIng/build/commit/98c77b4)
EDIT: Oh while testing the new menu, I recognized that Armbian switched to mainline U-Boot for this board, just a week ago:
> **[orangepi5: drop vendor uboot · armbian/build@e5b845f](https://github.com/armbian/build/commit/e5b845f)**
>
> Armbian Linux build framework generates custom Debian or Ubuntu image for x86, aarch64, riscv64 & armhf - orangepi5: drop vendor uboot · armbian/build@e5b845f
Testing that one, with our menu vs radiolist:
One key less to type. The benefit of the new U-Boot binary vs prior image is that it does not flash the whole 16 MiB via `dd`, but only the ~1.6 MiB binary,via `flashcp`, with is much faster. Let’s see whether it solves the reboot issue and/or boots faster …
Haha yeah both:
- Boots after 11 seconds into kernel vs 61 seconds before
- Does not hang at reboot
Merging this build now … done.
@Renoria now I am kinda certain this will solve your issue as well, but Armbian most likely did not update the U-Boot package within the last week? You can try it like that in case:
```sh
cd /tmp
wget https://dietpi.com/downloads/binaries/linux-u-boot-orangepi5-vendor.deb
sudo dpkg -i linux-u-boot-orangepi5-vendor.deb
```
Then flash the SPI bootloader the common way on Armbian, AFAIK with `armbian-install`. To actually test it, with your current setup, you would need to copy the `/boot` directory from the SD card into the `/boot` dir on the NVMe. For this, however umount the bind mount that is currently there. Should be this, but not 100% sure about the mountpoint:
```sh
sudo umount /boot
sudo cp -a /mnt/sdcard/. /boot/
```
Shutdown, remove SD card, boot. It will fail to mount the SD card, of course, but that should not prevent boot or be at a point where you know whether it generally works. If so, you can remove the SD card and bind mount entires from `/etc/fstab`, or, flash again a DietPi image.
---
### Author:  [@system](https://dietpi.com/forum/u/system)
#### Post date: [18 February 2026 23:33 UTC](https://dietpi.com/forum/t/orange-pi-5-network-connectivity-lost-fresh-sd-card-also-fails-to-connect/24613/24 "2026-02-18T23:33:55Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
[Previous page](https://dietpi.com/forum/t/orange-pi-5-network-connectivity-lost-fresh-sd-card-also-fails-to-connect/24613.md?page=1)