AC86U: boot the prior "bootfs_update" mtd as is?

[bibikalka]

A slightly esoteric question. As far as I understand, my AC86 has 2 sets of system partitions, one active, the other contains the prior firmware, and will get the next one (_update partitions below).

admin@RT-AC86U-9988:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 05aa0000 00020000 "rootfs"
mtd1: 05a80000 00020000 "rootfs_update"
mtd2: 00800000 00020000 "data"
mtd3: 00100000 00020000 "nvram"
mtd4: 05f00000 00020000 "image_update"
mtd5: 05f00000 00020000 "image"
mtd6: 00460000 00020000 "bootfs"
mtd7: 00480000 00020000 "bootfs_update"
mtd8: 00100000 00020000 "misc3"
mtd9: 02f00000 00020000 "misc2"
mtd10: 00800000 00020000 "misc1"
mtd11: 0557e000 0001f000 "rootfs_ubifs"

After an update, rootfs and rootfs_update will swap, so the prior version will remain in the inactive set. Here is the relevant log with an update in between, where the partitions got swapped judging by the addresses:

Jun  4 12:45:00 kernel: 0x000006460000-0x00000bf00000 : "rootfs"
Jun  4 12:45:00 kernel: 0x000000580000-0x000006000000 : "rootfs_update"
Jun  4 12:45:00 kernel: ubi0: attached mtd0 (name "rootfs", size 90 MiB)
Jun  4 12:45:00 kernel: UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs_ubifs", R/O mode
Jun  4 18:00:04 kernel: >>>>> For primary mtd partition rootfs, cferam/vmlinux.lz mounted as JFFS2, vmlinux fs mounted as UBIFS <<<<<
Jun  4 18:00:04 kernel: Secondary mtd partition rootfs_update detected as JFFS2 for cferam/vmlinux source and UBIFS for vmlinux filesystem
Jun  4 18:00:04 kernel: 0x000000580000-0x000006000000 : "rootfs"
Jun  4 18:00:04 kernel: 0x000006460000-0x00000bf00000 : "rootfs_update"
Jun  4 18:00:04 kernel: ubi0: volume 0 ("rootfs_ubifs") re-sized from 592 to 705 LEBs

Question: can I boot the inactive set of partitions by some simple command? Basically, I want to boot the prior firmware that I had without writing it again. Some variable somewhere tells the router which set of partitions to boot - is it possible to flip that manually without hammering the flash too much? It's doable on Android if it has A/B partition sets, but what about here?

 

[bibikalka]

... in this device 2 firmware are in the router
- the first old worker
- the second new (update) on which the router can work
If the new one does not load, the router will automatically start the old one.
...

Did you try interrupting the boot process few times? Turn the router on, wait 15-20 sec., turn it off, repeat. Do it 5 times in a row and then let it boot. See what firmware it boots with. Yours is booting somehow and doesn't trigger the image switch. I don't know if it works on this router, but used to work on Linksys routers with dual boot partitions.

Found this in old threads. I guess one can boot the other partitions - but how?


@RMerlin - any guidance on this? I guess one can try to flash a properly formatted by empty update file, so it'd do nothing, and then switch partition sets. Or, just use the same code that does the upgrade, but skip writing to flash part, and just do the final bits which is the partition swap and reboot.

 

[RMerlin]

I don't know, I never looked at it. You would have to dive into the code, provided the relevant code is open sourced.

 

[bibikalka]

I don't know, I never looked at it. You would have to dive into the code, provided the relevant code is open sourced.

OK!

I am now thinking that emptying an update file so that it writes nothing, but makes the system think that an update has happened and switches the partitions, might be the least intrusive. Do you think an empty RT-AC86U_386.00_0_ubi.w could work?

What would be the quickest way to empty the update file?

 

[RMerlin]

I am now thinking that emptying an update file so that it writes nothing, but makes the system think that an update has happened and switches the partitions, might be the least intrusive. Do you think an empty RT-AC86U_386.00_0_ubi.w could work?

That won't work. For obvious reasons, the update process validates the integrity of the file before writing it to flash.

 

[bibikalka]

That won't work. For obvious reasons, the update process validates the integrity of the file before writing it to flash.

What I meant is that when an update file is created such as when a new firmware version is packaged, one could potentially create a blank update file that will not write anything, but will trigger the partition swap.

But all I actually needed was to pull the old dnsmasq 2.89 from RT-AC86U_386.12_4, which was sitting in my rootfs_update as I flashed it before to test. So I managed to simply mount rootfs_update like this, and copy the old version:

admin@RT-AC86U-9988:/# mkdir /tmp/mnt/old
admin@RT-AC86U-9988:/# ubiattach /dev/ubi_ctrl -m 1 -O 2048
UBI device number 1, total 724 LEBs (91930624 bytes, 87.7 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
admin@RT-AC86U-9988:/# /bin/mount -t ubifs ubi1_0 /tmp/mnt/old/
admin@RT-AC86U-9988:/# mkdir /jffs/scripts/289
admin@RT-AC86U-9988:/# cp -pr /tmp/mnt/old/usr/sbin/dnsmasq /jffs/scripts/289
admin@RT-AC86U-9988:/# umount /tmp/mnt/old/

 

[sfx2000]

That won't work. For obvious reasons, the update process validates the integrity of the file before writing it to flash.

I agree - not worth making any changes here...