Rpi4 < $(community_build)

Thanks again,

Good shout, I did take a local back-up of the version I pulled down the last time we discussed this (which has been working very well for my use case) if I see any issues with this update I’ll let you know.

I don’t have any voip devices on my network either, so shouldn’t be an issue for me

Is this on your repo so I can track the changes? I couldn’t see it in /utilities (which I swear is where it used to be)

1 Like

yeah... as that was a super quick demo I put up the first time... thought it would be best to not propagate it too much...

as you are making use of it... i've uploaded 'devel/current'@utilities which is newer than the one in that rom... and I'll try to resend periodically with a few notes / version at the top of the file... fwiw... 'current' is mostly full of testing stuff... so older versions are likely better...

:slight_smile:

1 Like

lol... glad someone did! next time you are poking around... can you do me a favour and post the md5sum FILE of that version?

many thanks!

( note: without asking... and hastily copying in an unclean manner... i've included some perl/influx server side reference samples from you and poodad at /etc/custom/4-model-b/influx_grafana_perl_samples/ not really intended to be practically utilised directly... i.e. for reference only as they will likely get/are out of date quickly ... there is also an init.d/grafana(chroot) experimental testing script in that or the next build... probably not worth really using it in production... but worth a test by someone who knows what they are doing )

1 Like

I think you may be over estimating my knowledge of both shell scripting & perl :sweat_smile: - happy to take a look when I've got some time to try things out... also, always nice to see your handle mentioned in the files of an OSS project you like :grin:

Sure thing... although I cannot guarantee I've not made a couple of minor changes, If you want this file for ref lmk and I can ping it over.

#md5sum ctinfo_4layercake_rpi4.qos
897c21b044a9b9e556924ab51a3fb7f5  ctinfo_4layercake_rpi4.qos

Thanks for uploading the QOS script, I'm watching your repo so will try pulling an update from time to time when I catch changes.

1 Like
root@network /37# bin/rpi-sysup-online.sh  -R  current
   flavour:current online:2.7.15-2[newer] onsys:2.3.770-5
Downloading... current
ibbuildinformation.txt: OK
rpi4.64-snapshot-25261-2.7.15-2-r15599-ext4-sys.img.gz: OK
Fri Feb  5 12:29:02 UTC 2021 upgrade: validate-good de1e2a01d2bba155 /etc/opkg/keys[ok] /etc/custom/keys[ok]
Fri Feb  5 12:29:02 UTC 2021 upgrade: Reading partition table from bootdisk...
Fri Feb  5 12:29:02 UTC 2021 upgrade: Reading partition table from image...
Fri Feb  5 12:29:03 UTC 2021 upgrade: AUTORESTORE [ok]
Fri Feb  5 12:29:05 UTC 2021 upgrade: Saving config files...
Fri Feb  5 12:29:07 UTC 2021 upgrade: [MULTILOGIC]v off
Fri Feb  5 12:29:07 UTC 2021 upgrade: [sync and drop_caches]
Fri Feb  5 12:29:07 UTC 2021 upgrade: Commencing upgrade. Closing all shell sessions.
Connection to 192.168.1.2 closed by remote host.
Connection to 192.168.1.2 closed.
1 Like

BANIP BUMP


in anticipation of the newer banip version ( builds later than 2.7.33 )... two notes...
  • wrt.ini luci editiing will move to system > startup
  • for banip users; when you upgrade to those TBA builds banip wont start if you carry an older versions config... or even if you don't it wont be enabled(@config)... so you may wish to test the newer version now...
curl -sSL https://raw.githubusercontent.com/wulfy23/rpi4/master/utilities/rpi4-official-opkg.sh > /bin/rpi4-official-opkg.sh; chmod +x /bin/rpi4-official-opkg.sh
cp /etc/config/banip /etc/config/banip-old
/bin/rpi4-official-opkg.sh upgrade --force-reinstall --force-maintainer banip luci-app-banip
rm -rf /tmp/luci-*; /etc/init.d/uhttpd restart
1 Like

**ctinfo_4layercake_rpi4.qos:**
much better than?
**piece_of_cake.qos:**

depends on your environment and needs...

briefly tho' without digging into the lowlevels;

  • piece is setup so balance relatively evenly
  • rpi4.qos is experimental and is aimed at primarily auto expediting realtime/interactive~user flows ( gaming, video, browsing )

the only way to know is try it and see... won't do any harm... ( although you might want to reboot if you change back to something else as I can't guarantee it tears down everything cleanly when toggling back and forth )

2 Likes

now i am using
**ctinfo_4layercake_rpi4.qos:**

How do you install that to try?

rpi-support.sh -b | grep localversion

Excellent work @anon50098793 . Thanks for sharing this.

1 Like

I did a reinstall due to corrupted sd card. After the restore of configs and packages I see this error:

root@magiatiko / > opkg update
Downloading https://github.com/wulfy23/rpi4-opkg/blob/master/r15599-37752336bd/core/Packages.gz
Updated list of available packages in /var/opkg-lists/git_core
Downloading https://github.com/wulfy23/rpi4-opkg/blob/master/r15599-37752336bd/core/Packages.sig
Failed to decode signature
Signature check failed.
Remove wrong Signature file.
Downloading https://github.com/wulfy23/rpi4-opkg/blob/master/r15599-37752336bd/base/Packages.gz
Updated list of available packages in /var/opkg-lists/git_base
Downloading https://github.com/wulfy23/rpi4-opkg/blob/master/r15599-37752336bd/base/Packages.sig
Failed to decode signature
Signature check failed.
Remove wrong Signature file.
Downloading https://github.com/wulfy23/rpi4-opkg/blob/master/r15599-37752336bd/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/git_luci
Downloading https://github.com/wulfy23/rpi4-opkg/blob/master/r15599-37752336bd/luci/Packages.sig
Failed to decode signature
Signature check failed.
Remove wrong Signature file.
...

The rest are correct. How do I find which is the wrong signature file?

1 Like

guessing the re-install was a different version... ( restoring the backup ... it replaced /etc/opkg/customfeeds.conf with in-correct paths... from within the backup )

rpi-support.sh -b | grep localversion
grep git /etc/opkg/customfeeds.conf
fgrep untrusted /etc/opkg/keys/* | sed 's!/etc/opkg/keys/!!g'

this may fix

cat /etc/opkg/feeds.gen.onboardoriginal > /etc/opkg/customfeeds.conf
  • there is also a '-V' option for opkg that may tell us more...
  • you could also temporarily try commenting out check_signature in /etc/opkg.conf
1 Like

also trendy... I owe you an apology for being an early adopter... I think your fs issue was partly made worse as the 'fsckparts' logic did not reboot after fsck repair... ( thought was not needed as was mounted 'ro' )...

best to disable it 2.7.15 ... ( or in /lib/preinit/80_mount put 'reboot' under the lines that have 'unclean' )

i've triggered it already on my system when I needed to pull the power and it seemed to work ok....

1 Like

This seems to have fixed it!

Summary
root@magiatiko / > rpi-support.sh -b | grep localversion
############ buildid:r15599-37752336bd localversion:2.7.15-2 files:7897eb49b variant:fullest
root@magiatiko / > grep git /etc/opkg/customfeeds.conf
src/gz git_core https://github.com/wulfy23/rpi4-opkg/blob/master/r15599-37752336bd/core
src/gz git_base https://github.com/wulfy23/rpi4-opkg/blob/master/r15599-37752336bd/base
src/gz git_luci https://github.com/wulfy23/rpi4-opkg/blob/master/r15599-37752336bd/luci
root@magiatiko / > fgrep untrusted /etc/opkg/keys/* | sed 's!/etc/opkg/keys/!!g'
0b26f36ae0f4106d:untrusted comment: Public usign key of Stijn Tintel
1035ac73cc4e59e3:untrusted comment: Public usign key for 18.06 release builds
5151f69420c3f508:untrusted comment: Public usign key of Hans Dedecker
72a57f2191b211e0:untrusted comment: Public usign key of Jo-Philipp Wich
792d9d9b39f180dc:untrusted comment: Public usign key for 17.01 "Reboot" release builds
7ffc7517c4cc0c56:untrusted comment: OpenWrt usign key of Stan Grishin
9ef4694208102c43:untrusted comment: Public usign key of Álvaro Fernández Rojas
b2d571e0880ff617:untrusted comment: Public usign key of Hauke Mehrtens
b5043e70f9a75cde:untrusted comment: Public usign key for unattended snapshot builds
c10b9afab19ee428:untrusted comment: Public usign key of Alexander Couzens
dace9d4df16896bf:untrusted comment: Public usign key of Ted Hess
dd6de0d06bbd3d85:untrusted comment: Public usign key of John Crispin
de1e2a01d2bba155:untrusted comment: Local build key
f94b9dd6febac963:untrusted comment: Public usign key for 19.07 release builds

done!

                                                else
                                echo "$(basename $VNAME)> fsck-rootfspart:$ROOTFSPART [fsck-unclean-issue]" > /dev/kmsg
                                reboot
                            fi
1 Like

thats one of them... the main one is under

################## ACTUALFSCK
$FSCKEXT4 -y -f $ROOTFSPART 1>/dev/null 2>/dev/null
################## TESTIFFSCKFAILED/WORKED
if $FSCKEXT4 -n $ROOTFSPART 1>/dev/null 2>/dev/null; then
    reboot #ADDHERE probably in else as well as it failed but may lead to endless bootloop

Alright, I added it in both cases of unclean fsck.

Summary
                        else
                            #echo "$(basename $VNAME)> fsck-rootfspart:$ROOTFSPART [unclean-fsck]" > /dev/kmsg
                            $FSCKEXT4 -y $ROOTFSPART 1>/dev/null 2>/dev/null
                            if $FSCKEXT4 -n $ROOTFSPART 1>/dev/null 2>/dev/null; then
                                echo "$(basename $VNAME)> fsck-rootfspart:$ROOTFSPART [unclean-fsck-ok]" > /dev/kmsg
                                reboot
                                                else
                                echo "$(basename $VNAME)> fsck-rootfspart:$ROOTFSPART [fsck-unclean-issue]" > /dev/kmsg
                                reboot
                            fi
                        fi

Thank you! :slight_smile:

1 Like

no thankyou!... without feedback, suggestions and testing... i'd never have known...

1 Like

One more thing, is it necessary to run the /etc/custom/firewall.custom ? It is giving me an error during firewall restart ("WANIFs not eth1 or many").

1 Like