Here's the output of logread -e collectd > collectd.log
Looks like there have been multiple respawns of collectd (I count 13) - it seems the last respawn before the more than 2 logs didn't exit normally, and is missing the following:
freikfunk feed has been removed from master I believe... this probably wont be present in newer (factory) distfeeds.conf files...
as these are carried across within sysupgrade data... users of existing builds are advised to disable the feed in '/etc/opkg/distfeeds.conf' preferrably prior to any upgrades (or if you restore a backup) as it will likely bork autorestore functionality;
Hi.
I've been pushing my rpi 4 a little too much with multiple jobs all over the day and I would like to overclock it.
However, when I try to do it, it appears the frequency does not change.
Isn't it enough to set in /boot/config.txt the lines:
over_voltage=3
arm_freq=1600
due to the various risks and complexities involved with overclocking...
on this build... the preferred method to 'overclock'(and 'underclock') is by tweaking the governor ( runtime within OS )...
/root/wrt.ini
POWERPROFILE="quickest"
try the above... ( check there is not a value already assigned i.e. a line that is uncommented... I may have set 'quick' as the default recently... cannot remember )
( in which case change that or duplicate and comment it out )
after changing this setting to apply without rebooting run;
fyi, as your sending your collectd stuff to a server... technically you could/should do without the 'persistentlucistatistics' feature...
alas... I haven't cleanly checked/implemented a clean way to do this currently... i'd assume adding SERVICESDISABLED="persistentlucistatistics" to wrt.ini and commenting out the existing line in /etc/crontabs/root
would be the logical way to do this... but probably better to not bother for a few builds (or at all if the workaround is ok)... I may get the chance to test/tidy over the next few builds...
basically... what these do is
copy /tmp/rrd to persistent storage in case of power loss ( @neil1 made me aware of this condition ) prior to that... there was no constant 'build-related' restarting of collectd...
some other stuff that tries to transparently retain luci_statistics and nlbwmon data over reboots and upgrades (messy as carp but I'm a little scared to touch it...)
hoping the 'end-existing' workaround largely resolves the fundamental issue for now ...
you can disable that cron script... although the firstboot logic may put it back each upgrade...
The next overclocking options will work if you have a good power source and enough cooling, of course:
# Overclocking to 1.75GHz
over_voltage=2
arm_freq=1750
# Overclocking to 2Ghz
over_voltage=6
arm_freq=2000
# Overclocking to 2.174GHz
over_voltage=6
arm_freq=2147
gpu_freq=750
Mine is running at 2Ghz for different reasons, since 8 weeks ago. If what you need is a quick ramp up of CPU frequency just go with @anon50098793's governor tweaks.
yeah... it's a bit of an odd one... rngd/rng-tools@/dev/urandom seems to be the sweet spot... ( i'm sure something whacky gets switched out at a lower level )
$ecmd "hardcode workaround setting to urandom seems to sync all 3"
uci set system.@rngd[0].device='/dev/urandom' #NOPE uci del system.@rngd[0].device='/dev/urandom'
uci commit system
/etc/init.d/rngd enable; /etc/init.d/rngd restart
uci show system | grep rng
system.@rngd[0]=rngd
system.@rngd[0].enabled='1'
system.@rngd[0].device='/dev/urandom'
Just an FYI of my experience on the RPi 4B so far.
I'm using an Rpi 4B w/ 8 GB RAM with two USB/Ethernet adapters (one is RTL8153 and one is AX88179, so 3 Ethernet ports in total) and a 32 GB A1/U1/C10 micro SD card for the code. And a 5V/3A power supply; plenty to support two USB/Ethernet adapters.
First I installed Snapshot 25730 r15963 all worked well for a day or two.
Both USB/Ethernet adapters worked from the start. No additional installs needed.
BUT once the power died (life here in the country) OpenWRT never came back up. It served the 192.168.1.1 on Eth0 but I could not SSH in, could not access the HTTP page nor ping Eth0. That was with and without the two USB/Ethernet adapters.
I reinstalled the snapshot (dd to /dev/sda, resize sda2, etc).
That started up fine, but it would not take the backup file made earlier....
So I reconfigured everything, then as a test I pulled the plug.
Dead again.
-Ok this is snapshot code so move on. I next applied Snapshot 25737 r16121.
Everything works again (actually a bit better than before).
I then pulled the plug again to see what happens.
Same problem, Eth0 served 192.168.1.1, but no ping, SSH or HTML possible.
I reinstalled everything again (still can't use backups) and it too could not recover from a power failure.
My old TP Link AC1750 has no such problem with OpenWRT.
Let me know if I neglected something so this could recover from a power failure but don't make a big deal of it. I'll wait for a few more revisions before I try again.
Seems to be working so far, I've seen some further unclean exits crop up from collectd, but still only ever seeing one version of sqm_collectd.sh running every time I've checked.
I'm trying to keep my build as close to yours as I can, so I don't have to think/remember too much when upgrading (I've made that mistake far too many times!), so I'll leave out disabling persistentlucistatistics changes out for now.
sorry, i missed your post until right now... and first of all thankyou for posting your experience / feedback...
background
due to alot of custom logic within the build... resizing partitions poses quite a few potential break points...
i have alot of experimental/disabled code within the build... one of those expands the rootfs partition to use the whole sdcard... part of the issue I have with fully promoting/finishing this option is if a user then fulls up the root partition with data... they typically then need to migrate that data outside of typical backup / keep settings methods... having a spare usb drive block mounted and pointing all your service data there totally avoids this complexity... is immediate, predictable, extensible... etc. etc.
to investigate
so... if you wish to keep trying first thing you should exclude is cmdline issues...
after that... it's probably your resize proceedure conflicting with fsckparts on the command line...
you pulling the power will activate fsckparts if it is enabled... and it's not happy with what it's finding... could be a bug on my side or yours... but you'll probably need a serial console to actually see whats happening...
in short... as stated before... the 'recommended' method to obtain more storage with this build is to use a usbstick...
( that said... I am ready and willing to further assist you to debug and possibly test the build in rootfsexpand feature [trying again in a few months likely wont help but actively testing and collaborating will]... there is no doubt it will lead to better robustness more generally anyway )
for reference here is what I run;
########## uci show fstab
fstab.@mount[2]=mount
fstab.@mount[2].target='/usbstick'
fstab.@mount[2].uuid='d088ab74-76b6-4760-aa88-3d0234c06d48'
fstab.@mount[2].enabled='1'
wrt.ini / or any other service data params (optional)
this is probably a more important separate issue...
for now... if you can next test this by only using a backup created on the same version... and try to restore from the command line with;
sysupgrade -v -r <backupname.tar.gz>
and post the output here...
also search the thread for 'sysupgrade-clean-backup.sh' and read any related comments around those posts... it's a wip but again polishing, collaborating and more testing of this is needed...
dd'd a new copy of Snapshot 25737 r16121 to my micro SD card (I'll leave the USB stick matter for another exercise since it is not a high priority).
I did -not- expand the the second partition or do anything else to the SD card. I just booted from it in the RPi4B
I then attached and mounted a Samsung T5 SSD with the backup file.
I ran Wulfy23's sysupgrade -v -r <backupname.tar.gz>
and that "worked". I say "worked" in the sense that it appeared to work; all my settings were back, and I could pull/kill power to the RPi4B and it would restart as desired.
You folks were right that enlarging the partition was the root of my problem.
My next issue is that my eth1 and eth2 adapters get mixed up (eth0 is the port on the RPi4B board). I'll bring this up as a separate question below to keep things separate.
Let me say here for completeness that when I said yesterday that this Snapshot code would not take the backup file, that was from in LuCI. I did not try it from in an ssh/terminal at that time.
As requested, here is the result of the sysupgrade -v -r command:
Just for interest, once the RPi4B was booting well from this snapshot, I added a third partition to the SD card. I left about 150 MB gap between partition 2 and 3 and ran 3 to the end of the SD card. I did this in fdisk, and formatted partition 3 ext4.
The RPi4B would not boot even thought partitions 1 and 2 were untouched.
ok... so one of the reasons I created 'sysupgrade-clean-backup.sh' is to exclude certain stuff that is problematic...
with the new 'partuuid' based images... restoring an old (from a non-identical install) backup will insert a cmdline.txt that contains an incorrect root=PARTUUID=INCORRECTNUMHERE... ( well technically some older backups may have contained root=/dev/mmcblk0p2 which would restore/boot properly from the mmc slot )
i'll check the logic in that script over the coming week related to this... but in the interim... one workaround is to untar it on a hostpc remove cmdline.txt and retar it... or I believe if you change it back to root=/dev/mmcblk0p2 my logic doesn't touch it after that...(but you lose the ability to boot from usb)?
logging has resumed
