Entering unresponsive state after upgrading to OMV6

[TijuanaKez]

So I did the upgrade to OMV6  (and associated kernel update Linux 5.15.93-rockchip64).

 

Now in the mornings or after long periods of no interaction, the Helios enters an unresponsive state where none of the docker containers respond and I can no longer ssh in.

There is still some sporadic noise comming from hard drives doing things and lights on the front are showing it's not completely frozen.

 

I suspect it's attempting to enter some kind of suspend / hibernate state that is not appropriate for this system.

 

Which would be the appropriate log file to go hunting for answers for sleep/hibernate issues on Armbian?

 

And what would be the recommended way to configure the available sleep options?

 

Thanks.

 

[bunducafe]

Is the first LED still blinking regularly? Or frozen? 

 

I think it's rather a kernel panic than a problem with hibernation.

[TijuanaKez]

Yes the 1st LED is blinking when it happens. 

 

For the time being, I have disabled all the suspend modes with 

    sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Seems to have fixed the issue for now, although I did hear it reboot itself for no apparent instead once so far.

 

I'm just now seeing this on the Kobol site.

 

Suspend to RAM     Not Supported      USB host controller refuses to enter suspend mode

 

I'm a little confused with where we end up now updating the Helio64 with OMV6 and Armbian kernel updates.

I assume the original supported Helios Buster image had some Helios64 specific tweaks (perhaps disabling suspend mode by default), but now that we are on our own, the more generic Rockchip Arabian build may not have these tweaks?

Any Helios64 users care to comment If I'm understanding that correctly?

 

 

 

Edited February 28 by TijuanaKez

[Igor]

14 hours ago, TijuanaKez said:

I'm a little confused with where we end up now updating the Helio64 with OMV6 and Armbian kernel updates.

 

This hardware is not supported as far as Armbian goes, upstream can only be worse. If something will break cause of upgrades we will do exactly nothing as we receive no funding for such things. But you can. This is open source, code is available ... 

 

14 hours ago, TijuanaKez said:

the more generic Rockchip Armbian build may not have these tweaks?

Armbian has probably all tweaks that were developed and can only have more RK tweaks then generic kernels provided by Debian or other general purpose distros. What works, works, but it is very difficult to proceed and finance what is missing and keep device stable out of our private savings. Its far out of range  

 

Another alternative solution / workaround is picking previous known-to-work-kernel and froze upgrades.

[bunducafe]

Am 28.2.2023 um 21:13 schrieb Igor:

This hardware is not supported as far as Armbian goes, upstream can only be worse. If something will break cause of upgrades we will do exactly nothing as we receive no funding for such things. But you can. This is open source, code is available ... 

Just out of curiosity: If upstream only makes the OS more likely to be fragile what is the use case then for community builds that can be downloaded every now and then?

 

Am 28.2.2023 um 21:13 schrieb Igor:

Armbian has probably all tweaks that were developed and can only have more RK tweaks then generic kernels provided by Debian or other general purpose distros. What works, works, but it is very difficult to proceed and finance what is missing and keep device stable out of our private savings. Its far out of range

 

Totally agree. It's a pity that people are not willing to support open source projects like this one. I actually started now to set up a virtual machine in order to be able to compile myself. Still at the beginning but meanwhile I am thinking of freezing an old kernel that works well with my setup. Maybe the best way to go in the end because the helping hands will keep on vanishing day by day.

[SteeMan]

3 hours ago, bunducafe said:

Just out of curiosity: If upstream only makes the OS more likely to be fragile what is the use case then for community builds that can be downloaded every now and then?

The purpose of Community builds is to provide the "community" an opportunity to step up and care for these boards.  If no one is interested, eventually they will stop working and be dropped.  Armbian is first and foremost the build environment for building SBC firmwares. Second, some Armbian developers also maintain boards they personally care about.  But there are far more boards than core developers can support.  But the infrastructure is there for others to step in and support boards they care about. But in the end if no one cares enough to maintain a board, it will drop from community support to end of support eventually.

[bunducafe]

Thanks for the heads up. At the end it is really nice to see that there is still some activity in that lovely machine. I tried to compile now my own image through a VM on my Mac, but the actual VM is somewhat unstable with OS Ventura on the ARM chip but at least I know now how to do it and then my wife's machine has to do it (on Intel).

 

Meanwhile I went down with my CPU frequencies on the latest 5.19.x kernel as I encountered various reboots (even when not really using the helios64). Therefore I will experiment the next weeks with older kernels in order to find one that runs stable within my environment. I had one with an uptime more than 60 days but I cannot recall which one it has been :)

[TijuanaKez]

Appologies, I didn't mean to imply we should expect any upkeep for this board from core Armbian developers.

I do however still really love this unit, it's a damn shame it didn't work out for the Kobold team.

I was just trying to get some clarification on what was actually happening when I ran the backend updates in OMV (that includes Armbian kernel updates), and ultimately if updating the kernel now should be avoided.

 

I was hoping there's enough of us hanging around to keep track of a few small things, e.g the fans, suspend modes.

 

Which brings me to another hole in my understanding....

 

The fact that all the suspend modes were activated after updating the system through OMV update (including kernel update) ... would that be a result of updating the kernel?

 

 

 

 

[magostinelli]

I updated my system, and now is unstable, service didn't start. If look under /boot i have only the last kernel, how i can rollback to the previous one?