Sysupgrade not upgrading my router

Ah yes - I see the link earlier in the thread now. Apologies for misunderstanding you.

The bug report refers to sysupgrade silent failure with swap enabled. The issue I'm seeing is not related to swap, as far as I know, in that I haven't ever had swap enabled. Not sure that adding to that bug report would assist in that case?

According to slp, sysupgrade 'functions as designed' in that there can be silent failures. Not ideal, for sure, but I don't know what else can be done, unless there's a change request made.

I don't know what is preventing the upgrade on this R8000.

Since reading more on the forums, I realize I've been doing something very much frowned upon - applying the modules from opkg list-upgradable. I'm wondering if this might have any bearing on the failure to sysupgrade. Thinking maybe a firstboot/reboot to clean up and try again?

I'll keep an eye on this post and others that are describing failures to update, for any suggestions or breakthroughs. I'll try upgrading again if/whenever anyone wants me to try assist in debugging what's going on.

That would be a good idea. Take a backup and do the firstboot.

Which is not only a bug, but a serious design flaw. Which is even worse.
Errors from lower level (of SW) have to be propagated up to the user.

In case, you feel not happy to add to my bug report, pls file another one and refere to mine.

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.

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:

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

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.

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

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.

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).

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

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....

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

umount /overlay && firstboot && reboot now

then try upgrade.

1 Like

@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.

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....

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.

Try tftp to update to latest openwrt?

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.

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

+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% ...