mrjpaxton

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.