OpenMesh MR1750 no longer upgrading

Hello All,

Short story: I have flashed my OpenMesh MR1750 with 18.06.1 and now sysupgrade's are not applied.

@thess, just saw the bot message about real people, so I'm adding you at random since you are a sysadmin:-P

So, I have a small wifi mesh network, I have spent some time working with various software to build images, but eventually went with building my own.

I have flashed this custom 18.06.1 image (mostly just network and wifi setup) on a few WiFi nodes, including the MR1750 nodes. Problem is, I can't seem to flash new sysupgrade or factory images, even the ones from OpenWrt. I run the sysupgrade -n /tmp/<imagename.bin> command and the node restarts, then seems to take some time with flashing lights, then reboots again back into the unflashed image.

I have tried a cold reboot, and various images, nothing changes.

So, to summarize. I managed to flash the LEDE factory image over the OpenMesh image. I even upgraded from 17.* to 18.06.1 but after that, no further sysupgrades will take.

There is no error output, just the usual "no metadata".

What info can I provide to find the issue here? Can it be that it's the same version?

How can I get my sysupgrades to take? At the moment, it just needs to over write the config on the /rom/ but in future I want to actually upgrade too:-P

Edit1: I will be getting hold of a UART to USB cable and checking out the serial. Hopefully I can actually figure this one out. Will post some details once I have them.

Edit2:

I think I have found the problem.

This device is supposed to have 2 firmware partitions. See here:

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00060000 00010000 "custom"
mtd3: 007a0000 00010000 "inactive"
mtd4: 00150000 00010000 "kernel"
mtd5: 00650000 00010000 "rootfs"
mtd6: 00440000 00010000 "rootfs_data"
mtd7: 00010000 00010000 "ART"

The inactive one is where the new firmware is flashed. See the logs from an attempted sysupgrade (thanks to UART):

root@<snip>:/# sysupgrade -n /tmp/openwrt-18.06.1-ar71xx-generic-mr1750-squashfs-sysupgrade1.bin 
Image metadata not found
Commencing upgrade. Closing all shell sessions.
Watchdog handover: fd=3
- watchdog -
killall: telnetd: no process killed
Sending TERM to remaining processes ... logd dnsmasq netifd odhcpd hostapd [  728.872688] device ntpd sleep ubusd sh 
Sending KILL to remaining processes ... 
Switching to ramdisk...
Performing system upgrade...
Unlocking inactive ...
Erasing inactive ...
Unlocking inactive ...
Seeking on mtd device 'inactive' to: 1376256

Writing from <stdin> to inactive ...     
Unlocking inactive ...

Writing from <stdin> to inactive ...     
ash: fw_setenv: not found
failed to update U-Boot environment
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
[  837.621000] reboot: Restarting system

There seems to be a lot of unlocking and all sorts going on there. But I think the main issue is that when it tries to modify the env for the bootloader, it can't.

I can run the fw_setenv command manually. Here's the output of fw_printenv:

bootargs=console=ttyS0,115200 rootfstype=squashfs,jffs2 init=/etc/preinit board=MR1750
bootcmd=test -n "${preboot}" && run preboot; test -n "${bootseq}" || bootseq=1,2; run set_bootargs_1; run set_bootargs_2; boot ${bootseq}
bootdelay=4
baudrate=115200
ipaddr=192.168.100.9
serverip=192.168.100.8
imagechk=test -n "${check_skip}" || check_skip=1 && datachk vmlinux,rootfs
preboot=flashit 0x80100000 fwupgrade.cfg
bootcmd_0=tftp 0x81000000 vmlinux-initramfs.bin && bootm 0x81000000
bootargs_0=console=ttyS0,115200 rootfstype=squashfs,jffs2 init=/etc/preinit board=MR1750 root=31:04 mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),384k(custom),1280k(kernel),6528k(rootfs),7808k(inactive),64k(ART)
bootcmd_1=run imagechk && bootm 0x9f0b0000
bootcmd_2=run imagechk && bootm 0x9f850000
set_bootargs_1=set bootargs_1 ${bootargs} root=31:04 mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),384k(custom),${kernel_size_1}k(kernel),${rootfs_size_1}k(rootfs),7808k(inactive),64k(ART)
set_bootargs_2=set bootargs_2 ${bootargs} root=31:05 mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),384k(custom),7808k(inactive),${kernel_size_2}k(kernel),${rootfs_size_2}k(rootfs),64k(ART)
stdin=serial
stdout=serial
stderr=serial
ethaddr=<snip>
ethact=eth0
kernel_size_1=1280
rootfs_size_1=6528
kernel_size_2=1344
rootfs_size_2=6464
bootseq=2,1
vmlinux_start_addr=0x9f850000
vmlinux_size=0x0014dd1a
vmlinux_checksum=ddb8d84e316d72fc0c57261804733fd0
rootfs_start_addr=0x9f9a0000
rootfs_size=0x200000
rootfs_checksum=27524fb8c2cc05e44f0a41612a092a33

I tried to modify bootseq=2,1 to bootseq=1,2 but this then made the node go into a boot loop. It failed to mount the rootfs and I had to flash back to stock (tftp, which requires a signature for the firmware...), then reflash openwrt from stock (which worked perfectly). I still cannot sysupgrade.

Does anyone know what env variables I need to change manually to make this work?

I have seen the line: ash: fw_setenv: not found mentioned elsewhere in other bug reports and forums, but none of them get anywhere. I think there is a regression here with OpenWRT, because the stock sysupgrade worked, as well as 17.

How can I give this more visibility? Or mention the person who maintains the MR1750 Image? Also, I have some UART info and pictures for the wiki.

@ajcollett - Thanks for the mention however, there are far more people here who can possibly help you other than I with this problem.

Seasons Greetings...

@thess seasons greetings to you too! Thanks for the reply. Sorry for bugging you, I had no idea who to mention :slight_smile: I'll try out Reddit.

I'd be interested in contributing to the firmware page. Once I have a clue I'll read up on that. :smile:

I don't think I can help you with the firmware issue, but I'd be interested in seeing your config files. I've spent too long trying to encrypt an OpenWrt 802.11s mesh without success.

@oavaldezi I can share with you what I have done. However, I have not gotten the encrypted mesh working either (rather, I haven't deployed it). I'll edit with a link to it soon.

On another note, does anyone know if this looks right?

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00060000 00010000 "custom"
mtd3: 007a0000 00010000 "inactive"
mtd4: 00150000 00010000 "kernel"
mtd5: 00650000 00010000 "rootfs"
mtd6: 00440000 00010000 "rootfs_data"
mtd7: 00010000 00010000 "ART"

There's no firmware partition, and that custom and inactive partition looks weird... I will try see if 17 is the same.

Edit: This is the same as what the original looks like, so I am lost again.

Original: https://github.com/true-systems/om5p-ac-v2-unlocker/wiki/Open-Mesh-MR1750-details

@oavaldezi Just to clarify, have you gotten the un-encrypted mesh working? My configs make use of VLANs across the mesh to separate house traffic. But I think I stayed away from encryption because of how many issues others seem to have had. Once I can safely flash my MR1750's then I can explore it again and revert back.

Unencrypted mesh works. I've struggled with encryption without success. I've discussed the issue in this thread and this other one.

Sup all!

Okay so I finally fixed this. Turns out it is fixed in 18.06.2.

However, that means it NOT in the current scripts that get used for upgrade.

So I basically had to manually do this commit to fix:

As well as create the lock file: /var/lock/fw_printenv.lock

So, working from 18.02.1, this should be the minimal changes needed to do an upgrade to 18.06.2:

  1. Create lock file:
    touch /var/lock/fw_printenv.lock
  2. Edit the file /lib/upgrade/platform.sh so that these two lines look like this:
    RAMFS_COPY_DATA='/lib/ar71xx.sh /etc/fw_env.config /var/lock/fw_printenv.lock'
    RAMFS_COPY_BIN='nandwrite fw_printenv fw_setenv'
    

Flash your firmware and all should be dandy! No promises though. This fixed my device and my use case.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.