Same, with rock 4c+ after upgrading to linux-image-5.10.110-37 there were random crashes/checksum errors all around… Downgrading to 5.10.110-35 fixed that.
Crashes since last kernel updates
ROCK 4 C+
Linux rock4 5.10.110-37-rockchip #27a257394 SMP Thu May 23 02:38:59 UTC 2024 aarch64 GNU/Linux
How to change back to -35 for now?
You can download the package here:
Use sudo dpkg -i xxx.deb to install, then create /etc/apt/preferences.d/radxa-kernel-pin to stop apt from upgrading related packages:
Package: linux-headers-rock-4c-plus
Pin: version 5.10.110-35-8ee7c8a
Pin-Priority: 2000
Package: linux-image-rock-4c-plus
Pin: version 5.10.110-35-8ee7c8a
Pin-Priority: 2000
Finally use apt to remove kernel installed on your system, as they have a higher version number, and will be preferred by the boot process.
Isn’t the -35 Kernel and rootfs still on the system and I can change some config, so it’s booted?
Or only -36 now and -35 gone with update to -37?
Since the -37 update I get asked if I wan’t to remove the -35 headers and some more with autoremove.
So that should be still on the system.
May be I wait till @usatiuk tells what he have done.
radxa@rock4:/boot$ ls -1
config-5.10.110-35-rockchip
config-5.10.110-36-rockchip
config-5.10.110-37-rockchip
dtbo
dtbo_old
efi
extlinux
hw_intfc.conf
initrd.img-5.10.110-35-rockchip
initrd.img-5.10.110-36-rockchip
initrd.img-5.10.110-37-rockchip
System.map-5.10.110-35-rockchip
System.map-5.10.110-36-rockchip
System.map-5.10.110-37-rockchip
uEnv.txt
vmlinuz-5.10.110-35-rockchip
vmlinuz-5.10.110-36-rockchip
vmlinuz-5.10.110-37-rockchip
I didn’t do anything with changing configs/pinning, I just removed the new kernel with sudo apt remove linux-image-5.10.110-37-rockchip:arm64 linux-headers-5.10.110-37-rockchip:arm64 and after it used the previous one I had installed (-35, so idk if -36 works fine or not)
H’m may be somebody know how to config -35 till the bug is fixed.
I don’t like to just remove -36 and -37 and hope -35 will run then
There is an dtbo and dtbo-old dir and dtbo-old seems to have date of -36.
I can try to move the -36 and -37 files to a subdir and give it a try.
If nothing works I can move the files back on another system.
Or best make a partition image and try after, should have done that before…
In /boot/extlinux/extlinux.conf, there is default l0 that I assume specifies the default config to boot. You can try changing it to the label that has the older kernel there, maybe it will work…
1 Like
default l2
(= …35 ) boots …35 and my TikTok works again - Thank You
Would still recommend you to do the apt package pin, as otherwise it might be broken the next time you upgrade the kernel.
@Stephen might want to check what was changed between those 2 releases that cause TikTok to not working.
usatiuk told having other problems too, TikTok is my only use.
Quite demanding and probably not well programmed, especially Theatre Mode.
With that last kernels whole X crashed till relogin some times.
Yep, I was just updating my home server, and after updating the kernel, updating docker containers (pulling) was failing with various integrity/checksum errors, and existing containers would crash sometimes… After downgrade everything works fine so far
/boot/extlinux/extlinux.conf comments say file autogerated, don’t change
So may be it is rewritten to default l0 - newest kernel on next kernel update anyway, but I will have a look on next update…
Todays update “radxa-firmware radxa-overlays-dkms”
seems not have improved .37 kernel, or is a new one.
I’ve tried .37 - same errors and haven’t seen some newer one.
I’m back to .35 again.
Same issue for us on multiple systems (5+).
With .37 and .38 we observe frequent integrity/checksum errors when pulling docker images.
Also communication with a USB zigbee dongle freezes randomly.
Also gave .38 a try after last updates 2-3 day ago, still crashes soon, back to .35
YES .39 no crashes
What exact was here? Some specific github commit with a fix? We suffer from rare random stability issues (internal compiler errors during GCC building, random apps crashes, corrupted files with multithreaded GZip etc.) on our Radxa ROCK 4B+ with custom-built kernel (rbuild+bsp), so I would like to verify if it could be the same issue.