The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
--- Begin Message ---
On Thursday, September 25th, 2025 at 13:36, Hauke Mehrtens <ha...@hauke-m.de>
wrote:
> I would like to have the basic attended sysupgrade features in the
> default images for the next major release.
>
> I am not very familiar with the feature and what is needed.
>
> I think LuCI should inform the user when a new major release is
> available.
Hi Hauke,
There's already a "prototype" of this bit that comes when you install
the luci-app-attendedsysupgrade package. Its current form is a bit
messy, as it injects a checkbox obtrusively on the Status page (gui
needs some work):
X Look online for upgrades upon status page load
Controlling
$ cat /etc/config/luci
config core 'main'
option check_for_newer_firmwares '1'
When selected, it runs a check against downloads.o.o and creates a
popup when a newer version is available.
> There should be a button in LuCI which will tell ASU to
> create an image and then install it using sysupgrade.
That would be pretty much the LuCI Attended Sysupgrade app, it only
has a couple bells and whistles beyond that.
> We should also have this feature on the command line, at least that you
> can ask a tool if an upgrade is available and then tell it to upgrade
> including all packages.
owut does all that and a bunch more. For example, 'owut check' not
only checks firmware version, but also the versions of all installed
packages. In addition, it goes out to the package feeds and attempts
to verify that all of the installed packages are built correctly and
currently available (it scrapes the faillogs).
Two variants do the build, 'owut download' simply generates the image,
runs checksums and all that, then dumps it in /tmp/firmware.bin;
'owut upgrade' does that, then fires off 'sysupgrade -f /tmp/firmware.bin'.
> Maybe we should restrict this to large flash devices.
Note: Overlapping dependencies are what I'll call things like
libc or libubox or luci-base, where the package is required by
other stuff, so it's going to be there regardless of whether
you install luci-app-attendedsysupgrade or owut, or not...
The luci-app-attendedsysupgrade package with its non-overlapping
dependencies is about 137k bytes; owut is much heavier at about 220kB.
The base code for luci app is 23k, with rpcd-mod-rpcsys adding
the biggest chunk to the total at 113k.
owut source is 89k of ucode, add on above rpcd-mod-rpcsys from
above, and also ucode-mod-uclient (17k), ucode-mod-uloop (29k)
and that's pretty much it. (Note though, that ucode-mod-uloop
is now a required package for netifd, so it becomes an overlap
in snapshot/25.x.)
Installing both together right now requires about (unsquashed) 242k...
> Do we have to install luci-app-attendedsysupgrade and owut for this or
> is it possible with less?
luci-app= is already pretty minimal. I could make an 'owut-lite',
but not sure if it's worth it since it would probably only remove
about 25k max. We might be able to apply the javascript mangler
to it and save some space, not sure it would handle ucode's
differences from js, but it might be worth a try...
> Should we add luci-app-attendedsysupgrade as a dependency to
> luci/collections/luci/Makefile ?
>
> Should we move utils/attendedsysupgrade-common from the package feed to
> the main repository?
>
> Should we also move utils/owut from the package feed to the main
> repository and add it as a default dependency to DEFAULT_PACKAGES.
All way above my pay grade. :)
One comment on owut, though. I've been working toward breaking
out the 'argparse.uc' utility component of its source code as I
use it in a couple other utilities, and Paul Donald has requested
that it be packaged separately so he can use it in his utilities,
too. There's a PR where I half-assed it, that I need to close
and rework, so I'd need to know where it should go (/openwrt
or /packages/lang/ucode or ???). Some discussion on
https://github.com/openwrt/packages/pull/26988
> Is this all needed or does this feature also work with less new packages?
I know of no other means for doing "one button" upgrades than
the ASU server and its various clients...
Hope this helps,
Eric
--- End Message ---
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
