I'm a brand new user of OpenWRT. I got a used Linksys WRT3200ACM with the purpose of experimenting with it as a possible alternative to my current setup which is made of Asuswrt-Merlin on an Asus RT-AC5300 (so similar equipment in terms of processing power and available RAM). That's because I want to pursue a more complex setup of my home LAN (which includes also a business-class firewall and an AP and a couple of managed switches) using VLANs, and that's something scarcely discussed/supported on that platform/forum (or I've been unable to find out easily by myself, might be too). I find OpenWRT robustly build and with great support for themes like managing the firewall and networking details (including related GUI tools which are always appreciated when time is scarce). And I love the hardware, seems rock solid, well ventilated, good visibility of activity LEDs (RT-AC5300 doesn't have them at all for LAN ports), etc.
Over the years I've installed quite a few Entware opkg packages (including big ones like Suricata which runs pretty fine on it, though eating almost all of the RAM). I'm used to opkg update && opkg upgrade from time to time, without fears. It's not a discouraged practice on that platform. So much that actually there's not even need to re-install packages upon a fw upgrade: nothing is lost at that, no installed packages nor, of course, their configuration. I've been working like this for several years now, upgrading hw (RT-AC68U, RT-AC88U, RT-AC5300), with not a single issue ever.
So once I got my OpenWRT 19.07.7 installed, first thing first I started playing with opkg and ... I now realise here in the forum that the practice of opkg upgrading packages has been instead quite discouraged (along with the need to re-install custom pkgs after fw upgrade). Is that still the case as of 19.07.7 ?
Also, just for the sake of knowledge and open discussion, I'd like to get a deeper understanding of the reasons why for two platforms that share quite a bit of "spirit" (though one has a closed-source core while the other is totally open-source), with due respectable differences, such a practice seems to have so diverse consequences/implications.
Upgrading packages (via the CLI opkg upgrade command or the LuCI Upgrade... button) can result in major problems. It is generally highly discouraged, unless you know what you are doing or if there is specific instruction to do so.
Thanks @trendy for the feedback. And thanks for sharing the OpenWrt Security Advisories link, I get now to know it, well done and useful.
As for the opkg packages, what is the practice then for those who make a good amount of use of them ? Is there any easing tool that allow to restore pkgs (I saw a script for that) and not less important their configuration upon a fw upgrade ?
As a smart working developer, in peak periods I can afford a fw upgrade if it takes (as it's been the case so far) less than 10 minutes, but lengthy manual operations would probably bring me to delay and delay the operation ... On the other hand, I love the idea of keeping my network protected and updated.
The best way to be safe and up to date is to upgrade the whole OS, whenever there is a new release. Otherwise keep subscribed in the mailing list for security advisories to receive the critical updates that should be upgraded in opkg.
I personally use the opkg script to restore the installed packages after an upgrade. Configurations should be carried over, but a backup doesn't hurt. There are solutions like builder to make your own image with the packages you use preinstalled.
Uhm ... a 30-sec look at the script seems that the config is not saved/restored (e.g. think of syslog-ng custom config for various filters/output, which I use in conjunction with network logging). Am I wrong ?
As for builder, that might be an idea if it's an easy (or easy to automate) task. Any hint to start with ?
The script will not save the configurations. It will create a list of the installed packages and will try to reinstall them after it is invoked post upgrade.
It is your responsibility to transfer any configurations not stored in the default /etc/config , see backup and restore.
Normal sysupgrade saves config files over sysupgrade. No need to handle them separately.
But like trendy implicates, that only concerns the files marked as config files. By default all in /etc/config, some /etc and most packages declare their config files properly. But if you have nonstandard files in nonstandard places, you may need to add them to the backup list.
I assume you refer to the case when you thick to save the config during the sysupgrade (sysupgrade keep settings), is that correct ? Which, I see, is often discouraged too (though 50-50, and not discouraged only for minor upgrades).
Meanwhile I read that "opkg save" might do part of the job ?
Thanks @hnyman to you too.
As above, sysupgrade saves if you thick to save the config, right ? (See above considerations).
I guess that after experimenting with the "opkg save" it might the case for a few iterations of flashing to see if the packages I'm interested into are correctly configured to set their config paths and they're automatically preserved.
It is discouraged between major upgrades from 17->18->19
Between minor 19.07.6 -> 19.07.7 there is no issue.
It might still work for major upgrades, but best restore them manually.
I have not tried opkg save.
Just concentrating on this this aspect of the question.
There is a quite major difference between your opkg usage there - and OpenWrt.
Let's start with the easiest aspect, entware. These are strictly addon packages, staying away from the actual firmware underneath - if something breaks, it's limited to the the entware packages - and there's generally very little development happening on the OEM firmware.
The situation is roughly similar with Asuswrt-Merlin, it's closely based on the OEM firmware - using large parts of it unchanged (kernel, libraries, etc.), changes and development mostly happen on the periphery, user-visible, adding functionality, but little changes to the actual core (OEM-) components (kernel, libc, etc.) of the firmware underneath.
OpenWrt does not used vendor kernels or libraries, everything is built from source and regularly synced with newer upstream versions. With these upgrades you get ABI- and API changes in system libraries down to its very core (libc/ musl), syntax changes in configuration files and fluctuations in general, just as well as a steady stream of updates as a whole.
There are two consequences coming out of this…
the most obvious one, regular updates need space. ~4.5 MB of your firmware is fixed and read-only (kernel && squashfs), only the rest (often the vendor flash partitioning reduces this even further) is available to the overlay and with that to upgraded packages. With most devices not having much flash to begin with (8-16 MB are still very common), you quickly hit a dead end just with the number- and size of upgrades (even if those would be totally fine themselves).
As mentioned above, kernel && rootfs are read-only (and highly compressed, to save space), so over the lifetime of your currently installed base firmware, these can't be changed. The kernel generally is outside the rootfs, non-upgradable via opkg, because
the OEM bootloader isn't smart enough and just loads whatever is at its default flash location and
very often the size split between kernel && rootfs is dynamic, so the rootfs starts directly behind the kernel at the next erase block - it grows and shrinks between versions as needed.
As a result even if you would find a way to upgrade the kernel, it couldn't ever grow - but the kernel tends to grow over time…
Now besides the monolithic kernel parts (vmlinuz), its modular parts the kernel modules are stored inside the rootfs (/lib/modules/$(uname -r)/) - both having a very tight ABI dependency between them, version and even its configuration must match exactly and can't diverge at all, while at the same time the upstream stable kernel (down to the LTS releases) on average are updated roughly twice a week, with OpenWrt usually following within a day or two (in master, the maintenance releases follow a bit behind - but are also regularly updated for the next maintenance release), so you'll end up in trouble with the kernel packages alone within very short time.
While less pronounced, a similar issue happens with the basic userspace libraries (libc, OpenSSL, et al) as well, you have the read-only parts of the rootfs (squashfs) and the writable parts overlaying this read-only parts - yes, you can update/ replace the files via the overlay, but there is a time in the (earlier-) boot process before the overlay is mounted, so both would need to remain compatible (which isn't a given in master/ snapshots). While the major ABI of the core system libraries is generally fixed between maintenance releases of a stable release branch, the further you get to the 'edges', the more likely you get ABI bumps due to bug- and security fixes (and things like w.g. OpenSSL might be a prime candidate for having to update).
Q: How is this dilemma solved on desktop linux distributions? A: By co-installing different library ABIs (soname) in parallel, at least temporarily until all depending packages have been rebuilt (and additionally by symbol versioning, which would massively increase workload on the developers, but wouldn't be an issue for this topic). Here you clash with the basic dogma again, >95% of all devices running OpenWrt don't have sufficient flash to support that (there is a reason why e.g. Debian has minimum disk space requirements of 10 GB, even a very, very stripped down (more OpenWrt like) system would need a minimum of at least 1-2 GB to allow viable in-place upgrades (keep in mind, during the upgrade itself you need at least 3 times the space - longer term you need to account for multiple co-installed library versions) - and most bootloaders wouldn't be able to cope with multiple co-installed kernel versions (vmlinuz not being part of a file system, but having to start at a fixed flash offset).
Aside from this, opkg is not feature complete compared to e.g. dpkg&&apt or rpm&&(yum||dnf), it doesn't have many of the essential features and locking mechanisms that would be needed for in-place upgrades of the full system - but it's small and just good enough for what it has to do…
And yes, given that neither package manager nor the target devices would allow in-place upgrades anyways, shortcuts are taken in the packaging as well. It is easier to maintain (upgrade-) packages, if you don't have to account for co-installed sonames of the same libraries (supporting multiple versions at once) and can depend on there always only being a single one, monolithically matching to the complete userland. This reduces workload on the developers/ maintainers significantly, if you had to do this 'properly' instead, you'd easily need >>2-3 times the number of developers to cope with the current package set (but at that point, opkg would be sent off to history anyways, in favour of something else, such as dpkg&&apt, rpm&&(yum||dnf), pacman, portage, apk, …).
As you see, there are quite fundamental differences between (binary compatible-) 'hacking' on an OEM firmware (without source for vast parts of the basic OEM firmware) and original development with frequent upstream syncs. And we'd need quite different hardware to really support in-place upgrades (flash/ RAM, bootloader flexibility <-- and with that some form of more generic hardware abstraction (UEFI, ACPI, SMM, grub2, …)).
Disclaimer: this is a simplified overview, ignoring the finer details not necessary here.
Oh well ... this is plenty of information (call them simplified if you wish )
So, it's roughly as comparing a quite controlled dev environment like Apple iOS and the wilderness of Android which copes with the huge diversity of the install base between old/new and basic/advanced devices. And ... OpenWRT has no Google backing it ...
Adding the very distinguished ramification of the opkg limits within OpenWRT w.r.t (...) AsusWRT where Entware is just ... an optional addition touching only the periphery of the system.
I didn't know though that opkg was so much different (in terms of robustness and results consistency) compared to the various linux packages management tools. It's understandable, indeed but ... didn't think seriously about it before.
Config is in 99% of the cases changes of config files so you don’t need to reinstall OpenWRT to start over.
If the software works (if it boots at all) and you can connect you can simply reset it to defaults from system settings.
Or push the physical reset button (if you have one) and wait for it to reset the settings. Then you have a “new install”, this also resets any extra installed packages.
I have had not so much fortune with “keep settings” when making system update. So I don’t use it any more.
I made the effort to write my own config scripts I simply run after a update. Then all the config files are cleanly rewritten to fit my network without any old garbage laying around.
The problem with a manual reconfig becomes a real issue when you start to have 3-4 VLAN:s and interfaces and Firewall settings. Then a manual reconfig takes hours instead of about 5min with a config script including the reboot time.
No one has told the router that it shoulden’t do that, but it does that anyway...
I have done that a lot of times this year on the Linksys WRT3200ACM when I did my config script and it gave me a fresh new 19.07.7 install every time.
On devices with a physical reset button, OpenWrt can be reset to default settings without serial or SSH access.
Power on the device and wait for the status led to stop flashing (or go into failsafe mode, as described above).
Press and hold the reset button for 10 seconds.
Release the reset button.
The device will do a hard factory reset (see below) and then reboot. This operation can be slow on some devices, so wait a few minutes before connecting again.
Not all devices have a reset button though. so for those other devices it's worthwhile to know the other possible procedures.
I have a TTL serial also, and now with my new ER4 a console cable because that is more industrial standard so it needs a Cisco cable.
But I agree, to be allowed to use OpenWRT everyone should proof they know at least two ways to reset the device...
But as long as I am able to connect to LuCI when experimenting it is simpler to use the system menu and hard reset.
)