bunducafe

My Helios64 has some hick-ups now end then and it takes a few attempts to get it booted properly. No big big issue, but annoying nontheless. I am wondering who is playing with the community builds? Until now I could not dig deep enough to compile my own build so far but I do suppose that some might do that here and possibly share the output. Or push me in the right direction where I could look and / or indeed build something from the scratch... The hardware setup of the helios64 is untouched therefore I do think that I don't need a kernel >5.15. but within the community builds we are already at 6.0.x and I have that slight concern that this will work well together with OMV for example... or is this a concern that I should not have at all Or do you guys have a preference for a specific / stable linux kernel for the helios64? That's also something I would consider to freeze the kernel completely if one of the builds work as expected without hick-ups.

For me a nobrainer, as I am sticking with SD cards in order to not have the hassle if something really goes wrong as they are easier to backup. But in any case I have this kernel also as a running backup on a SD Card

Okay. Just wondering, how you are disable the armbian.list. Here I only have one entry and so far I went down the freeze kernel via armbian-config. Is there any difference? And if so, what would it be. Thanks you for the offer. I will look into your link once I am back in my office and then might get back to you in the near future That's very kind. BTW: The actual culprit of my random reboots has not been a faulty upgrade rather than the USP Battery caused the problems and made my machine unusable (did not react when pressing buttons and rebooted every 10 minutes). After ripping the USP out everything works flawlessly again.

Okay, after I dared to do an upgrade last week my helios64 is not constantly trying to reboot. I am back with an old backup now but just wonder how you guys are doing it: Freeze the kernel updates? Or do you indeed compile yourselves? To be honest I could not dig into compiling a kernel myself so far as I don't have the time right now. But somehow I think it will be the only solution in the end (or get rid of the helios64 and change to a different board).

Just a quick question: Is there any community related development regarding the helios64? I know there is no official support but I am curious where to look whether there are some coders who do so. When setting up the helios from scracth I found the archived download page that contain the old images and of course I can use them. But I just wonder if there is any form of development. Otherwise I also will have too look into compile kernels myself

Since the emmc bug I am kind of reluctant to put the OS again on that device. I have gone back with SD Cards that I can easily backup once in a while. That said I always have a running backup.

I am working with: Linux helios64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux I have snapraid configered via the OMV interface but MergerFS and LUKs manually because the plugins were not present at the time but I am not sure if this really does any difference. Beyond that I am using some Dockers like Airsonic, Jellyfin, Nextcloud. And the ondemand governor is now between 400-1800MHz and runs all the tasks (Snapraid + rsync + smart on a weekly basis) smoothly. My current uptime now is 21 days.

Since 4 weeks now I am runnign the helios64 together with OpenMediavault 6 with the full CPU capacity and ondemand governor. Before I had always problems when doing an scheduled task but with OMV6 the problem seems to be solved. I am quite pleased now with the performance and a rocksolid NAS.

@Amix73 What a spirit! That is really great! I am kind of the same as you with not too much experience in coding and debuggind and time to do everything... so I will do a donation next week (is there a Link somewhere to be found how to do this?). And: I don't really understand why people here selling there units

Hm, that always depends on the setup. I am in the Apple universe and I find that SMB works a bit faster on OMV6 but as you can edit the preferences yourself there should not be too much of an issue to modify this to your needs.

Go ahead, OMV6 works fairly well with the Helios64... there are some bits and pieces that are not completely ported (plugins for example) and some need a bit of adjustment whatsoever. But all in all it is okay. I am running OMV6 together with SnapRaid. MergerFS and Luks I am running outside of OMV as I do find it easier to customize for my needs.

Okay, my bad. I just should think a little bit more beforehand then I could solve things myself. Well, as I was affected by the malfunction of the eMMC after having upgraded the Linux kernel i did format the eMMC but did not pay attention that it still able to boot from that partition. A look into the Troubleshooting section would have solved everything within minutes: https://wiki.kobol.io/helios64/troubleshoot/ Anyhow. I can now turn off the machine as expected and everything's fine.

@Heisath Yes, that's exactly why I am "puzzled". I have to get the console going then which in the past did not work well together with my MacBook Air. Anyhow, let's give it another try... Beyond that: I did a fresh install with armbian and further with a fresh OMV. WOL is not enabled nor is the GPIO Auto-Power On. I will report once I found the culprit or if I need any further assistance

I'd love to bump this thread one more time as it really annoys me. I was reinstalling OMV but it seems that it is not the culprit of the unwanted boot after a shutdown. Yesterday I installed the alpha OMV6 and it ran fine. I shut it down over night and ejected also the sdcard but this morning the blue leds a are flushing again I did format the eMMc, too beforehand so I have absolutely no idea why the helios64 repeatedly comes up again. Why does it not stay shut down? And: Where do I have to look in order to get the server to behave like I want it to?

I am currently away from the office, so I can only verify that once I am back in a week or so... But as I did not encounter that issue beforehand I wonder if it can occur "just" out of the blue...?! Okay, just connected via VPN: No alarm set, so RTC is not the culprit.