So the Pi 4 has been flakey twice now in the last week.
This is reference PI4 Running 64 Bit Build (stable) fully updated, only running smb share and a few low resouirce docker containers.
First issue i noticed a mass slowdown in dns request to the point the device failed. I was able to ssh in to reboot. However i decided to check the device earlier in the week and it was red hot. So something was not right.
Anyways, i powered her down let her cool and switched syslog on so i could monitor. Did all updates and she has been fine and running cool all week
Anyways to the issue that prompted me to write this
I just logged in and Dietpi mentioned running updates for Patches
The only patch that was required was for Max Processor speeds (no 4 in the list) and that a reboot was required.
So i applied that patch which seemed succesful and rebooted.
Now she is “Dead” in that no ssh response no dockers no dietpi dashboard webpage nothing.
Which line was added to the boot config for this supposed patch so i can comment it out and see if i can get her to boot again
This is how the setting should look like: https://github.com/MichaIng/DietPi/blob/934459f/config.txt#L91
It speeds up boot by using highest frequency for 20 seconds. Otherwise the first seconds by default lowest frequency is used until the CPU governor is applied at a later boot stage.
The patch indeed should not be able to cause a change from initial_turbo=20 to initial Turbo=20 with a removed underscore and a capital T. The regex matches only lines with at least 100 characters and replaces the whole line with the first 99 characters of it. And there are no valid settings with 100 characters or more, if there were, those were naturally broken by the RPi bug the we addressed with the patch .
So not sure how your setting got invalidated, but that patch cannot be the reason .
Even stranger is that an invalid setting is simply ignored but does not prevent boot. That is the reason why we didn’t recognise the >=100 character problem, otherwise until this patch the system wouldn’t have booted already as everything above 99 characters is taken as an additional line, which was invalid until a recent wording chance, then by change became valid (but unintended).
I had an OC applied at 2ghz (temp in normal use never over 44)
OV of 4 (passed stress test fine
and Min Freq was set at 600Mhz
For now i have changed those values to
OC = 1900
OV = 4
Min = 300
Not sure wether the changing of initial turbo solved the issue could just be conincidence as far as i can tell that just sets boot time freq to max until scheduler takes over?
I will unflag that in the morning to see if i can recreate it failing to boot
As i say may be a conincidence but i have rebooted a cpl of times this week without issue, then after the patch she was unresponsive so i put 2 and 2 together and may have come up with 5
Anyway just booted with that line uncommented and she has booted up.
The only odd telling sign however is the board getting extremely hot during a failed boot, and im not talking warm heatsink im talking hot heatsink usb sockets the lot.
Its like it got stuck at whatever max boot speed when it failed to boot and seemed to just get stuck there overheating in the process. (max temp set to 65)
I just verified that invalid options are not an issue, I added a line initial Turbo=20 (invalid) and the RPi reboots fine, no issue at all . Seems to have been a completely unrelated issue in your case, or it simply took a little longer, e.g. due to an fsck or so (which is forced once every 60 mounts/reboots on ext4 by default). As of 2000 MHz overclocking it may also be this, e.g. when the device is hotter, implying a little higher internal resistances, so that voltage is not reliably sufficient for the peak at boot. This again would also explain why disabling initial turbo solved it, since with powersave governor less power/voltage is required .
EDIT: As of your last post, fsck would fit well indeed. Usually it does only do a real check when a filesystem error was reported the session before, but every 60 mounts it forces a full check. You can see the output via:
So Again the Pi4 became unresponsive and no reboot is bringing her back online.
The PI4 this time is barely warm, at first i thought it was Adguard Docker causing net connection issues, (first the nvidia shield failed to get internet connection) then my Macbook suddenly stopped getting any net.
Next the Mapped drive on my Macbook pro showed a disconnect error, so i tried to ssh into the PI4 and its dead no connection.
Pulled the power supply and plugged back in, and again dead, so same issue as before.
I will try and pull the logs tomorrow, but this is becoming a bit of a pain to be fair
Apologies, whilst i cant confirm this yet as have loads to work through to get this going, i think this is down to the half brained idiots running the software at Ubiquity, it appears they have once again mucked around with the firmware renaming the ports network assigment and in the process manage to kill the main Lan network.
And i doubt Ubiquity will ever get any better, such great hardware yet their software is so poor it’s untrue, literally had to factory reset and still half way through setting up the vlans firewalls hotspots etc it’s painful!
.
.
.