Jump to content

hartraft

Members
  • Posts

    14
  • Joined

  • Last visited

Everything posted by hartraft

  1. I have an Odroid XU4. My other devices are a tinkerboard (rk3288) and a Rock 5b (rk3588 but I don't think it's on kernel 6.1 yet) If you point me in the right direction I could take a look at updating it
  2. Hi I'm quite new to MGLRU. I've got the community build of armbian running on 6.1.0. But when using mg-lru-helper, it wants to set /sys/kernel/mm/lru_gen/enabled But the /sys/kernel/mm/lru_gen path doesn't exist. Is there something I need to do to get the kernel module?
  3. Like everyone I'm sad for the news. While the reality is difficult, in the end Kobol still achieved a great job in delivering the product in these circumstances. Considering how many kickstarters fail and have vapourware products. My only hope is that this will inspire a future aarch64 NAS whether it's by Kobol or another manufacturer. Would it be possible for the Kobol team to share the 3D print files for the drive trays? So that if some need repair we can fix this ourselves?
  4. @gprovost I took a quick look at your previous reply in the thread. It looks like I have the Rockchip blob (line "DDR Version 1.24 20191016") since I haven't updated since 2020.07 LK 5.9.X and initially my LK 5.10.X upgrades had issues. Is there a way to update the UBoot without losing the rest of the system? Perhaps that was my issue and since I didn't reboot in a while, I avoided that scenario...? Modified the armbianEnv.txt on a spare Linux machine. Output below:
  5. Okay... So I had to jinx it... After 100 days of uptime, I had to do some electricity work in the house. Either the Helios64 shut-down after the UPS was spent or it rebooted / shut-down. Now I can't boot the thing back up anymore. Connected through picocom and it doesn't get past "Starting kernel". Tried without any disks attached, same thing. Similar to another thread, the LAN LEDs don't light up (obviously). Any ideas?
  6. Thanks for that feedback, noise is something I would want to indeed avoid and I'm not ready to upgrade to 10Gbe (not enough devices). That's reassuring that between vendors there isn't anything to watch out for in particular, since these are mainly unmanaged switches there isn't really an interface to compare between them. I did see this on reddit though for the QNAP so just monitoring if there's other potential faults. But whatever I can easy source seems in the EU seems fine for my case. Thanks all!
  7. I'm in the process of upgrading my network and with the Helios64 capable of 2.5 GbE, what are some people's switch recommendations? My needs aren't really too high so I think 5 ports should be enough until the rest of the infrastructure catches up in my home network. My short-list are: * QNAP QSW-1105-5T * TP Link TL-SG105-M2 * TRENDnet TEG-S350 Article from servethehome
  8. My system has been "stable" running the LK 5.9. I updated to 5.10 in the past but had issues with stability under small load, not rebooting through omv etc. so I went back to the previous version. Running MergerFS / SnapRAID / LUKS on Seagate Ironwolves with the 1.2ghz frequency $ uname - a Linux helios64 5.9.14-rockchip64 #20.11.3 SMP PREEMPT Fri Dec 11 20:50:18 CET 2020 aarch64 GNU/Linux $ uptime 20:25:53 up 67 days, 19:23, 2 users, load average: 0.08, 0.12, 0.12 I'm sticking with this until things get clearer but would like to get full use of my NAS hardware...
  9. Regarding stability of the helios64 and the support of ZFS on ARM, why wouldn't a more preferred setup be normal RAID, mergerfs/SnapRaid or MooseFS as some have run in other setups? I'm asking from a naive point of view, no disrespect for ZFS. I already heard of its prowess in x86 Solaris/FreeBSD/Linux. Just looking for the most stable environment for "the current situation"
  10. Is this something ddrescue can do that is quite similar and sufficient to backup the system?
  11. Thanks for this, I'll try on my end too. I think many people follow the "perfect media server" guides which pretty much have this setup
  12. Whilst i'm satisfied with my Helios64 as well, i would have liked: the original RK3399Pro as the NPU would have been useful in tensorflow for Photoprism (as a Google photos replacement). RK3588 would be even nicer but everyone is waiting on that chip more RAM, once Photoprism indexes photos, it easily runs out of memory. I limit the memory in docker now but its not ideal. Granted, there is an issue on their code so i just keep the container restarted each night NVMe for fast disk access Better HDD trays (already mentioned) the screw eyelets for the backpanel (1st pic below) not to be directly aligned with the eyelets for the backplane (2nd pic below) for easier assembly.
  13. I'm getting the same problems as OP. When I do a sudo reboot, it's the same issue. The helios64 doesn't come up but you can still ping it on the network (LAN LED not on)
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines