running custom commands during sysupgrade -

[Sven Roederer]

Am Samstag, 17. Oktober 2020, 01:15:38 CEST schrieb Adrian Schmutzler:
> Hi Sven,
> 
> > -----Original Message-----
> > From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
> > On Behalf Of Sven Roederer
> > Sent: Samstag, 17. Oktober 2020 00:51
> > To: openwrt-devel at lists.openwrt.org
> > Subject: running custom commands during sysupgrade -
> > 
> > Hi,
> > 
> > based on my setup for some 8/32 MB devices I'd like to run a custom script
> > before / during sysupgrade.  The main task of the script should be to free
> > additional RAM, as I suspect some soft-bricks and aborted upgrades to a
> > OOM- situation.
> 
> it's not exactly what you are looking for, but I'm sharing it anyway in case
> it helps you somehow:
> 
> Fortunately, and I don't fully understand why, we were able to drive this to
> effectively zero by simply running
> 
> echo 3 > /proc/sys/vm/drop_caches

Thanks for this hint. I'll add this line to my script.

> 
> directly before sysupgrade. Out of a few hundred upgrades since then, I
> haven't had a single soft-brick. I do occasionally have the situation that
> the device reboots into the old firmware again (i.e. upgrade failed in an
> early stage), but for some reason the soft-bricks were completely gone.
> 
> Regarding your actual question, we have a custom upgrade script for our
> firmware where the command above is simple the line before calling
> "sysupgrade $FILE", so we didn't touch OpenWrt routines at all here.
> 

As we use plain LuCI and OpenWrt commandline, my intention was not to add 
another wrapping-script, but integrate transparently into OpenWrt. But when 
your firmware (Gloun) is havnig a script anyways, that's the most easy way.

Sven

> 
> > To me the /lib/upgrade folder seems a good place to add such scripts, as
> > the *.sh files there will be sourced already, So additional patching is
> > not required.
> > 
> > My problem is: adding a script
> > --------------------------
> > root at gib-mir-einen-namen:~# cat /lib/upgrade/freifunk-berlin_freeup-
> > ram.sh
> > ffberlin_freeup_ram() {
> > 
> >   # remove LuCI-caches
> >   rm >/dev/null -f /tmp/luci-indexcache*
> >   rm >/dev/null -rf /tmp/luci-modulecache } ffberlin_freeup_ram
> > 
> > ---------------------------------
> > works as expected. The files are delete the the firmware gets flashed. But
> > just adding  a "ifdown" or "/etc/init.d/<service> stop" make the upgarde
> > fail -------------------------------
> > root at gib-mir-einen-namen:~# cat /lib/upgrade/freifunk-berlin_freeup-
> > ram.sh
> > ffberlin_freeup_ram() {
> > 
> >   # stop uhttpd and luci
> >   /etc/init.d/uhttpd stop
> >   # remove LuCI-caches
> >   rm >/dev/null -f /tmp/luci-indexcache*
> >   rm >/dev/null -rf /tmp/luci-modulecache } ffberlin_freeup_ram
> > 
> > -----------------------------------
> > 
> > The Upgrade starts as expected and runs up to
> > 
> > Saving config files...
> > Commencing upgrade. Closing all shell sessions.
> > 
> > and then times out. on the serial console I can see that the board just
> > reboots after some time.  Normally it will do:
> > 
> > Watchdog handover: fd=3
> > - watchdog -
> > killall: telnetd: no process killed
> > killall: ash: no process killed
> > Sending TERM to remaining processes ... netifd odhcpd uhttpd udhcpc
> > odhcp6c ntpd dnsmasq pingcheck crond ubusd askfirst urngd logd rpcd
> > hostapd Sending KILL to remaining processes ... netifd uhttpd dnsmasq
> > pingcheck sh sh rpcd netifd uhttpd dnsmasq sh rpcd rpcd Switching to
> > ramdisk...
> > Performing system upgrade...
> > Unlocking firmware ...
> > 
> > Writing from <stdin> to firmware ...
> > Appending jffs2 data from /tmp/sysupgrade.tgz to firmware..
> > 
> > Upgrade completed
> > Rebooting system...
> > umount: can't unmount /dev: Resource busy
> > umount: can't unmount /tmp: Resource busy [  343.465535] reboot:
> > Restarting system
> > 
> > 
> > Any idea what is causing this behavior?
> > Is my idea a totally wrong approach?
> > 
> > 
> > Thanks Sven.
> > 
> > 
> > 
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel