hi,

sorry for the delay. I didn't expect that kind of sharing.

your fix is not enough: when later the partition is written, it is via 'mtd -n write' which expects an erased partition.

i will do a PR ASAP to fix this by invalidating the start of the kernel partition instead of erasing it, this is enough to invalidate the kernel CRC.

thanks!



On 4/29/22 11:37, Bjørn Mork wrote:
Commit ecbcc0b59551 bricks devices where a ubi rootfs and a raw
kernel shares the same mtd partition.

This is the case for the ZyXEL NR7101 for example.  The OEM bootloader
has no UBI support.  OpenWrt splits the "Kernel" mtd partition in a raw
kernel part used by the bootloader and a UBI part used for the OpenWrt
rootfs and rootfs_data.  Running mtd erase on this partition during
during upgrade erases the UBI part and results in a soft brick.

Fixes: ecbcc0b59551 ("base-files: safer sysupgrade.tar for kernel-out-of-UBI")
Signed-off-by: Bjørn Mork <bj...@mork.no>
---

I'm not sure what the proper fix for this is.  I believe the intended
functionality of commit ecbcc0b59551 should be re-implemented somehow.

I guess the real bug might be the dual usage of this partition?  But
I'm pretty sure I found that as an example in some other device,
without being able to point it out now.

But I believe we need this immediate fix in any case, since this is a
bricking regression.


  package/base-files/files/lib/upgrade/nand.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index 5ecdb0ff2363..5e5607d35cd8 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -305,7 +305,7 @@ nand_upgrade_tar() {
        local ubi_kernel_length
        if [ "$kernel_length" ]; then
                if [ "$kernel_mtd" ]; then
-                       mtd erase "$CI_KERNPART"
+                       : # mtd erase "$CI_KERNPART"
                else
                        ubi_kernel_length="$kernel_length"
                fi

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to