the git README has had a note about this... need to update the top post as it's tripped a few people up...
setting things up like this allows for packing in a wide range of packages... yet not bloating everybodys logs / performance with stuff they dont need to be running... much easier to turn on one or two things than to disable 25
@migube you are a genius... you've hit two birds with the one stone here...
after all my talk about disabling stuff out of the box... it seems vpn-policy-routing has snuk through the cracks... (doh!, thats the whole reason for disabling things that and two adblocks at the same time are defo nono dodo ) and seems like it might be behind some of @alpynz 's / mwan3 issues...
it was kinda unresponsive... ( to disables ) so alpy, best of you trash the package all together...
cheers will do and continue testing... MWAN3 2.10.0-1 seems happier but vpn policy rouitng will definetly be trying to do same thing ... was still seeing occasional LUCI hangs on config chnages to MWAN but hard to pin down...
ok... you have to make this... shoutout to DarkElvenAngel [thankyou], i used an alpine chroot on-device - /etc/init.d/ntop will set one up for you if you edit the variables at the top and start it... chroot CHROOTDIR, ( apk add dtc git make etc. ), git clone, make all, (i skipped this: make install), mkdir /run, cp argononed /usr/sbin/, cp argonone-shutdown /usr/sbin, cp argonone.dtbo /boot/overlays/ ( maybe run the setup-overlay.sh )... then likely reboot and run 'argononed' ( or add /usr/sbin/argononed & to your rc.local etc. )...
[root@dca632 ../argonFANcompiled 46°]# ps w | grep argon
21458 root 840 S ./argononed
21460 root 0 SW [irq/42-argonone]
[root@dca632 ../argonFANcompiled 45°]# cat /var/log/argononed.log
Sun Sep 13 17:32:02 2020
[INFO] Startup ArgonOne Daemon ver 0.1.6
[INFO] Loading Configuration
[INFO] Reading values from device-tree
[INFO] GPIO initialized
[INFO] RPI MODEL 4B 2GB rev 1.1
[INFO] Lock file created
[INFO] Now running as a daemon
[INFO] Set GPIO 4 to mode INPUT
[INFO] Set GPIO 4 pull up/down to DOWN
[INFO] Now waitting for button press
[INFO] Monitoring line 4 on /dev/gpiochip0
[INFO] Successfully opened /dev/vcio for temprature sensor
( as with most things build related, a few users need this, i'll look at integrating it (wrt.ini option and init.d script) into the build once sort out git versioning )
I followed your explanation and the daemon is now running.
The issue is the I2C is still not working.
I have installed kmod-2c-core, i2c-tools but no i2c device appears in /dev .
Is there anything else i should be trying?
Sun Sep 13 15:12:41 2020 [INFO] Startup ArgonOne Daemon ver 0.1.6
Sun Sep 13 15:12:41 2020 [INFO] Loading Configuration
Sun Sep 13 15:12:41 2020 [INFO] Reading values from device-tree
Sun Sep 13 15:12:41 2020 [INFO] Hysteresis set to 3
Sun Sep 13 15:12:41 2020 [INFO] Fan Speeds set to 10% 55% 100%
Sun Sep 13 15:12:41 2020 [INFO] Fan Temps set to 55 60 65
Sun Sep 13 15:12:41 2020 [INFO] GPIO initialized
Sun Sep 13 15:12:41 2020 [INFO] RPI MODEL 4B 4GB rev 1.1
Sun Sep 13 15:12:41 2020 [INFO] Lock file created
Sun Sep 13 15:12:41 2020 [CRITICAL] Failed to open the i2c bus
Sun Sep 13 15:12:41 2020 [INFO] Now running as a daemon
Sun Sep 13 15:12:41 2020 [INFO] Set GPIO 4 to mode INPUT
Sun Sep 13 15:12:41 2020 [INFO] Set GPIO 4 pull up/down to DOWN
Sun Sep 13 15:12:41 2020 [INFO] Now waitting for button press
Sun Sep 13 15:12:41 2020 [INFO] Monitoring line 4 on /dev/gpiochip0
Sun Sep 13 15:12:43 2020 [INFO] Successfully opened /dev/vcio for temprature sensor
I have issue with SQM. I get very stuttery movement in games. Now i installed the new package
SQM is off and game is working fine without any stutter.
@anon50098793 what you did? after updating the pi4. All the packages installed automatically without doing anythings.
before i used to install all the packages one by one now they are already installed.
pros(for me): usb boot, particularly 'boot order' aka fallback when not present etc. also tftpboot
cons: current one works pretty well ( minus the above feature ), mmc so far seems to be the quickest...
need to keep this pi as common / bugfree as possible for the builds, and i've fried the primary uart pins... and without those i'm reluctant to mess around with the bootloader...
pretty sure the openwrt images will be fine... athough the default cmdline.txt would need to be changed after writing the image, preferably to PARTUUID= should work... come to think of it... there is probably a bit of stuff in preinit / init.d / lib-upgrade... that's likely hardcoded to mmcblk... so sysupgrade would be 'broken'
next build will support an experimental 'dual firmware' feature... you'll need to run a one time script to set it up... ( which requires internet access for now )
from that point on... subsequent flashes will go to the 'alternate' partition... so you'll be able to run 20.x and keep snapshot as the second OS...
i'll extend it to support USB... but at the moment everything is tied to a common 'boot' drive/partition... (mmc)... my pi, is in a case and getting to the mmc is difficult... so i'll be looking at making that compatible with the latest pi, firmware 'boot-order'... which would allow you to have your boot files on the usb...
os1 or os2 can be anywhere ( tied to mmc for testing )... so if you wanted to have one rootfs on usb or both, this will be do-able...
if anyone is keen on this feature... i'd like to know how you would mostly use it?
( 20.x + snapshot ? )
( wifi travel mode vs home router mode? )
etc. etc. this ties in to how config 'syncing' / partition support is implemented...
another thing is rootfs size... which i've hardcoded to be the same as the baseos ( 1G )... but it is possible to make os1 and/or os2 partition sizes whatever ( i.e. half of the free sdcard space each )
( NOTE: these features also allow for optional EXCLUSIVE rootfs partition expansion... or 'live/mode'... but as I don't really need these they are not a priority )