• Content Count

  • Joined

About ShadowDance

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @RockBian my suggestion could fix your issue since it gets rid of the gzip compression. The caveat, of course, being that the files will no longer be compressed. It might be possible to edit 02-armbian-compress-indexes and changing the compression to lz4 (if that works) but I haven't tested it.
  2. It's probably indicating a kernel panic. You could try limiting CPU speed and setting the governor as suggested in the linked topic. You could also try hooking up the serial port to another machine and monitor it for any output indicating why the crash happened.
  3. If you want to speed it up, you can quick-fix it by doing the following: sudo rm /etc/apt/apt.conf.d/02-armbian-compress-indexes sudo rm -rf /var/lib/apt/lists/* sudo apt update If you don't want to remove 02-armbian-compress-indexes you can edit it and change true to false. Do note that these will, unfortunately, be overwritten/replaced by future updates to the linux-buster-root-current-helios64 package.
  4. @SR-G have you tried limiting min/max CPU speed as well as setting the governor as suggested in ? I had good luck with only setting governor to performance for a long time, but recently had a system lockup as well. Unfortunately I didn't have serial hooked up at the time so I didn't get any reports. Will keep monitoring (with serial hooked up).
  5. Hmm, I think one reason you’re not seeing it now could also be that disk access patterns changed by removing the encryption. For me the issue is easily reproducible even without encryption. Simply do a read via dd on a disk. For me speed of reproduction varies depending in which disk slot is read from. Here’s an example command: You may want to try this on each disk just to confirm the issue isn’t still lurking around. Good luck!
  6. This looks like the same issue as I’ve been having, it’s possibly due to the SATA cables in the harness. I’ve tested with other SATA cables and can’t reproduce the issue with those. So I believe it’s not likely to be bad disks but that is a possibility of course. You can start by trying to limit SATA speed to 3 Gbps and see if that helps, if it does it’s very likely the same issue. I also recommend doing SMART scans and scrub _after_ limiting the SATA speed. See my other topic for more information: Good luck!
  7. You probably have the answer you're looking for already, but yes, they do stop :).
  8. For spinning disks, you should use ashift 12 (and ashift 13 for SSDs) when creating your ZFS pool. It can't be changed after the fact and should match the physical block size of your HDD (12 = 4096). ZFS read speed also benefits from additional disks, if you e.g. created a mirror across two disks or say a RAIDZ1 across 5 disks, you should see pretty good performance. Also, to make the above test unfair (in favor of ZFS), you could also enable compression (-O compression=lz4). zpool create -o ashift=12 ... Personally I use: zpool create \ -o ashift=12 \ -O aclt
  9. @dancgn if it crashes occasionally, you could try to use armbian-config to change the CPU speed / governor to 'performance' (armbian-config > System > CPU). I personally use 1800000 for CPU speed but I've seen 1200000 recommended elsewhere on the forum, YMMV.
  10. If you're seeing a few of those every now and then, nothing to be alarmed about. It can happen when the CPU is stressed and is normal. If you're constantly seeing it then you might want to consider either reducing the CPU load or disabling NOHZ. For understanding what NOHZ does, I highly recommend this Stack Overflow answer to: "How NOHZ=ON affects do_timer() in Linux kernel?". If you want to get rid of the message, you can simply add the following to /boot/armbianEnv.txt: extraargs=nohz=off But if you decide to do this, make sure you fully understa
  11. @grek I've been using compression since the get-go, and can't say I've had similar issues so far. The only time I had a kernel panic was from before I switched to the performance governor for the CPU. LZ4 is also a pretty light-weight compression algorithm, but it does increase CPU to a small degree. Potential changes I have compared to your setup: I run root (/) on ZFS I use full disk encryption via LUKS (that's an additional layer between ZFS and kernel) I use the performance governor My disks are limited to 3.0 Gbps SATA speed Things you could try
  12. @manman hmm, the configure step should’ve taken care of that. You could try to specify the correct path manually via: If that still doesn’t help, see if you have any other linux-headers installed and remove them all.
  13. @Salamandar Yes, I've been using 5.8/5.9 since the get-go. You probably need the `linux-headers-legacy-rk3399` package (modify the apt-get download stage). Good job automating the process .
  14. I've also noted the sudden power loss to drives and that it only happens during reboot, not regular shut down. When doing a regular shut down the drives seem to shut down one at a time, and when reboot:ing they lose power simultaneously. Now, I'm wondering, what happens if the system is running from the drives and we're using a systemd script to stop them? Is there a chance that they will spin up again because another script is loaded or something similar? It may be a stupid question but I'm not very familiar with systemd. I imagine it should be the very last thing that's executed
  15. If you want the fans of your Helios64 to start spinning earlier, look no further. This will allow the fans to spin at a constant speed from the earliest stage of initrd until fancontrol is started by the system. My use-case is for full disk encryption and recovery in initramfs, sometimes I can have the machine powered on for quite a while before fancontrol starts. Or, if the boot process encounters an error the fans may never start, this prevents that. Step 1: Tell initramfs to include the pwm-fan module echo pwm-fan | sudo tee -a /etc/initramfs-tools/modules Step 2: