specs

In my opinion setting up internet without tools is less work than setting up either networkd or network manager, because that would mean downloading all packages by hand and transfer them to the SBC (and probably add missing packages as you go). The after getting the network up you can install anything you want using apt. Look up on setting up ethernet from the commandline. I would suggest starting with wired ethernet if available. ip link set eth0 up ip route add default via 192.168.1.2 dev eth0 rm /etc/resolv.conf echo nameserver 192.168.1.1 > /etc/resolv.conf (Assuming your route is 192.168.1.1 and eth0 is set up with DHCP). There is probably enough to comment on this. But it gives you a general direction as it points to setup the ethernet adapter with IP address, route and DNS lookup. The order of "ip addr" and "ip link" is something you should find by trial. You probably use it only once before you switch to network manager. PS https://access.redhat.com/sites/default/files/attachments/rh_ip_command_cheatsheet_1214_jcs_print.pdf

Currently networking in Armbian is possible in different ways: 1 - networkd 2 - network-manager 3 - netplan, using either networkd or network-manager 4 - /etc/network/interfaces (which is absolutely outdated) 5 - armbian-config (which uses networkmanager via a script) Have you considered using 5? Perhaps you need to install armbian-config first on a minimal image. The timeout for systemd can omitted by disabling systemd-networkd-wait-online.service with systemctl. The second place to look is the "optional: true" parameter if you use netplan (which only works for ethernet).

Just saw the "mark as solution" tab. Basically when posted this issue was already solved. If it is not against policy I do like to post if only to document.

Finally found the problem: Since the kernel was half installed, the kernel and the modules did not match. This means all the modules did not work. Manually remounting the /boot partition and reinstalling the kernel did the trick. There is still some detail that the "uname -a" and "cat /proc/version" are not updated, although the kernel was replaced.

Current kernel: Linux rock-5b 6.1.43-vendor-rk35xx #1 SMP Mon Mar 18 05:06:52 UTC 2024 aarch64 GNU/Linux Symptoms: $ lspci .. 0002:20:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0002:21:00.0 Network controller: Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz (rev 1a) 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0004:41:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) And after a reboot I find with dmesg: # modprobe iwlwifi modprobe: ERROR: could not insert 'iwlwifi': Exec format error root@rock-5b:~# dmesg|grep -E -A 3 -B 3 "intel|iwl" [ 6.285747] input_leds: disagrees about version of symbol module_layout [ 6.288159] joydev: disagrees about version of symbol module_layout [ 6.309378] gpu_sched: disagrees about version of symbol module_layout [ 6.314006] btintel: disagrees about version of symbol module_layout [ 6.314148] btintel: disagrees about version of symbol module_layout [ 6.314693] btintel: disagrees about version of symbol module_layout [ 6.314751] btintel: disagrees about version of symbol module_layout [ 6.368536] iwlwifi: disagrees about version of symbol module_layout [ 6.377085] systemd[1]: Starting modprobe@dm_mod.service - Load Kernel Module dm_mod... [ 6.378547] systemd[1]: Starting modprobe@fuse.service - Load Kernel Module fuse... [ 6.380075] systemd[1]: Starting modprobe@loop.service - Load Kernel Module loop... [ 6.380564] btintel: disagrees about version of symbol module_layout [ 6.381271] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root). [ 6.383701] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root). [ 6.384399] dm_mod: disagrees about version of symbol module_layout -- [ 217.993684] [drm:vop2_plane_atomic_check] *ERROR* Invalid size: 64x1->64x1, min size is 4x4 [ 218.001798] [drm:vop2_plane_atomic_check] *ERROR* Invalid size: 64x1->64x1, min size is 4x4 [ 218.009720] [drm:vop2_plane_atomic_check] *ERROR* Invalid size: 64x1->64x1, min size is 4x4 [ 439.786500] iwlwifi: disagrees about version of symbol module_layout [ 445.011474] iwlwifi: disagrees about version of symbol module_layout [ 476.290795] iwlwifi: disagrees about version of symbol module_layout Manually installing the iwlwifi driver yields: # modprobe iwlwifi modprobe: ERROR: could not insert 'iwlwifi': Exec format error Perhaps more people ran into the same problem? Of course I ran into this problem while quickly trying to access some server, only finding that the wifi adapter was not working anymore ("it used to work"). The quick & dirty solution was finding a cable bypassing wifi.

Conclusion: the only kernels you can switch between with armbian-config are the 5.10 legacy and the 6.1 vendor kernels with the current setup. You did mention "Usually", but basically I guess the "armbian-config" and "exchanging kernels" route only is only recommended with "standard support". There is much which can go wrong and I did end up reinstalling (starting from SD is no guarantee your NVME is not ending screwed up).

It seems like the Radxa Rock5B has been downgraded from standard support to community support for the image downloads but not (yet) for the forum. Are the vendor images for the RK3588 and the 6.8.x images the same except for the kernel? (Can I expect to just replace the kernel to switch from the vendor image to the edge image.)

After installing Armbian_23.2.1_Rock-5b_bookworm_legacy_5.10.160_xfce_desktop.img I found a nagging error each start of Firefox. "Failed to read the configuration file. Please contact your system administrator." Looking at internet with Google I found hardly any link referring to linux or armbian, therefore I still don't know which configuration file was actually missing or damaged. The only link I found with armbian in it contained some very obscure editting of some configuration files (just like many proposed Windows solutions). The issue: where does it go wrong? The problem is some configuration clutter somewhere in /usr/lib/firefox-esr. And how to solve? A Windows video showed a user removing and reinstalling firefox. Reinstalling with a blank configuration really does solve this problem (try as root or use sudo): apt --purge remove firefox-esr rm -rf /usr/lib/firefox-esr apt install firefox-esr I guess only users who don't use a minimal image may encounter this problem.

Does the latest version include Andy Yan's HDMI/VOP2 patch? (I believe the downstream patch v1 was dated 14 november.)

PD has advantages when you use the cables at 2A for a long time. But that is typically for charging a phone or a laptop in a short time. With a PD-adapter the power consumption is pretty bad for the Rock5. With a constant Voltage power supply it is only bad in combination with NVMe and good in combination with eMMC. When powered of, without removing the power cable, the Rock5B still uses about 0,5W (slightly worse than a RPI4, which is already bad). When using eMMC the Rock5B uses about 1.8-2W in idle. When you are using a general 30-65W PD adapter make it 2.4-3W in idle (the DC-DC conversion from 20V to 5V is very inefficient, if you have a small and cheap PD adapter this adds to the inefficiency). When using an NVMe you could get the power consumption as low as 4W in idle, with a 12V constant voltage adapter. CPU 0-3: 1200 ( 600 Mhz - 1800 MHz / conservative) CPU 4-5: 816 ( 408 Mhz - 2400 MHz / conservative) CPU 6-7: 600 ( 408 Mhz - 2400 MHz / conservative) GPU : 300 ( 300 Mhz - 1000 MHz / simple_ondemand) DMC : 1560 ( 528 Mhz - 1560 MHz / dmc_ondemand) Here the pcie_aspm (NVMe connection) is set to powersupersave. With the pcie_aspm set to performance and all the cpu and gpu settings to max you get 6W in idle. CPU 0-3: 1800 (1800 Mhz - 1800 MHz / performance) CPU 4-5: 2400 (1000 Mhz - 2400 MHz / performance) CPU 6-7: 2400 (1000 Mhz - 2400 MHz / performance) GPU : 1000 ( 300 Mhz - 1000 MHz / performance) DMC : 2112 ( 528 Mhz - 2112 MHz / performance) The Kingston A2000 might not be the most energie-efficient NVMe, but other brands generally also focus on performance instead of efficiency. The above summary is made by parsing the settings from: /sys/devices/system/cpu/cpufreq/policyX/ /sys/devices/platform/fb000000.gpu/devfreq/fb000000.gpu/ /sys/devices/platform/dmc/devfreq/dmc/ /sys/module/pcie_aspm/parameters/ (You can also use the sys-tree to quickly change the settings with a script). Ondemand and conservative are generally similar for power consumption in idle mode. Earlier experiences that low power consumption and NVMe are a bad combination is true for the Rock5 as well. PowerSuperSave can not be considered a stable option for all NVMe drives. But still with lowpower solutions NVMe might be preferable to eMMC since it is slightly better protected against data loss. In performance mode, during a compilation, the consumption easily reaches 13W (with NVMe, without large USB users, without much GPU use). (I use a cheap power supply with monitoring to get the general idea of power consumption, not a calibrated solution). Finally you could use a constant power supply of 5V to lower the power consumption in idle. I would not recommend that , I think optimizing for 1.5A at peak performance is better, resulting in 9V or 12V for most cases. (Instead of PD, QC is probably cheaper and more power efficient).

Pressing escape to enter the UEFI, changing the boot order apparantly was the correct option. (Bypassing the armbian-config script). After changing the boot option I had to again issue a root password which probably means the installation is started from zero. Now I need to know if (using the 23.04-legacy image) I can change the kernel to the edge kernel. PS on the 2304 image: that probably can be counted as a success since I was (relatively easy) able to install the system on a NVMe starting with the Radxa SPi image. It would be easier to enable the 'normal' armbian-install script than just uploading and dd-ing the image to the nvme, but that's why it is still labelled as "WiP", I guess. What I want to do soon is decrease the partition size and install an edge image besides the 2304 image, including a recent 6.x-kernel. Any hints on the process are welcome! It seems that just booting the original SD card is not a working method. A new image booted from UEFI/EDK might be an option,

On the danger of sounding very stupid: I downloaded the image Armbian_23.02.3_Rock-5b_sid_edge_6.3.0 and Armbian_23.04_Rock-5b_sid_legacy_5.10.110. With the edge-image I got no display, so that seems a dead end for me. With the legacy-image I could start and I could use armbian-install to update the firmware (the powersupply is 12V fixed voltage) Now I have a booting image on SD and I wonder how I can install the image on NVMe. The only install-option I see is "7 install mtd block" (which I did). After that I expected a need to reboot and choose option 3 or something like that, but the only available option is option 7. I can see the nvme-drive and I can make volumes on the nvme using fdisk, but I don't know how to install the system. The other thing I tried is dd-ing the image to the nvme-drive, but then both nvme and SD-card failed to boot and I found myself rewriting the image on the SD-card. How can I install Armbian on NVMe using the 23.04-image?

if you still have access to a prompt I'd suggest you login and remove the iujianfeng1994-ubuntu-panfork-mesa-kinetic.list from /etc/apt/sources.list.d/ What I did: run "dpkg --get-selections > installed-pkgs" remove everything which includes panfork in the name with dpkg, manually remove the liujianfeng ppa run "apt clean" run "apt update" reinstall the desktop reinstall all the pkgs removed when removing the panfork packages (I used ""dpkg --get-selections > installed2" and diff) reboot and the desktop reappears The sunny side is, removing panfork means some weird bug where the pointer disappears after the screensaver kicks in disappeared. The dark side is, you lose hardware GPU acceleration. Alternative solution (untested): update mesa23.0~panfork~csf to git221210.120202c6757~j+1 JianFeng Liu (10 hours ago) <= wasn't there this weekend. Note that some developpers ban the panfork project, since I had the same issue (and the above bug) I dumped it for now. I'll wait to see what mesa driver gets adopted in the official armbian distribution.

I tried to boot my system to NVMe and the result of my trying was: - powered with constant 12v1.5W (i.e. PD problems are ruled out) - bootable SD-card and NVMe or - bootable eMMC and NVMe If there is no problem with the power (PD problems should be ruled out since you use the Radxa SPI image) the bootable NVMe overrules the SD or eMMC. This means the system won't start if the partitions was not setup correctly. I think you can only try this method with an NVMe which has no boot partition already. Which means the "dd if=/dev/zero of=/dev/nvme0n1 count=100" might have to be executed with an USB-NVMe drive or something. Without bootable NVMe partition, the system might start correctly. Since my eMMC is only 32GB I will have to try to boot from NVMe, so I will try to boot the NVMe. If I have to use an USB-NVMe module I would prefer to setup the NVMe without SD or eMMC. I'll try if that works. Edit: I did see you used the method mentioned in the Radxa Wiki, this is where you probabbly found the link for the SPI image. If the SPI image fails there is allways the rkdeveloptool-option.

I think the power supply might deserve it's own topic. Like balbes mentioned PD is meant for devices with internal battery. There it saves the battery during fast charging by preventing overcharging. The Rock 5B is further 'borked' since the negotiation starts after the system starts. The advantage is it can be open source (more or less), but the big disadvantage it is so slow most PD chargers stop negotiating during system start in the meantime. If you realise that the power supply in the Rock 5B (IP2315) is just a step-down converter with some logic and a PD car-adapter adds an step-up adapter to the equation you might realise it makes no sence to operate the power input at 20V. While the resistance in the cable might be minimized the power loss in the step-down and the step-up converters are maximized. Most power supplies can achieve 95% efficiency, but cheap step-up/step-down converters can only achieve that when V_in is almost equal to V_out. Normal PD-adapter should work more efficient than 12V car-adapters, but even then if they very efficiently produce 20V which the R5B very inefficiently transformes to 3.3-5V does that make sense? A 20W PD car-adapter adds roughly 0.5W to the power consumption. With a 65W/20V PD car-adapter the adapter might add more, but the step-down converter in the R5B will definitely work more inefficient than at 9V.