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.