OpenWrt Snapshots are already built without a graphical interface - not by accident, but for technical reasons (build time, resources). This raises a few questions I'd like to open up for discussion.
1. Background - a concrete example:
Devices like the MikroTik RB750r2 have 16MB flash and 64MB RAM. Starting with OpenWrt 25.x, the sysupgrade image (7.2MB) no longer fits in free RAM while the initramfs is running - 24.10.5 (6.8MB) still works. The device is not dead - in my assessment it has simply been held back by image growth. Comparable cases likely already exist. RAM is not the only possible bottleneck - but one of the less obvious ones, since flash-related issues are already documented.
2. Headless stable variant:
Would it make sense to offer an official headless variant for stable releases - analogous to snapshots? No new infrastructure needed, the build process already exists. Fewer installed components mean less attack surface - and RAM-limited devices remain usable with current security patches.
3. ToH data and headless as a solution:
The ToH already contains all relevant hardware data - RAM, flash, supported versions. Does this data feed into the build process or the Firmware Selector anywhere? If not - would that be conceivable, for example to automatically flag devices that are reaching a limit and offer them a headless variant? A first analysis of the DTS files in the OpenWrt repository shows at least 15 devices with 64MB RAM - with devices like the RB750r2 not appearing at all, since their RAM value is not defined in the DTS. With images continuing to grow, the number of affected devices is likely to increase over time. A headless image would not be a step backwards but an option — for users who are willing to put in the effort. A note that explains what this means for the user in practice would in my view be helpful. It would also be conceivable that at a point release a corresponding notice appears - something like: "This device will only be offered as a headless variant from this version onwards." Transparent, clear, no surprises for the user.
The result would be an extended useful life for existing hardware with the current OpenWrt version.
These are my personal thoughts and assessments - I look forward to your perspectives and discussion.
Really ? I fiddled around with memory constrained openwrt devices (32MB RAM) for long time already. A few times sysupgrade to a newer version simply failed because of max size limit for /tmp. Re-mount with more allowed space fixed the problem for me.
There are official ath79/tiny builds for ath79 devices with small flash and ram. You can probably make your own build using a similar build recipe to get some more life out of your device.
to flash:
use initramfs from snapshot build. Or even build barebone yourself.
to run:
zram and no luci and you should be fine. Also you can disable/remove ipv6 related odhcpd if not required.
I you mean webui-less, then if you’re capable of configuring and running such a device, it’s not a big stretch for you to build a custom image (without luci and with your own settings to start). AFAIK, it is, however, an expensive task to build and store images without luci for all OpenWrt devices. It might also introduce issues when someone, not equipped with SSH skills, accidentally flashes the webui-less release image onto their device.
@reinerotto, @konus, @nicefile - I will try out the suggested workarounds, thanks for those. I had already been thinking in that direction myself and identified kmod-ath9k, kmod-ath9k-common and wpad-basic-mbedtls as unnecessary packages that could be removed to save space. Interestingly, exactly that was recently implemented officially in PR #22134 and merged into main.
@stangri - the Firmware Selector can be customized manually, but a beginner does not know which packages can safely be removed to still get a working result. A ready-made headless image would come preconfigured - it works, just reduced. Someone who knows this upfront can back up their configuration beforehand and update via SSH afterwards. From my perspective the deal is simple: less comfort, but current and secure. The alternative is staying on an outdated version long term or working around the problem from release to release - but I understand that others may see this differently. Regarding the cost concern - the proposal is not about building headless images for all devices. The infrastructure already exists since snapshots are built headless today. It would only apply to a specific subset of devices that are reaching or approaching their limits. Which brings me to point 3 - ideally this could even be handled automatically and reliably based on existing data.
@cookiemonster - thanks for the links and the reference to the support tiers discussion. Whether that idea ever materialized I honestly cannot say - someone with deeper insight would need to answer that. What I can say is that the underlying idea and my proposal point in the same direction - keeping devices running as long as possible without excessive effort. The quoted approach "bootable images small enough to still allow configuration persistence" describes essentially what a headless stable image would deliver.
One question that has not been addressed yet and interests me most: Could ToH data or the DTS files in the OpenWrt repository serve as a reliable technical basis to automatically identify such devices and flag them accordingly in the Firmware Selector? What do you think?
I was not aware that it's wifi less device. I've created backport to 25.12 to be included with next release . Pull Request #22475
Until then you might build your sysupgrade using firmware selector with removed kmod-ath9k and wpad-basic-mbedtls from the list
Use the image builder and or compile your own firmware with reduced footprint. As we all do since nearly 20 years by now....for instance, I never had Luci installed on any of my devices
