BinaryWaves

Apologies it's been a while. I have been busy and haven't had a lot of time to mess with my helios. I had gotten it to a stable point with updates and then kernel headers, etc, and then froze. I just did an armbian update and it installed updates but now it won't boot :\ boot.log

Update: No system update but now something happened and it wont boot Getting this in there serial output: Unknown command 'kaslrseed' - try 'help' There was a commit regarding this file and rockchip here: https://github.com/armbian/build/pull/4352 Is this a regression bug? And is this comment fatal or just some warning message? Sigh I think this build is still progress though updated-boot-log.log

Apologies for late reply. So I had set the cpu governor but after the upgrades I noticed that it got reverted to default (full range 400Mhz - 1.8Ghz, for helios64). It has been surprisingly stable with bookworm, no instability issues or kernel panics really at all! I got mergerfs + snapraid running through the CLI and have my share exported over samba and nfs. So far so good! I was still a little bit concerned about a kernel upgrade borking the whole thing given past experience and after the system was up to date I froze the kernel upgrades in armbian-config, I can unfreeze later but just to be safe in the short term idk. I installed docker via softy and have loaded up a few containers and reading storage from the attached ssd m.2 drive on the mobo, all seems good there! I ran jellyfin and disabling transcoding and only using direct streaming, didn't have a huge impact on the system it seemed which is perfect! When it downloaded media files it definitely kicked the CPU load a bit over 4.0 (4 cores, so over 4 is high right?). There was a weird error where the contianer crashed during this and I thought it had kernel panicked but it was something to do with the container, i am not sure -- docker normally does not spit out an error message to console as it did for that. I am not using swarm mode on the helios but you can set a cpu limit under a deploy setting in compose and run it with a --compatibility flag which will translate it. I set the limit to 1.0 (thinking 25% max cpu capacity in my head, i am not sure how this works out tbh). It works pretty well to keep container constrained and not overwhelm the rk3399. I would like to take advantage of the gpu but apparently there are issues with ffmpeg and rockchip cpus for hardware encoding and other features? Looking into this more. So it seems my only issue at the moment is the eMMC boot thing which i am kind of at a catch 22 for...

Update 1: Did system updates and after taking the suggestion to reboot it, it kicked the fans up to max during boot like it always does (wish it didnt but as i understand some desk fans start like this as well because its better to start them on max electricity and then step down if im not mistaken?) but then it calmed them down and went through to boot without a problem! OMG thats amazing, theres been a like a half a dozen times that I've woken up in the morning and had to break out my laptop because we lost power and the helios fans were just blasting as it sat hung up on the boot part. I'm glad that isn't a problem anymore with this new bookworm build but I think it still might be messed up if I remove the jumper. I was looking into ZFS this time around but it requires disks to be spun up 100% and higher power consumption :\ Bitrot protection would be nice. Edit update: Okay, I should clarify for technicalities. the System update I did was via armbian-config (install firmware updates). After the initial reboot I did an apt update and saw i had a libc6 to update. I updated through apt update. then I checked again and there were 40 packages to install still? I went back to armbian-config and ran the firmware update again and it only installed 1 of the packages (some libpam package). So then I did another apt upgrade. It completed and I suspected I would have to reboot so I logged out and then back in as the motd prompt tells me if I need to do a reboot. It said I should reboot for the dbus package so I did. When I rebooted I got a kernel panic! I hard powered down via the front power button then powered back up and no panic this time... back to login prompt. I went in to armbian-config and set the CPU governor's upper bound to 1608MHz instead of 1800MHz. I had done this on previous installs and it seems to be more stable this way as the board tends to freak out it if hits peak CPU? not sure exactly what happens but I'm sure this will not be some magic bullet. --- Current state: After setting the governor I went to software and ran "Headers_install" to install kernel headers, and then "Full" / Install full firmware package. No reboot prompts. I need to make an image backup of the current image state. I previously ran OMV, but I just learned it isn't compatible with Debian 12... soooo juuuuustt great but fuck it i'd rather have the os updates and service patches and deal with having to set things up manually. this is the way Since I learned OMV was not compatible, I was definitely keen on preserving the sdcard a bit and installed log2ram. OMV used a more custom folder2ram but log2ram is more actively maintained it feels like and I can add folders anyway. Rebooted again as per log2ram install and no kernel panic so seems stable. Will report back after setting up MergerFS and SnapRAID tomorrow.

Side question. Since I can't boot without the jumper in place, would there by any harm in booting with it on and then removing it carefully with the system on? I kinda hope I could do the Helios instructions to re-overwrite the emmc.

@prahal Okayyyy, I'm back again. So I suspect essentially the boot record is messed up and confirmed it a little more. I powered down and pulled my drives out (except for an m.2 ssd thats on the board and wasn't on in the hotswap bay. I had set the eMMC bypass jumped and forgot why so I popped the back plate off and took the jumper off and booted. Aaaand then I remembered -- because something happened and essentially without it the jumper it attempts to load the eMMC partition by default. But whatever the issue is that causes the maintenance thing is messed up and will not accept a root password for maintenance and Ctrl+D to bypass does not work, it just reloads the prompt and after a few times it rebooted itself. I reapplied the jumper and ran it again to get the serial dump but it got stuck in a boot too and wouldn't come up. See the attached files for the boot logs, hopefully they might be of use. (The stuff above the U-boot line happens on the unjmpered boot too I just didnt grab it in the log the first time) Since it wouldn't boot for some reason and I was torching it anyway I went ahead and flashed the bookworm build to my sd and booted it up again (with jumper still in place to bypass eMMC). It like briefly came up to the root thing but then it continued half a second later through the normal first boot process and let me set root password / time / first user. I stopped here to write this and am currently sitting at the root@helios64:~# prompt. I will try to go through system updates and armbian config stuff and report back, wish me luck boot_emmc-bypass-to-sdcard.log boot-no-jumper.log

@prahal It's been a while since I checked in here. I recently moved and my system has been running stable over: OS: Armbian (23.8.1) aarch64 Kernel: 6.1.50-current-rockchip64 But have an odd issue with samba and at one point I think I borked my emmc install and the boot freaks out whenever I attempt to boot. Boot will get to kernel load or I think where its trying to figure out boot partition stuff then it will hang and have the fans blasting full speed until I can connect my laptop to it over the serial console and run Crtrl+D to advance to skip the maintenance. I am not adept enough to handle this entirely but I might give it another go here seeing as there was a build for bookworm! I would love to try and upgrade and redo my helios again with an updated image and fix the issues ive been having. @prahal thank you for your work and keeping my beloved home nas alive <3 Please message me if there is anything I can do to help your efforts Edit: I am performing a backup of my NAS now. I will attempt to perform and document my upgrade process sometime this week or weekend at the latest

Necro revive but @giddy you saved my butt a ton on this one! Thanks! <3

@n3o So far my build has remained stable. Not sure about NUT plugin. @prahal thanks for your bug fix! <3

I'm rather new and not sure what switching to a media group would entail but I think I'd probably agree with iav. I really ❤️ my H64 but we are a niche community and most of us use them for low-power homelab NAS i'm assuming. I have finally got my H64 stable with OMV6 but I am having issues with smb shares and such that i'm still working on

How can we freeze the uboot package so it does not upgrade to this broken version?

Well, after a third reflash I finally had success using [408/1414/performance] and an uncomfortably long time waiting on the install script that felt like it hung up multiple times. Then the system said there were packages to update still and broke after reboot stuck at "Starting kernel..." This is probably because of the uboot issue in the other thread.

Well, I had kernel panic when doing apt upgrade through armbian-config, so I reloaded Armbian_21.08.2_Helios64_bullseye_current_5.10.63 and froze firmware upgrades and set CPU to [408/1600/conservative]. apt update went okay and rebooted. Kernel panicked on installing with wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash Rebooted and changed CPU to [408/1416/performance] and cleaned up some mangled packages with apt autoremove and apt upgrade for the bunch that were sitting 'unupgraded'. Reran script and got no panic but the following output. Idk if there is a way to minimize or collapse the code block, apologies:

Hi @grek I had some kernel panics and instability on my Helios64 but mostly this was fixed from limiting the CPU clock as Helios had some issues at full speed. I usually set it to the 1400 option to be safe but I believe the 1600 is fine too? Need to test again. I just had to reinstall because my OMV was messed up so I'll see how it goes. Sometimes freezing the kernel upgrades might help too but I'm going to try and let it update to 22.08.6 tonight and see how it does with OMV. Will report back later.