On Rock5B with Radxa's Debian image, always use rsetup to upgrade the system, never apt upgrade

rock · June 3, 2025, 1:57pm

Hi,

The latest stable Debian distributed for Rock5B by Radxa is this Bookworm image: https://github.com/radxa-build/rock-5b/releases/download/rsdk-b5/rock-5b_bookworm_kde_b5.output.img.xz

For clarity, doing “apt update; apt upgrade” is ALWAYS safe, right?

I would not want to take the risk that Debian had released a new kernel or u-boot version, and that version turns out to now have the RK3588 Rock5B specific patches, etc.

Inside https://docs.radxa.com/en/rock5/rock5b/radxa-os/using-apt I see a command under “Please run the following command to add the RadxaOS Vendor repository:”, it says “VENDOR… deb…”, and then “sudo apt-get dist-upgrade --allow-downgrades task-rockchip; sudo apt-get dist-upgrade --allow-downgrades”.

But, on the downloaded Debian image above these steps are already done so I don’t need to do them, right, or?

It would be a shame if a Rock5B suddenly is rendered unbootable and a whole system reinstall would be needed.

Right now I noticed apt upgrade shows this: “update-initramfs: Generating /boot/initrd.img-6.1.84-6-rk2410”, so kernel upgrades do happen.

The next line was “Couldn’t find EFI system partition. It is recommended to mount it to /boot or /efi.”.

It also said “Unpacking u-boot-rk2410 (2017.09-45-b9a0522) …”, not sure of what consequence that is.

Also interestingly “aptitude upgrade” started with this:

# aptitude upgrade
The following packages will be DOWNGRADED:
  gstreamer1.0-plugins-good
The following NEW packages will be installed:
  u-boot-rk2410{a}
The following packages will be REMOVED:
  u-boot-rknext{u}

This is all correct and you always test the Debian updates before they become reachable via apt update; apt upgrade, right?

Thanks

@RadxaYuntian @jack

Oh, I see Yuntian followed up here Rock5B Radxa Debian 12 image question: OK to install u-boot-rk2410 and remove u-boot-rknext? and said apt update; apt upgrade is NOT safe.

And refered here https://docs.radxa.com/en/template/sbc/os-config/rsetup#system-update .

Apparently rsetup has a Debian update function in it now, which is safe and is the designated way to update a Rock5B.

@radxaYuntian In which situations does it actually matter to use rsetup , i.e. what kind of situations does apt update; apt upgrade get into so it breaks the Debian installation and makes it unbootable? E.g. does it install broken kernels, or break u-boot etc.?

RadxaYuntian · May 19, 2025, 7:06am

The primary mechanism of how apt upgrade breaks the system was explained in the linked reply already: it doesn’t remove packages which results in partial upgrade. Whether that will actually break the system depends on what packages was actually installed before it, so the older the image is the more likely it will be broken by it.

The breakage is almost never caused by broken kernels, since we usually catch that in the testing so it won’t be released to production channel (we have separate package repositories for this). U-Boot packages won’t modify the installed bootloader automatically. It is more like a resource/add-on package, where rsetup uses to update the bootloader with user confirmation. The breakage is usually caused by broken system configurations or or mismatched packages, which is why the potential issue was listed with a list of system anomalies.

rock · June 3, 2025, 10:42am

@RadxaYuntian Hi Yuntian,

OK I understand that it’s common on many ARM SBC:s that “aptitude upgrade” not is permitted. So from now and on “rsetup” must be used for the function “aptitude update; aptitude upgrade”, to ensure that only a patched kernel and correct boot code is installed. Thanks for letting me know.

On the machine I accidentally ran “aptitude upgrade”, I see now that it boots all to the point of having a login prompt on the TTY serial connection, but, it appears the onboard Ethernet controller is not found, because running “ip a” does not show it. That’s an interesting problem.

RadxaYuntian · June 3, 2025, 11:16am

Because we replaced the network card driver from r8125 to kernel provided r8169. Partial upgrade broke it.

rock · June 3, 2025, 3:09pm

Ok.

Within the “rsetup” update on the freshly installed Radxa Debian distribution, I was asked this:

Setting up libfdisk1:arm64 (2.38.1-5+deb12u3) ...
Setting up liblzma-dev:arm64 (5.4.1-1) ...
Setting up libubsan1:arm64 (12.2.0-14+deb12u1) ...
Setting up libsrt1.5-gnutls:arm64 (1.5.1-1+deb12u1) ...
Setting up mount (2.38.1-5+deb12u3) ...
Setting up libhwasan0:arm64 (12.2.0-14+deb12u1) ...
Setting up radxa-desktop-branding (0.1.3) ...

Configuration file '/etc/skel/.face'
 ==> Deleted (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** .face (Y/I/N/O/D/Z) [default=N] ?

I just pressed enter and it continued with other stuff:

update-alternatives: using /usr/share/images/radxa-logos to provide /usr/share/images/vendor-logos (vendor-logos) in auto mode
update-alternatives: using /usr/share/desktop-base/radxa-theme to provide /usr/share/desktop-base/active-theme (desktop-theme) in auto mode
Setting up libqt5dbus5:arm64 (5.15.8+dfsg-11+deb12u3) ...
Setting up libtiff6:arm64 (4.5.0-6+deb12u2) ...
Setting up libasan8:arm64 (12.2.0-14+deb12u1) ...
Setting up libxslt1.1:arm64 (1.1.35-1+deb12u1) ...
Setting up linux-image-6.1.84-6-rk2410 (6.1.84-6) ...
dkms: running auto installation service for kernel 6.1.84-6-rk2410.

I guess that was the right thing to do. If not let me know.

At the end it said this:

It also said some daemons are outdated. Just clicked Ok. And then ran reboot. Looks like all worked fine.

rock · June 3, 2025, 3:30pm

@RadxaYuntian After “rsetup”, the onboard Ethernet disappeared again.

lspci shows “0004:41:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)”.

The rows surrounding 0004:41:00.0 in dmesg are:

[    5.257920] pci 0004:40:00.0: [1d87:3588] type 01 class 0x060400
[    5.257955] pci 0004:40:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    5.258034] pci 0004:40:00.0: supports D1 D2
[    5.258045] pci 0004:40:00.0: PME# supported from D0 D1 D3hot
[    5.271568] pci 0004:40:00.0: Primary bus is hard wired to 0
[    5.271594] pci 0004:40:00.0: bridge configuration invalid ([bus 01-ff]), recc
onfiguring
[    5.271912] pci 0004:41:00.0: [10ec:8125] type 00 class 0x020000
[    5.271983] pci 0004:41:00.0: reg 0x10: [io  0x0000-0x00ff]
[    5.272059] pci 0004:41:00.0: reg 0x18: [mem 0x00000000-0x0000ffff 64bit]
[    5.272113] pci 0004:41:00.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit]
[    5.272513] pci 0004:41:00.0: supports D1 D2
[    5.272524] pci 0004:41:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    5.281694] pci_bus 0004:41: busn_res: [bus 41-4f] end is updated to 41
[    5.281752] pci 0004:40:00.0: BAR 8: assigned [mem 0xf4200000-0xf42fffff]
[    5.281769] pci 0004:40:00.0: BAR 6: assigned [mem 0xf4300000-0xf430ffff preff
]
[    5.281785] pci 0004:40:00.0: BAR 7: assigned [io  0x200000-0x200fff]
[    5.281806] pci 0004:41:00.0: BAR 2: assigned [mem 0xf4200000-0xf420ffff 64bii
t]
[    5.281856] pci 0004:41:00.0: BAR 4: assigned [mem 0xf4210000-0xf4213fff 64bii
t]
[    5.281900] pci 0004:41:00.0: BAR 0: assigned [io  0x200000-0x2000ff]
[    5.281924] pci 0004:40:00.0: PCI bridge to [bus 41]
[    5.281937] pci 0004:40:00.0:   bridge window [io  0x200000-0x200fff]
[    5.281950] pci 0004:40:00.0:   bridge window [mem 0xf4200000-0xf42fffff]
[    5.287029] pcieport 0004:40:00.0: PME: Signaling with IRQ 158
[    5.289814] dwmmc_rockchip fe2d0000.mmc: No normal pinctrl state
[    5.289827] dwmmc_rockchip fe2d0000.mmc: No idle pinctrl state
[    5.289877] dwmmc_rockchip fe2d0000.mmc: IDMAC supports 32-bit address mode.
[    5.289939] dwmmc_rockchip fe2d0000.mmc: Using internal DMA controller.
[    5.289954] dwmmc_rockchip fe2d0000.mmc: Version ID is 270a
[    5.289996] dwmmc_rockchip fe2d0000.mmc: DW MMC controller at irq 103,32 bit
host data width,256 deep fifo
[    5.290143] dwmmc_rockchip fe2d0000.mmc: Looking up vmmc-supply from device tt

Is this a Linux kernel problem or what is it?

To make the machine work without reinstalling from scratch, I guess I should command the system to use the previous kernel?

# ls -al /boot
total 114120
drwxr-xr-x  6 root root     4096 Jun  3 15:09 .
drwxr-xr-x 19 root root     4096 Jun  3 13:44 ..
-rw-r--r--  1 root root   234718 Jul 31  2024 config-6.1.43-15-rk2312
-rw-r--r--  1 root root   239005 Apr 18 07:23 config-6.1.84-6-rk2410
drwxr-xr-x  2 root root     4096 Jun  3 15:02 dtbo
drwxr-xr-x  2 root root     4096 Jun  3 14:59 dtbo_old
drwxr-xr-x  2 root root    16384 Jan  1  1970 efi
drwxr-xr-x  2 root root     4096 Jun  3 15:03 extlinux
-rw-r--r--  1 root root       93 Aug  8  2024 hw_intfc.conf
-rw-r--r--  1 root root 16021112 Aug  8  2024 initrd.img-6.1.43-15-rk2312
-rw-r--r--  1 root root 16718700 Jun  3 15:09 initrd.img-6.1.84-6-rk2410
-rw-r--r--  1 root root  6548484 Jul 31  2024 System.map-6.1.43-15-rk2312
-rw-r--r--  1 root root  6599056 Apr 18 07:23 System.map-6.1.84-6-rk2410
-rw-r--r--  1 root root      179 Aug  8  2024 uEnv.txt
-rw-r--r--  1 root root 35246592 Jul 31  2024 vmlinuz-6.1.43-15-rk2312
-rw-r--r--  1 root root 35187200 Apr 18 07:23 vmlinuz-6.1.84-6-rk2410

In /boot/extlinux/extlinux.conf , I changed “default” from “l0” which means 6.1.84-6-rk2410, to “l1” which means 6.1.43-15-rk2312 . And then “reboot”:ed. And the onboard Ethernet works now. I’ll keep it like this.

What’s wrong with the new kernel, do you see this issue too?

After restoring the kernel to the one that works, and running “aptitude install -y something”, I get this confirmation message that the package system realizes I have forced another kernel version, and it says it will not change it to the broken kernel automatically. That’s good.

RadxaYuntian · June 4, 2025, 2:28am

We are currently in the process of updating Rockchip SDK (which is why you see kernel patch version change). Rockchip SDK is not online upgradable, so a fresh reinstall is needed.

rock · June 4, 2025, 2:20pm

I had a total disaster come out of this reinstallation. Wrote it up in a separate thread: A horrible failure report in latest Radxa Debian - no networking due to kernel, NetworkManager or other component broken. ifupdown a fix?