Is there an effort or a best practices, or better, a howto with script, like a quick and dirty POC, for upgrading the most silently possible a openwrt release ?
I have seen some effort on forked openwrt like turris but never find usefull information...
I want to help to get it working, if possible to !
Thanks...
EDIT :
Theses scripts are given "AS iS"; so take care because of they can broke your system...if missused !
Use them at your own risks...
I have find an attempt with official release, that I have not yet tested...
Some time ago I created the following PR which uses the profiles.json file created by the OpenWrt buildbots to find an adequate image. I'll refresh the PR, problem is that there is still no versions.json file which allows a machine to figure out if it's up to date or not.
Another attempt to check ;
I've collected/coded some useful Opkg and UCI functions which may help to automate system/package upgrade:
How can we handle the overlay/partition map ?
Any clue will be welcome about this...
My own installation practices is to flash a mvebu and add a third partition to clone and mount as '/' !
It gets me ext4fs bad mounting after crash been handled correctly...
It gets me also the filesystem size been up to the full mmc or SD card size...
If you want to upgrade regularly, the best practice in the long run is to cook up your personal image with all packages included, either with imagebuilder or with the full toolchain.
If you are skillful enough to write the automation scripts, you can easily build your own firmwares.
With the large universe of supported devices, changes in device specific packages & config, there is no sure way to hand all possible upgrade scenarios automatically and gracefully.
I didn't test it, but it may be possible to run a custom post-upgrade script if you save it in /etc/rc.local or /etc/uci-defaults, mark it for backup and then perform upgrade keeping the settings.
yup... for testing make sure the uci-default script exits 1... otherwise if you reboot it will get removed... ( you can have it internally check for flag-file presence to prevent re-runs )
Step #1, done;
the target of the first step is to autoclone the /rootfs (extroot) when sysugrade or flashing or resetting...
I'll have integrate the management of my rootfs layer here :
this script is for /lib/preinit/... it will check for a flag and (re)create a clone of rootfs and enable it for fstab...
Step #2, study GL.INET and/or TURRIS auto-updater...
The target of this second step is to keep or reinstall the users packages...!
The main problem may be the overlay of the rootfs...
using opkg.sh (thanks @vgaetera), I have now a fully auto upgrader service which restore all users installed packages at the first reboot, just next the sysupgrade...
all stuff can be test here ;
you need to add owrt.sh to the profile.d and execute a opkg_backup BEFORE upgrading...
Then, if you add files to imagebuilder, and build with something like ;
make image PROFILE=globalscale_espressobin-v7-emmc FILES=files/ PACKAGES="block-mount kmod-fs-ext4 fdisk mount-utils partx-utils"
flashing the resulting system will sysupgrade your system as usual, and at first reboot, add the extroot and refresh your user installed packages at the end of the boot...
tested with success with 19.07.4 !
Hopes all this will help...
Feedbacks welcome
just for my benefit ( and anyone who reads this thread )...
would you mind ( next time you test / do a normal install ) sharing the default partition layout?
( and maybe a brief description of the disk hardware on your device... )
i'm just not 100% clear on what is going on here... create overlay and setup during preinit I understand...
( need to know what it looks like beforehand as i'm thinking anyone who tries to copy that script not on a two part default block system is going to run into trouble?)
before : the default of mvebu espressobin mmc :
root@C3BOX:~# mount
/dev/mmcblk0p2 on / type ext4 (rw,relatime,data=ordered)
root@C3BOX:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 252.0M 9.3M 237.5M 4% /
after my script has clone the partition root to a third additional extroot :
root@C3BOX:~# mount
/dev/mmcblk0p2 on /rom type ext4 (ro,noatime)
/dev/mmcblk0p3 on / type ext4 (rw,relatime,data=ordered)
root@C3BOX:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 252.0M 9.3M 237.5M 4% /rom
/dev/mmcblk0p3 3.3G 31.7M 3.1G 1% /
thankyou!... so it's mmc/ext4/2part... identical to rpi4...
this is for using the full space and also to get crash of the box not hanging because of a filesystem error needing check and/or repair...
the /etc/config/fstab is managed by the script also and it will add :
config mount 'rootfs'
option uuid '271bab22-d5e7-4715-9e60-7fd0d0a5c92d'
option target '/'
option enabled '1'
option enabled_fsck '1'
yes, mmc ext4 2 partitions (/boot and /(root))
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.