mrjpaxton

Okay, I started looking around some more. So it's a feature that's in the SATA 3.3 standard - https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/tech-brief/tech-brief-western-digital-power-disable-pin.pdf But according to these schematics - https://wiki.kobol.io/helios64/files/schematics/Helios64_Schematics_Rev1.2.pdf It uses SATA 3.0, so my most likely guess is that it will not work right.

Hey, Quick question, can I use HDDs that have the pin-3 SATA "power disable" feature with the Kobol NAS, or should I steer completely clear of them?

@Balog Dániel Okay, just so I am 100% clear, you say you want to boot from SD card, but why is the USB-to-SATA adapter plugged in when you are booting? Are you also trying to boot from a HDD/SSD or something? Which one would you actually prefer to boot from? Unless the SD card is above Class 10 (whatever the SDXC specifications support), it's going to be slower unlike your other 3 options: eMMC, M.2 or a SATA device over USB3. You could also expose your eMMC by putting a special SD card inside. See Step 1. This will allow Offline copies since you can mount the partitions to a folder on the computer, and all you need to do is boot it with that SD card and plug it using the USB-C cable for the back. But since the Kobol runs Linux, normally any Linux backup solutions will work, including `rsync`. It should be good enough to do Online backups. If you choose to use `rsync` to backup, I recommend having a script that can do `fsfreeze -f /` followed with the folders you want to rsync over like /boot, /etc, /home, /root, /var, and then `fsfreeze -u /`. It is possible, but not advisable, to convert Ext4 to Btrfs, and then you could copy over read-only snapshots as backups, which means you don't have to do the `fsfreeze` parts, but it's a pain once you have to upgrade, because Armbian still recommends upgrading with reflashes. However, it will flash an Ext4 filesystem again. I really hope they start using Btrfs sometime on some of these larger capacity devices...

@Balog Dániel How did you install it? Since `armbian-config` is undergoing maintenance and re-haul, the best way to do it may be using `sudo nand-sata-install` at the moment, which actually seems to be part of what `armbian-config` uses anyway. Follow either System on USB or SATA (Including M.2 SATA) or Transfer rootfs from eMMC to SATA or USB depending if you want to transfer or install the OS from scratch, and skip to Step 3. Otherwise, if that's what you did, and that doesn't help... after reading your logs at the end, seems like the I2C driver gets stuck. I've read that it might be possible to solve the problem by disabling I2C. How to do that specifically for the Kobol, I'm not exactly sure, but I don't even have I2C drivers on my install when I check `lsmod | grep rk3x-i2c`. Not sure what it's needed for, so it should be possible to disable it with a blacklist config in `/etc/modprobe.d/` I'm guessing.

Yes, I have also experienced a crash without the patch. It crashed when I tried to attach a HDD hard drive with a SATA-to-USB3 device for backup (I made sure the AC adapter was used for it), so it is more "stable" and responsive than before, but not completely yet. Would it be helpful to disable Armbian's ramlog and get journald to write any dumps to storage so that I can check the logs last boot, or are you guys already aware of *all* of the issues that cause these random crashes/freezes?

Oh wow, been a while since I checked this thread. Apparently I'm still on a 2023 build. If I fully upgrade (via eMMC reflash) to Armbian 24.5.3 with the 6.6.36 kernel, will I still need the modified DTB file for improved stability, or has the DTB already been patched?

Ah, I see. Aren't there some Mali GPUs that will not run without the FOSS drivers? If it's only the drivers and not the underlying firmware, then the Mesa drivers should be fine. I'm also not using the graphical desktop, just the console. Maybe that's safer to use? Though reading here - https://wiki.debian.org/MaliGraphics Looks like it is possible to ship either user space drivers (Mesa) as well as kernel drivers. Gotta figure out which ones Armbian are using for which boards. And some may still have blobs for the drivers. So I guess it's up to everyone to figure out if they are using the completely free Mesa ones, or not.

Been hearing some news lately about some pretty big ARM Mali GPU vulnerabilities. Old boards could be affected, including ones that are not maintained. https://hothardware.com/news/arm-warns-of-mali-gpu-vulnerabilities https://developer.arm.com/Arm Security Center/Mali GPU Driver Vulnerabilities https://arstechnica.com/security/2023/10/vulnerable-arm-gpu-drivers-under-active-exploitation-patches-may-not-be-available/ I have a Rockchip RK3399 that may also be affected by this. Can Armbian do anything to help mitigate this problem? A handful of boards use these GPUs.

It can already run Mobian, which is a slightly better choice anyway. https://images.mobian.org/pinetab2/ Most ideal is just straight up Debian ARM with the vanilla Linux kernel it comes with, but that's a hard expectation these days... a pipe dream for most, because ARM hardware is so diverse and customized, and expects a whole bunch of additional cruft. The smaller screen usually demands a more mobile-focused, touchscreen interface like Phosh, Plasma Mobile, etc...

Ahh, okay. So it only has to do with the kernel and what version it is. Got it. Well, I have an eMMC install, so I back up root FS and `/boot` on an SD card every month, or when making changes, since putting the backups on the NAS itself... won't work out very well unless it's also on the entire NAS backup disk I have, too. But anyway, my kernel is "6.1.36-rockchip64", and just this week in early September I was able to do a full backup of my NAS array with Rsync on a USB 3 attached HDD just fine with zero problems on that kernel (I'm using the back USB ports, but that probably won't matter). Have you all also tested on both SD card and eMMC installs? So wait, I'm guessing this "dwc3" driver thing has to do with some other problem besides specifically USB storage devices. Maybe there are some devices it will work with, and others that it wont?

A bunch of people seem to have the same problem, and it may have to do with possibly the overall power consumption. Either that, or some other people say it's a particular software bug if you are searching for other Helios64 problem threads. Are you using the included backup battery in yours, or is it not installed?

How important is the Helios64 to you? You are going to have a very hard time finding sellers for this thing. I don't know how many total units were sold, but it seems pretty little. If you have trouble finding a seller, check my post here - https://forum.armbian.com/topic/28907-anyone-here-have-a-stable-helios64-running-omv6/?do=findComment&comment=169549 Where I talk about the TerraMaster F5-422, and JONSBO N1 and N2. The thing is these are not ARM boards, they are x86, so you can run whatever OS you want to on them as long it's all compatible with the hardware.

I don't know if 23.8 is the same as 23.08. This is where the numbering gets confusing, and I don't know why they did that... If you mean "Colobus" which was released on Sep 1st, I'm not entirely on that version right now. I didn't "dist-upgrade" the rest of the 23.08 packages. I sort of am, but here's what I mean. I have these packages held back: armbian-bsp-cli-helios64-current armbian-config armbian-firmware armbian-plymouth-theme linux-dtb-current-rockchip64 linux-image-current-rockchip64 linux-u-boot-helios64-current My version of these is apparently at "23.08.0-trunk". I can verify that my system is still working with USB and everything. Sorry to hear you're having this problem, but thanks for telling us, because I was also getting concerned if I should upgrade them or not, but I think I will hold off for a bit. The newest one available is actually 23.8.1. Have you tried that specific one, yet?

Yeah, that is a good point. I only have two drives installed in RAID 1 right now. They are HGST Ultrastar drives. I plan to install 2 more when I need more space.

I really wish I knew why mine is more stable. But i don't know if it's because I don't use OMV, Snapraid, or whatever, but I may plan to use more stuff in the future. If I could figure out how to extract some logs such as what U-Boot version I'm using, since I don't know if the installed "linux-u-boot-helios64-current" correlates to what the internal U-Boot is being used to boot up the system. I also tested with this: for i in $(seq 1 100);do python3 -c "import pkg_resources" || break; done I am getting the "free() invalid pointer", and even "Segmentation fault" sometimes but my system does not freeze up at all after it, and nothing is showing up in the dmesg or journalctl logs that I think is relevant to it. Let me know what I can share.

@TijuanaKez No problem. I'm sure it's possible to keep running Nextcloud on both Armbian or OMV. Though with OMV I'm guessing it's containerized. I haven't changed my CPU settings from default, both from when I was running Buster, and right now as I'm running fresh Armbian Bookworm with no problems for a couple days now. So I have to ask, are you using the backup battery? I am still using it on mine. Maybe that could affect stability, I don't know. I should probably start checking mine with a multi-meter at this point... When you were building the NAS (I don't think it was possible to order these pre-built), you did make absolutely sure all the cables are seated properly to the board right? And none of the SATA cords or capacitors on them look damaged? Did you also do the "2.5 Gbps hardware fix"? If you don't know what this means, then don't worry about it. Most Kobol owners would know about it if they've done it. EDIT: Oh yeah, I forgot to mention that I'm using the eMMC install. I know it's possible to try an SD card install. If anyone gets problems on SD card install, try the eMMC install, or vice versa, that may also be helpful in figuring out some of those problems. Since Armbian Bookworm has a new kernel now, "6.1.36-rockchip64", you should give it a shot, and maybe it could help solve your problem if it's a software issue. I just don't like that Armbian makes it slightly more difficult than Debian to store persistent logs to check software--or some hardware-related--rebooting problems, because you have to disable ZRAM logging in `/etc/default/armbian-ramlog`, and THEN you have to enable persistent logs with Systemd. So a two-step process. Haha.

Very important, but I want to mention here that the Armbian community has support for Debian Bookworm since June 30th - https://www.armbian.com/helios64/ For those of you still on Buster (or Bullseye) make two full rsync backups of your rootfs/configs, download the CLi version, not minimal, because it will have a particular tool which we will need, and follow the eMMC install instructions - https://wiki.kobol.io/helios64/install/emmc/ - I would personally delete the partition and wipe the partition table (requires MS-DOS, not GPT) before you "unxz" the archive and reflash the image. This is what Armbian recommends doing. The full distribution upgrade is a too risky without a backup anyway. You can then use Picocom after attaching the USB-C serial connection with this command: sudo picocom -b 1500000 /dev/ttyUSB0 Which will help with the initial setup. I want to take some of what I said about the security vulnerability implications back, because I have backed up my old Armbian Buster install, flashed this new image, and it's been running very successfully for me. Been taking some time to meticulously restore my configs and scripts that I use. Apparently according to these instructions - https://docs.openmediavault.org/en/latest/installation/on_debian.html - it is possible to install OMV on Armbian with `armbian-config`. I haven't done this yet, but someone should try this out. Run Armbian Config and go into: Software (System and 3rd party software install) > Softy (3rd party applications installer), then check OMV (OpenMediaVault NAS solution) Please try this out on a fresh Armbian Bookworm install, and let us all know how this goes! Best of luck. I'm curious to know which version of OMV this is though.

The topic of this thread is kind of old and dated now. I suppose I could either update it, or maybe a mod can close it for now. I don't know how to do it. Most of my general questions have been answered thankfully with Bookworm. I'm so happy the Armbian community is continuing to support this board. I'll probably start posting in some other Helios64 threads now. Thanks, everyone.

Okay, well I am running into one problem with the CLI (not minimal) install. So I uninstalled Network Manager and Netplan, because I prefer straight-up Systemd networkd. Did `sudo systemctl unmask systemd-networkd.service`, double checked my files in `/etc/systemd/network` and did a `networkctl` to check everything. Works fine once I enable and start the service, but after rebooting, the service does not start up upon boot, even though the service is enabled, and I can't seem to find any related error messages associated with it. What's going on there? Is it an Armbian thing? EDIT: never mind, I just tried `sudo systemctl enable systemd-networkd.service`, and now it's working again. Although `systemd-networkd-wait-online.service` is failing for some reason, but at least the rest of networkd still works.

Okay, so I finally did it this Friday. I did the expose eMMC steps - https://wiki.kobol.io/helios64/install/emmc/ (Somebody will probably have to mirror that link and the eMMC SD-Card exposure image if those instructions and files ever come Offline for good.) I'm also going to report that it all works just fine. I connected it with Picocom afterwards over USB-C with `picocom -b 1500000 /dev/ttyUSB0`, boots up fine, got a login prompt, did the Armbian initial setup stuff like setting up root password, a user password, which was different from last time I think, and then shell, etc... Now I'm in the long-haul process of meticulously restoring my config backups one by one from my old install, got SSH quickly set up again so I could disconnect the serial cable, double-checking them to make sure my static mounts will still work, my personal user scripts still run, and everything else still works without too many errors. I'm going to install more packages, set up Systemd's networking stack (networkd/resolved) the way I want, the Btrfs array, then NFS, and finally, maybe I'll even try to set up extras that I can't remember right now, like maybe disabling the ZRAM if it becomes a problem. Because usually the 4 GB of regular RAM is enough. So far, yes, everything is working great. I'll report back with any problems I run into.

@ebin-dev It is probably a better idea to back up all your configuration (home dir, root FS) with rsync or whatever backup utility you prefer before that. So yeah, I'm using the fresh Bookworm image because I'm 2 stable releases behind. That's because there was never a Bullseye image released to my knowledge. You'd have to build it. I think I have some time to try it out tomorrow if I remember to do it. If this was vanilla Debian, i would so it. OpenWrt is the same way, where they prefer the backup config and re-flash method. A little annoying, but whatever works I guess.

Great, thanks! I'll try the build too when I have the time and opportunity. EDIT: Actually, I see that there are now downloads for Bookworm listed on the Helios64 page. Someone's already 10 steps ahead. Time to text it out soon then.

Hey there, I also still use a Helios64 with the Kobol NAS enclosure. I'm not using OMV though, just Armbian directly. Since it is still on Debian 10 (Buster), and the Debian team is already at Debian 12 (Bookworm) for Debian Stable right now, Buster is considered "oldoldstable". That is the code name that Debian uses. Once Debian 13 (Trixie) is released, most of these systems will no longer get updates from anywhere, and will start severely getting out of date with more and more security vulnerabilities. One option I've been looking at is the TerraMaster F5-422 - https://www.terra-master.com/global/products/smallmedium-businesses-nas/f5-422-10g-nas.html If you look at it, it has almost the same dimensions and measurements as the Kobol There's also the F4-423 with one less drive bay and $100 cheaper. The problem is they run a bad version of Linux called "TOS", which is slow. But you can re-flash it. Since it is an x86 board, it should support regular Debian/OMV or TrueNAS, which is great. The big problem is you will void their warranty if you install another OS, and this stupid Chinese-based company doesn't really care about their customers very much it seems; I've seen that their attitude about their products and support was awful on their forums. You can't even buy replacement parts if the specialized motherboard dies, or any RAID controller boards if they break physically. You are S.O.L. if any of the HW breaks. Another option is the JONSBO cases. been looking at the N1 and N2 cases. JONSBO N1 - https://www.newegg.com/jonsbo-nas-case-mini-itx/p/2AM-006A-00074 JONSBO N2 - https://www.newegg.com/p/2AM-006A-000B7?Item=9SIAY3SJNH8050&cm_sp=SP-_-1582697-_-0-_-2-_-9SIAY3SJNH8050-_-JONSBO N2-_-jonsbo|n2-_-1 You can also see reviews on YouTube for these, or on other Sites. There are pros and cons to them as well. They are not identical dimensions, so if having exact space is a concern, maybe don't get them. The also use a regular Micro-ITX motherboard, which is great, but may not be as extremely power efficient. Still, that's more appealing than the TerraMaster right away, since it gives you more modularity, "repairability", and more available options, like putting in a low-profile Intel Gigabit Ethernet NIC, or something to the PCI-E slot. But yes, the company is out of business, Armbian no longer has the resources nor wants to support them for that obvious reason, and most of us are just users, and not experienced developers who just want a good open source NAS, hence why nobody seems to be an Armbian maintainer for it anymore. There were attempts to get vanilla Debian to run on the Kobol, but kernel patches are needed for the SATA stuff - https://wiki.debian.org/InstallingDebianOn/Kobol/Helios64 It looks like the page hasn't been updated since 2021. If it's possible that Debian 12 has the PCI-X drivers necessary for SATA to work, that would be cool. I would assume maybe the LEDs won't work right, or there will be other paper-cuts, but it would be so great to just have Debian 12 on this thing. However, I don't think that will be a reality. It's time to replace at this point. Don't wait until the next Debian release to do it.

This board still does not have a maintainer, but I'm still using and relying on it. Since Debian announced Bookworm recently, are there any new Armbian Bookworm builds that can be used for this?