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