This release adds support for Raspberry Pi 5 based gateways.
Hi,
During the base image sysupgrade (from 4.7.1 to 4.8.1), does anybody have problem with kmodloader during boot, that freezes the raspberry PI 3?
After base image sysupgrade, which reboot the raspberry PI 3, it freezes at this line kmodloader : done loading kernel modules from /etc/modules.d/
Has anyone had this same problem?
That is strange, because nothing OS-related has changed for Raspberry Pi 3 targets (except from the version number). Let me see if I can reproduce this issue.
OpenWrt.python3 dependency in Dockerfile-devel (after Debian update).The problem that I´ve reported 2 months before (about a base image sysupgrade (from 4.7.1 to 4.8.1) ) still remains unsolved even if I try to upgrade from 4.7.1 to the new 4.8.2 on a same raspberry PI 3B+. I spend some time for analysis the problem and, after upgrade from 4.7.1 to 4.8.2 now, it appears that the root filesystem is readonly mode after the upgrade. The two lines below show during boot process:
Maybe this implies the problem that the kernel doesnât mount these 3 filesystem:
If I try to do a fresh base image install (4.8.1 or 4.8.2), it doesnât mount the above 3 filesystem eitherâŚ
Now, if I try a fresh base image install (4.7.1) it works like a charm.
Any ideas ?
It took some time to troubleshoot, but it seems to be this issue:
In short, there is a boot partition and a rootfs partition. The rootfs partition is filled with the read-only sqashfs, the remaining space is used by a loopback device (/dev/loop0). OpenWrt does an auto-detection if the loopback device has already been initialized, in which case it will mount it. The issue is that when there is already data at the offset where the /dev/loop0 starts, it might look like it has already been initialized, where in fact this is data from before the sysupgrade. OpenWrt will try to mount it and fails.
I have created this PR:
And this patch for the next GW OS version (until the change is available in OpenWrt):
Index: openwrt/target/linux/bcm27xx/image/gen_rpi_sdcard_img.sh
===================================================================
--- openwrt.orig/target/linux/bcm27xx/image/gen_rpi_sdcard_img.sh
+++ openwrt/target/linux/bcm27xx/image/gen_rpi_sdcard_img.sh
@@ -23,6 +23,8 @@ set $(ptgen -o $OUTPUT -h $head -s $sect
BOOTOFFSET="$(($1 / 512))"
ROOTFSOFFSET="$(($3 / 512))"
+ROOTFSSIZE="$(($4 / 512))"
dd bs=512 if="$BOOTFS" of="$OUTPUT" seek="$BOOTOFFSET" conv=notrunc
+dd bs=512 if=/dev/zero of="$OUTPUT" seek="$((ROOTFSOFFSET+ROOTFSSIZE-1))" count=1 conv=notrunc
dd bs=512 if="$ROOTFS" of="$OUTPUT" seek="$ROOTFSOFFSET" conv=notrunc
There might still be some optimizations possible but that needs some feedback from people that know how this detection is implemented in OpenWrt, e.g. like pointed out here:
@fbarreto after some more research + feedback from the OpenWrt community, I have optimized the fix: rpi: Only add 1MB padding after rootfs image data. ¡ chirpstack/chirpstack-gateway-os@1bb631e ¡ GitHub.
I have also created a PR to fix this issue in OpenWrt: bcm27xx: Add padding after writing rootfs to image to fix possible device bricking after sysupgrade by brocaar ¡ Pull Request #19997 ¡ openwrt/openwrt ¡ GitHub.
This release fixes an issue with the Raspberry Pi images that could cause the bootprocess of the Raspberry Pi to fail after an upgrade. For more details about this issue, please see:
In case you are affected by this issue and you have access to the terminal (e.g. USB keyboard + HDMI display) you could try the following command to restore the Raspberry Pi: firstboot && reboot. firstboot will normally reset the overlayfs containing the configuration, but as in case of this issue OpenWrt fails to mount it, this will cause OpenWrt to re-create the overlayfs and restore the configuration backup to it after the reboot.
Very good! I tried it here and now it worked⌠thanks!