Jump to content

mrjpaxton

Members
  • Posts

    34
  • Joined

  • Last visited

Everything posted by mrjpaxton

  1. 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.
  2. 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.
  3. 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...
  4. 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?
  5. 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?
  6. 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.
  7. 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?
  8. 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.
  9. 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.
  10. @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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. @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.
  16. 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.
  17. 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.
  18. 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?
  19. I'm really glad people are discussing this instead of blatantly tossing a perfectly good case with parts, leading to more e-waste. I had almost forgot the case was Nano-ITX compatible. The biggest challenges will be getting the fans, LEDs, the backup battery, and hardware buttons (power/reset) to work. The back with the I/O shield will also need to be replaced, or removed completely. Otherwise, it sounds doable.
  20. I am really happy to hear that you were able to narrow down the rsync issue! Yeah, for me, rsync is one of those essential utilities I couldn't function without to do my backups properly. Using scp just doesn't cut it anymore! And I am not hacking it to use a Btrfs root FS on my Armbian install, so I can't just use Btrfs send and receive on snapshots to backup (or, for example, the equivalent way for ZFS). My NAS is a Btrfs RAID 1, just set up with pure Armbian and NFS (no OMV) so I think I won't run into any ZFS issues... I might be good to go and try it out next week, maybe.. Like I said, I can always just re-flash a Bullseye Armbian image and migrate over my config files. As a side note, the halved performance slowdown on eMMC is a minor concern. Sometimes I want to use the NAS with other services. For example, I also have it set up as my print server (CUPS), so it needs to access the spool, etc... and I'm also thinking about trying some other services on it in the future. But anyway, even `apt cache search` runs very, very slow after it gets to "50%" for some reason, and I have no idea why. I think someone on here had a fix for this, but I can't remember what it was...
  21. So I continued to keep Buster by putting in "buster", "buster-upgrades", etc.. in my /etc/apt/sources.list files, then did an `apt full-upgrade`. It pulled in the latest kernel 5.15.25 and some other updates, and the rsync issues you were talking about did not happen to me. So it sounds like it is possible to only get kernel 5.15.25 working on Buster well enough. Either that, or I'm just lucky. But I am going to check stability for at least a week before I even consider re-flashing with Bullseye (I won't even upgrade from Buster to Bullseye within Buster, I suppose.) But if Bullseye still has issues with things on Kobol, even when re-flashing it new and copying over my config files that I've backed up, I guess I will be sticking with Buster... I have no idea how long updates to Buster are going to be supported by Armbian anyway.
  22. Hey guys, I figured it was time to ask again... Does doing an `apt full-upgrade` from Buster to Bullseye break anything like before a year ago? I kind of want to do it, but not if the eMMC issues are still around. I really prefer not using the slower SD card method. And i also want to ask about stability for people that still use a Kobol with Armbian on Bullseye. Any pertinent issues with anything? A few people on here have claimed that they have gotten the vanilla Debian kernel to run on the Helios64, but I'm not sure how... Sure would be great if the vanilla Debian distro worked on this board, but I doubt that'll ever happen... I love my Kobol, and I am going to have a hard time finding a good replacement for it. i just really like having full CLI access, complete understanding of all the hardware, little to no proprietary bits, and also the open-ness of the hardware. It's all great. But man, finding alternatives NASes is going to be hard for me now. Hahaha. (Please ignore the fact that I posted this on April Fools Day. That's just a coincidence).
  23. Hey, I have uninstalled cron from my system completely, but I just thought I might help contribute, even just a little, by making some services and timer files to replace the ones in these folders: /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.weekly Now keep in mind that I have not fully tested any of these yet! I would appreciate feedback in testing these, since most of these I won't even use on my system. I barely even use the armbian-config utility at all, so... yeah... The files in question are these. Let me know if I should add more: armbian-truncate-logs armbian-updates armbian-ram-logging These are the Armbian specific ones. I know there's ones for like man-db, mdadm, logrotate, fake-hwclock and a bunch more that get installed by default. And I think systemd already has timer files for some of these. In fact, here's the timers in use on my Kobol system right now: # systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Sat 2021-09-11 18:43:28 PDT 13min left Fri 2021-09-10 18:43:28 PDT 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Sun 2021-09-12 00:00:00 PDT 5h 29min left Sat 2021-09-11 04:38:49 PDT 13h ago logrotate.timer logrotate.service Sun 2021-09-12 00:00:00 PDT 5h 29min left Sat 2021-09-11 04:38:49 PDT 13h ago man-db.timer man-db.service Sun 2021-09-12 05:57:58 PDT 11h left Sat 2021-09-11 17:25:28 PDT 1h 4min ago apt-daily.timer apt-daily.service Sun 2021-09-12 06:20:19 PDT 11h left Sat 2021-09-11 06:59:08 PDT 11h ago apt-daily-upgrade.timer apt-daily-upgrade.service n/a n/a Sat 2021-09-11 05:57:28 PDT 12h ago update-ddns.timer update-ddns.service 6 timers listed. Pass --all to see loaded but inactive timers, too. The "update-ddns" timer and service is my own custom one. The rest are defaults. So we'll start in order of shortest to longest activation times: armbian-truncate-logs (runs every 15 minutes) /etc/systemd/system/armbian-truncate-logs.timer [Unit] Wants=armbian-truncate-logs.service [Timer] OnActiveSec=15m [Install] WantedBy=timers.target /etc/systemd/system/armbian-truncate-logs.service [Unit] Description=Truncate the Armbian log files [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-truncate-logs [Install] WantedBy=multi-user.target armbian-updates (runs daily and on boot up) Note: We are going to change this to run after the network is brought Online, but still make it run daily. /etc/systemd/system/armbian-updates.timer [Unit] Wants=armbian-updates.service [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target /etc/systemd/system/armbian-updates.service [Unit] Description=Check for updates on the Armbian system After=network-online.target [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-apt-updates [Install] WantedBy=multi-user.target armbian-ram-logging (runs daily) Note: It is mentioned that this cron job should only run when logrotate is a cron job. This was confusing wording at first, because it doesn't tell you if it prefers to either have logrotate as a systemd timer, or if logrotate should not run at all. After looking inside the script "/usr/lib/armbian/armbian-ramlog", which passes "write" as the first argument, I tried to see if there was any problematic code that conflicts with logrotate... Using the "syncToDisk ()" function, it doesn't seem like it'd conflict with logrotate at first glance. Just to be safe, I've included the line "Conflicts=logrotate.service" just in case. If this can be safely removed, let me know. /etc/systemd/system/armbian-ram-logging.timer [Unit] Wants=armbian-ram-logging.service [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target /etc/systemd/system/armbian-ram-logging.service [Unit] Description=Perform Armbian RAM logging Conflicts=logrotate.service [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-ramlog write [Install] WantedBy=multi-user.target --- That's about it. Again, not sure if any of these should be set to "oneshot" or "simple" services, or if they need to be active "RemainOnExit" or whatnot. Just hope I can give a good template for converting cron jobs to systemd timers. It's a lot simpler than I thought to convert them. Have a wonderful day, Armbian team. And thank you for all you contribute to this project.
  24. Well, here's my issue. I'd like to explain it. The problem was I wasn't even doing a full upgrade. I was just using "apt update; apt upgrade", and upgrading the system normally. So if even a normal upgrade breaks the system, there's something seriously wrong here... I don't know much about Debian's policies, but I do know a full distribution upgrade should only be done with "apt dist-upgrade" or "apt full-upgrade", and this policy wasn't respected. It would have been fine if the latest rockchip64 kernel image was held back before the upgrade, so that it had time to get bug fixes. Also, the version numbering is confusing. The version for "linux-image-current-rockchip64" is set to "21.08.01", but that's not what version the kernel is. Shouldn't it be "5.10.60-rockchip64". That might have helped me avoid this problem altogether, so at least I'd know what version of the kernel I was about to install. In other words, I had no idea "21.08.01" had the broken kernel "5.10.60-rockchip64". I know Armbian is different than Debian, but it really should play more nicely to what regular Debian users are used to, rather than deviating too much from it. It's one of the reasons why I chose Armbian! It is because I expected it 99% to work like Debian, except maybe for the fact that it uses a different kernel, DTD, maybe a BSP (base support package), U-Boot, and a few necessary patches. But changing how core OS updates and upgrades work is just wrong to me. A side note, I know U-Boot isn't GRUB, but it really would be nice to have support for multiple (backup) kernels like I'm used to on x86 with GRUB. It is different code, and a different arch, so I guess that makes sense though... Still a shame. I will look around and see if the solutions work. Otherwise, I'll try to use my full rsync backup.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines