Sysupgrade not upgrading my router

Installing and Using OpenWrt
24

While generally not good practice, it is hard for me to think of a case where installing packages to flash would "break" sysupgrade (except, perhaps, if flash was was completely filled or the critical binaries were corrupted).

The details of how the sysupgrade process works can be seen in ./package/base-files/files/sbin/sysupgrade and the files in ./package/base-files/files/lib/upgrade/ The process of "pivoting" off the flash file system and into a memory-backed one is in ./package/base-files/files/lib/upgrade/stage2

From that file, a current (February, 2018, master) list of files and binaries that can get you into trouble include (Edit: As noted by hnyman in his follow-on in this thread, there may be additional files and binaries beyond this generic list.)

        for binary in \
                /bin/busybox /bin/ash /bin/sh /bin/mount /bin/umount    \
                pivot_root mount_root reboot sync kill sleep            \
                md5sum hexdump cat zcat bzcat dd tar                    \
                ls basename find cp mv rm mkdir rmdir mknod touch chmod \
                '[' printf wc grep awk sed cut                          \
                mtd partx losetup mkfs.ext4                             \
                ubiupdatevol ubiattach ubiblock ubiformat               \
                ubidetach ubirsvol ubirmvol ubimkvol                    \
                snapshot snapshot_tool                                  \
                $RAMFS_COPY_BIN
        do
                local file="$(which "$binary" 2>/dev/null)"
                [ -n "$file" ] && install_bin "$file"
        done
        install_file /etc/resolv.conf /lib/*.sh /lib/functions/*.sh /lib/upgrade/*.sh $RAMFS_COPY_DATA

If you configure your system to replace these with other versions (such as removing or not implementing the busybox applet and its symlink), you may have problems with upgrade. Augmenting the default binaries with packages should not be an issue.

As a warning, trying to upgrade busybox over a ROM version can lead you into a world of hurt with sysupgrade and likely in other places, especially as installing a package often requires tools provided by busybox.

25

Thanks Jeff.

I haven't replaced any of those with other versions.. well, not intentionally!

Whilst biding my time yesterday, I was looking at that exact piece of code you show. This afternoon I installed 18.06.2 onto Raspberry Pi 3B, and ran a simple script using that code, which just echoes the $binary and associated (if any) $file. Though there were quite a few missing binaries, they did look to be not relevant to an RPI install (probably I should have taken the code directly from the RPI version for that test).

However, running same script on the R8000, there were a few important-looking missing files. Quite why they were missing I don't know - probably I'd been overzealous in cleaning up in the past. I've always used 'opkg whatdepends' but possibly messed up somehow. I've just installed the missing packages, and will try an upgrade again later today.

Files that were missing and since installed:

partx
mkfs.ext4 
snapshot 
snapshot_tool

They do look kind-of important! :slight_smile:

26

PLUS the respective code snippets in each target, which may even be device-specific...

sysupgrade varies a lot between targets and devices, depending also on the storage media.

E.g.

1 Like
27

what about the firstboot route? It should reset you back to the default packages because the overlay is completely wiped and the initial packages installed "return" from the dead. After that if a sysupgrade doesn't work something is seriously wrong.

28

Yes, I'll try the firstboot next. Having installed the missing packages, I tried the upgrade again via Luci. Device came back up as 18.06.1

1 Like
29

Of course as others have said, make sure you take a backup of your config before doing the firstboot. Hope that works for you, and if not... I can't see how you'll recover very easily, might be a good time to start looking for new hardware. Failure of sysupgrade after a firstboot probably indicates a hardware problem, I'd think, because the software will be entirely stock at that point.

30

Thanks. If this still fails, I thought to try installing the R8000 OEM software. And work forwards from there. I recall going that route when moving from classic OpenWrt to the the first LEDE release. Though I can't recall now how I did that. Should it be ok to load the R8000-V1.0.3.4_1.1.2.chk via Luci?

I've been re-reading about the header differences between chk and bin, and I see the OpenWrt chk header is similar format to the stock firmware. From my brief browsing of the sysupgrade code, it looks like both are acceptable - the upgrade code takes care of header?

(Apologies if I'm asking too many questions here. I have been reading documentation, but it's not so clear what the exact correct method is, as there's lots of information accumulated over the years).

31

Back online, running 18.06.2
Thanks to all for advice and instruction.

Recap:
I ran firstboot and reboot -f
Upgraded to 18.06.2 via the Luci interface
After the reboot, Restore Backup via Luci interface

1 Like
32

Hello,
Have tried to do exactly same steps on my ENS202EXT device but does not work!
The command "/sbin/firstboot" just performs a soft reset, and after rebooting and updating using LuCI, the versions keeps the same as before, 18.06.1....

33

see https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset

umount /overlay && firstboot && reboot now

then try upgrade.

1 Like
34

@YaM_PT5 - any chance you used opkg upgrade in the past? If so, that would be similar to the experience of the OP, but there could be other issues that are preventing firstboot from working properly.

35

Tried that and lastely "jffs2reset" but always with same result... device performs a reset and reboot after that.
Attempted to update again through LuCI, but still refuses to update. Also with "sysupgrade -F" got exactly same result. It is definitely stuck on 18.06.1....

36

Actually installed OpenWRT 18.06.1 directly from the stock EnGenius firmware. And still did not update any opkg packages.
As I mentioned above, tried an hard reset but it did not help me in anyway.

Was thinking myself if should TFTP to go back to stock again, and from there, update it again to the latest OpenWRT version.

37

Try tftp to update to latest openwrt?

38

Yeah that's what I mentioned above. But still undecided if I should flash it to stock again first, or if I am ok to upgrade without doing that.
Either way, should I use "factory" or "sysupgrade" file in this case ? Both are .bin files, and not .img as the stock file is. Just wondering, to avoid it gets bricked.

39

I don't know enough about your device to say whether you should use factory or sysupgrade when tftp updating on your device. The intent of factory is that it is acceptable to the factory software, and since the tftp procedure is designed to work with OEM firmware images my guess would be that using the factory image is the right way to go. That's also born out by some incidental examples on the tftp page... but nowhere does it explicitly say "when using the tftp client built in to factory uboot you should use factory images" If someone here with more in depth knowledge can confirm the appropriate info I will update the wiki

40

+1
That holds true for >95% of cases.
(I do not know any exceptions, but surely there is some...)

Sysupgrade is ONLY meant for upgrading an existing OpenWrt.
That again holds true for >95% ...

41

@doublez13 @geofb @YaM_PT5

Hey all,

I Also have an ENS202EXT that was on 18.06.1. and I ran into the same problem trying to upgrade to 18.06.4. Found this thread, but without the answer. I found the answer on another thread shortly afterward and wanted to share.

Basically, this is a bug that only exists in 18.06.1 for the ar71xx branch it seems...

as the person who figured it out describes, you have to do the following before upgrading:

  • (first, I recommend factory reset / firstboot and reboot beforehand)

  • create the lock file for uboot env: touch /var/lock/fw_printenv.lock

  • Make the changes for platform.sh (approx. line 10) as seen in this commit:
    nano /lib/upgrade/platform.sh
    RAMFS_COPY_DATA='/lib/ar71xx.sh /etc/fw_env.config /var/lock/fw_printenv.lock'
    RAMFS_COPY_BIN='nandwrite fw_printenv fw_setenv'

  • Load the new image however you like (to /tmp) and upgrade (not keeping config)
    sysupgrade -v -n /tmp/*.bin

42

Hi there mpratt14,

Actually I forgot to update this thread as I found out an easy way (in my opinion) to upgrade those EnGenius units, which require we to force them to enter into "Failsafe mode", can be get through an easy way.

After many failed attempts and frustation of nothing works to upgrade or downgrade from 18.06.1 to any other version, I found this following command as working great for those who are stuck at this version. From what I understand, it forces unit to write directly at MTD linux partition, through this way:

mtd -r write /tmp/original_firmware.bin linux

On my case, after doing this, the unit reboot and entered into failsafe mode as pictured below:

EnGenius%20-%20Failsafe%20mode
EnGenius - Failsafe mode.jpg1367×383 47.2 KB

After that, we simply need to upload the desired version into unit and it will flash normally as if using the "sysupgrade" method.

Hope that helps :slight_smile:

1 Like
43

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