Netgear GS308T - Patching with potential MTD issues

LS,

I have two identical Netgear GS308T v1 switches, bought at the same time, initial installation of OpenWRT at the same time.

Quite a while ago (months) I decided to patch one of them with a new snapshot from the firmware selector. This caused a soft brick where I had to open it up and solder wires to the serial port in order to get it to work. I've patched that switched again with a recent snapshot, and this works fine.

I now want to patch the unpatched switch, but I'm afraid of a repeat of the first one. One of the difference I do see is the MTD layout:

Patched switch:
OpenWrt SNAPSHOT, r18460-def9565be6
root@switch_utility_closet:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 000e0000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "u-boot-env2"
mtd3: 00100000 00010000 "jffs"
mtd4: 00100000 00010000 "jffs2"
mtd5: 00e80000 00010000 "firmware"
mtd6: 00240000 00010000 "kernel"
mtd7: 00c40000 00010000 "rootfs"
mtd8: 00a30000 00010000 "rootfs_data"
mtd9: 00e80000 00010000 "runtime2"

Unpatched switch:
OpenWrt SNAPSHOT, r16915-bb749e49a6
root@switch2:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 000e0000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "u-boot-env2"
mtd3: 00100000 00010000 "jffs"
mtd4: 00100000 00010000 "jffs2"
mtd5: 00e80000 00010000 "firmware"
mtd6: 00210000 00010000 "kernel"
mtd7: 00c70000 00010000 "rootfs"
mtd8: 00a70000 00010000 "rootfs_data"
mtd9: 00e80000 00010000 "runtime2"

Can this cause issues with patching? Can I somehow mitigate it by not doing a sysupgrade but somehow doing something different?

You're looking at sizes, not addresses. Check the logread/dmesg output right after boot, it contains start addresses and not just the sizes.

Sysupgrade does not change partition sizes. What OpenWrt prints is merely what's set in the DTS + the dynamic split OpenWrt itself makes between its own kernel (mtd6) and rootfs partitions. On top of that, rootfs contains a nested rootfs_data partition which makes it look even more confusing to the layman's eye (which mine is as well).

A wild guess: your first switch is on kernel 5.10 (newer, bigger kernel that needs more space) and the old one is still on kernel 5.4. Am I right? :wink:

As a rule of thumb, blindly sysupgrading is a bad thing if you're on master. Doesn't hurt to use -n once in a while, epsecially if the old build has some mileage on it.

E.g. on an AP here:

Sun Jan  2 11:27:12 2022 kern.info kernel: [    0.891161] spi-mt7621 1e000b00.spi: sys_freq: 220000000
Sun Jan  2 11:27:12 2022 kern.info kernel: [    0.911901] spi-nor spi0.0: w25q128 (16384 Kbytes)
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    0.921531] 8 fixed-partitions partitions found on MTD device spi0.0
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    0.934188] Creating 8 MTD partitions on "spi0.0":
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    0.943739] 0x000000000000-0x000000080000 : "u-boot"
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    0.954789] 0x000000080000-0x000000090000 : "partition-table"
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    0.967308] 0x000000090000-0x0000000a0000 : "product-info"
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    0.979353] 0x0000000a0000-0x000000dc0000 : "firmware"
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    0.991017] 2 tplink-fw partitions found on MTD device firmware
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    1.002840] Creating 2 MTD partitions on "firmware":
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    1.012739] 0x000000000000-0x000000230293 : "kernel"
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    1.023672] 0x000000230293-0x000000d20000 : "rootfs"
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    1.034614] mtd: device 5 (rootfs) set to be root filesystem
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    1.046023] 1 squashfs-split partitions found on MTD device rootfs
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    1.058376] 0x000000880000-0x000000d20000 : "rootfs_data"
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    1.070249] 0x000000dc0000-0x000000df0000 : "user-config"
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    1.082115] 0x000000f30000-0x000000fb0000 : "mutil-log"
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    1.093633] 0x000000fb0000-0x000000ff0000 : "oops"
Sun Jan  2 11:27:12 2022 kern.notice kernel: [    1.104404] 0x000000ff0000-0x000001000000 : "radio"

Ah yes, you're right... should've looked at the column names a bit closer :man_facepalming:

Indeed 5.4 vs 5.10, so that would explain the size difference.

I don't mind losing my config, should I also add -p, or some other flags? I really don't want to have to open that thing up and mess around with soldering again... Especially since I still don't really know what went wrong in the first run...

I'm not aware of any breaking changes with 5.10 on the realtek target at the moment. I do know when my G108T v3 went AWOL upon flashing OpenWrt, it turned out to be the default management VLAN thingy. OpenWrt was just working fine when I hooked up serial. So you might not need -n. I've been switching my GS1900-8HP v1 between master and 21.02 a few times without too many problems (I think).