Latest arm_cortex-a7_neon-vfpv4 packages seem broken

I am using an AVM FRITZ!Box 4040 on OpenWrt 19.07.2 and my device today bricked after doing the usual opkg upgrade of the new packages using SSH.

The upgrade list had a lot of new packages to upgrade that were new to my eyes (usually i am getting some luci package updates every 2-3 days), and after the upgrade commands i was getting a lot of "Command failed" messages.

After the reboot, the device bricked. I had to flash the image from the begin. Device now works as vanilla 19.07.2 but if i try to put a package in i am getting problems.

For example when i tried to install dnsmasq-full to start setting DNS over TLS on my device, DNS server became completely broken and i had to perform a device reset.

Is anyone experiencing the same or have any idea why this is happening? I believe there is something going on with the arm_cortex-a7_neon-vfpv4 packages as of this morning 11 of May.

Thank you

1 Like

@obamia, welcome to the community!

:warning:

There are many threads advising not to perform general opkg upgrade of packages. It's advised to flash a new snapshot to update software. You're actually quite lucky you never ran into issues until now.

That's a common issue with non-responsive devices after a bad run of the command.

If you want bleeding edge updates, consider flashing Development Snapshots (a link about what Snapshots are can be found below).

For more information, see:

Hope this helps.

1 Like

Thank you for the reply, i guess i was very lucky (the last 2 years i was doing opkg upgrade with no problems).

Though i don't really mind to have the latest packages, so the snapshot builds are out of question, i do mind to be able to put some packages like stubby for DNS over TLS, that seem broken now cause dnsmasq-full package has issues at the moment.

Seems the actual root cause was a botched fstools upgrade.

1 Like

I have the same problem. After an upgrade to Version OpenWrt 19.07.2 r10947-65030d81f3, i found 42 upgradeable Packages. The Upgrades ends with many errors e.g. "Command failed: Not found", Collected errors: "* satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-mod-status: * libiwinfo20200105", * satisfy_dependencies_for: Cannot satisfy the following dependencies for rpcd-mod-iwinfo:

  • libiwinfo20200105", "xargs: opkg: exited with status 255; aborting". The package libiwinfo20200105 don't exist in this version.

@brummbeere - Please see the above post by @lleachii.

To resolve your problem, you will likely need to reset your router to the default configuration, at which point things should work normally. Please do not upgrade any packages unless you know exactly what you are doing (why you are upgrading each package), and it should go without saying that the upgrade process carries some risk of ending up in a situation where you may experience problems again if the packages turn out not to have been safe to upgrade.

Hello psherman,
thank you for the answer, which unfortunately does not solve my problem. So far I was able to install updates without problems and adapt my system to my needs. This and Open Source are the reason why I use OpenWRT. Since yesterday this is no longer possible. Updates are offered for almost all installed packages, some of which end in non-resolvable dependencies (e.g. libiwinfo20200105). After resetting to default values it works for the basics.

Thank you and best regards
Brummbeere

@brummbeere - I think it might be good to clarify a few points

If you look through some of the links provided and search through the forums, you will see that OpenWrt's opkg package manager does not have the mechanisms in place to ensure that the upgrade will succeed. There are people working on improving the robustness of the upgrade system, but it was never designed for blindly updating all packages, and it also cannot update certain core packages without causing the system to fail. This has always been the case, but you are lucky that you have not experienced problems until this point.

Maybe you could explain exactly what you actually need to update using this method and why? In many cases, people believe that they should update just because an updated package is available. This is usually not necessary unless there is a specific feature addition, bug fix, or security patch that is critical for the continued operation of the system -- and like I said, this is rarely actually necessary. Beyond that, blindly updating all packages is the main issue here. If you have a few specific packages that you wish to upgrade, it may be okay to do so.

Yes, OpenWrt is open source. Nothing has changed in this regard.

Actually, the risk of upgraded packages causing major system issues has been around for a very long time -- this is just the first time you have encountered such issues. Again, just because there are updates does not mean that it is necessary or wise to install them, unless you know exactly what the update does and why you need it.

Yes. Because the reset to defaults removes the updated packages and all of the core packages are self-consistent. You can still install new packages to add functionality, but upgrading is usually not recommended.

The recommendation for upgrades has always been to wait for a maintenance release (for example 19.07.1 > 19.07.2) and flash a complete image. If there is a critical patch that must be applied before a new stable release can be built, you will see it here. If you must have the latest updates and be on the bleeding edge at all times, you should consider using snapshots (linked above by @lleachii), and to update your snapshot build regularly by flashing the newest snapshot (not upgrading packages) -- but understand that snapshots are not always stable and also make installing packages more difficult over time (snapshots are, by definition, a moving target). Or you can continue to upgrade specific/selected packages on a given build, but you need to understand that there is a risk involved, especially if you upgrade all packages.

1 Like

Nice idea but the reality is if I need to install dnsmasq-full onto a vanilla build, the problem occurs.

1 Like

If you're using a stable release build (without having performed any package upgrades) followed by using opkg update and opkg install and you experience this problem, that suggests that your problem may be different. I'd recommend opening a separate thread (if you haven't already done so) to try to address this problem.

EDIT: added opkg update to be consistent with @lleachii's comment below -- the package lists must be updated before the opkg system can install anything.

1 Like

Just to be clear:

  • release build reset to default
  • opkg update
  • then opkg install

I do this all the time to "upgrade"packages (since I flash snapshots - and use all packages bundled at the time, which is sightly different from the update methods y'all seek on stable builds.)

1 Like

I have the same problem with GL-B1300, bricked after upgrade. uboot recovered with
http://downloads.openwrt.org/releases/19.07.2/targets/ipq40xx/generic/openwrt-19.07.2-ipq40xx-generic-glinet_gl-b1300-squashfs-sysupgrade.bin
But now ALL packages in opkg repository are from new build 11 May.
https://downloads.openwrt.org/releases/19.07.2/packages/arm_cortex-a7_neon-vfpv4/
How i can install additonal luci modules, wireguard, upnp without risk of bricking device again?

I even tried to find package causing a problem.... Install one package and reboot....

Regards
Weasel

Correct. If they weren't you'd have mismatched kmods, packages, kernels, etc...likely causing the identical issue of a soft-bricked router.

:confused:

I literally just upgraded my router an hour ago and installed Wireguard...

  • Sysupgrade new snapshot
  • opkg update
  • opkg install mod-udptunnel4 kmod-udptunnel6 kmod-wireguard wireguard-tools wireguard luci-proto-wireguard luci-app-wireguard

What's the big problem?

1 Like

@ElectricWeasel -
From a fresh install (or reset to defaults)

opkg update
then
opkg install <package 1> <package 2> etc

just don't use opkg upgrade and you should be fine

1 Like

I did exacly as you typed, rebooted, no wireguard status on overview - was available before. Also I need DDNS so typed
opkg install ddns-scripts ddns-scripts_nsupdate luci-app-ddns
Now Overview stopped to work at all.


no single opkg upgrade command

Regards
Weasel

Can you show the output?

What does this mean???

If I understand this, it means you didn't type what I said.

Explain this. How do you make it appear on a fresh install?

:bulb:
Whoa...and I just realized your original problem causing a brick.

Router configuration was restored from backup.
opkg install kmod-udptunnel4 kmod-udptunnel6 kmod-wireguard wireguard-tools wireguard
then
opkg install luci-proto-wireguard luci-app-wireguard
reboot, no wireguard status on Overwiew
anyway to make this sense i need DDNS
opkg install ddns-scripts ddns-scripts_nsupdate luci-app-ddns
reboot, Overview broken as on picture above

I'm not suprized because now part of luci is in different version - is updated frequentely as i observed.
By "was" i mean in the morning with couple of other services like miniupnpd, WakeOnLan, collectd, fwknopd

Regards
Weasel

I just tested the install of the 3 items you mentioned, everything is working just fine on my installation.

Maybe Wireguard is not there because you didn't reinstall it.

To be clear, rebooting is not the same as resetting to defaults. Please try that first. (System > Backup / Flash Firmware > Reset to Defaults). Then configure the very basics, and try installing the packages you just said caused problems.

1 Like

If you have any misconfigured items in the backup, that could potentially cause issues.

Did you first run opkg update?

What do you mean by this?

Yup, basically you have no DNS resolution.
If you go to an SSH session, you can ping 8.8.8.8, but not google.com.