• Content Count

  • Joined

  • Last visited

About wurmfood

  • Rank

Recent Profile Visitors

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

  1. Sigh. Except that doesn't solve the problem. Now it's just cron filling up the log. New solution, using the sleep option. Modified helio64-ups.service: [Unit] Description=Helios64 UPS Action [Install] WantedBy=multi-user.target [Service] #Type=oneshot #ExecStart=/usr/bin/helios64-ups.sh Type=simple ExecStart=/usr/local/sbin/powermon.sh Modified powermon.sh: #!/bin/bash #7.0V 916 Recommended threshold to force shutdown system TH=916 # Values can be info, warning, emerg warnlevel="emerg" while [ : ] do main_power=$(cat '/sys/class/power_supply/gpi
  2. While something that sleeps for 20 seconds might be better, I've set up the following script in cron to go off every minute. <removed> My crontab looks like: <removed> I've tested this and it seems to work. The pipe to systemd-cat lets this log to the system journal at a set warn level. -- Edit: Removed extra stuff here to clean things up a little. This didn't work the way I wanted.
  3. It looks like you have been booting from the eMMC, right? I think you're going to need to boot off an SD card and try to fix the GPT. This may help you with doing that.
  4. @SIGSEGV It is disabled by default, but since I had some time the last few days I've been digging into things and came across this. There's a corresponding service, but all it does is check to see the state of the battery and then exit. If something else is monitoring the battery, I don't know what it is. The service could be rewritten as a script that has an loop that checks the state of the battery every 20 seconds and then sleeps.
  5. While I like having the helios-ups.timer in case of power failure, I don't like that my logs get three lines written to them every 20 seconds. Apr 09 07:43:26 helios64 systemd[1]: Starting Helios64 UPS Action... Apr 09 07:43:26 helios64 systemd[1]: helios64-ups.service: Succeeded. Apr 09 07:43:26 helios64 systemd[1]: Finished Helios64 UPS Action. Does anyone know if there is a way to keep the timer on but not fill the logs this way? Everything I've found about silencing systemd messages is about the output of the command, not the systemd activity itself.
  6. Well, for anyone else interested in trying this, here's the basic order I did: stop armbian-ramlog disable armbian-ramlog create a zfs dataset and mount it at /var/log cp -ar everything from /var/log.hdd to the new /var/log modify /etc/logrotate to disable compression (since the dataset is already using compression) modify /etc/default/armbian-ramlog to disable it there as well modify /etc/default/armbian-zram-config to adjust for new numbers (I have ZRAM_PERCENTAGE and MEM_LIMIT_PERCENTAGE at 15). reboot
  7. Is there an accepted procedure for moving from using ramlog to logging to disk? I've looked but everything I can find is about setting up ramlog. I assume it's more complicated than just creating a partition (or ZFS dataset) and mounting it /var/log, disabling ramlog, and rebooting.
  8. Thank you. I wanted to make sure I understood it correctly since I hadn't encountered this on other Linux systems.
  9. I'm trying to understand the role of zram and having some difficulties with it. I've looked in several places and my understanding is this: - It's a block device in RAM that uses compression - It functions similar to swap I notice that mine is set to about 2 Gb: wurmfood@helios64:~$ cat /proc/swaps Filename Type Size Used Priority /dev/zram0 partition 1945084 0 5 My questions: 1. Does that mean 2 Gb of the device RAM is used for the z
  10. Ah! Sorry, yes, you're right. I've been looking at these back and forth for the last few days. A lot of people here have been having trouble with WD drives and at least some of that seems to come down to the difference between the two types of drives.
  11. One note: It looks like you have CMR drives from WD in there. Those are known to have a variety of problems and may be contributing to the issues you're seeing.
  12. Taking a look around, this definitely seems to be the case: https://www.truenas.com/community/threads/warning-wd-red-wd60efrx-68l0bn1.58676/ Additionally, people see a lot more errors with the *EFAX drives instead of the *EFRX, since the *EFAX drives are CMR and don't hold up.
  13. I do. My system has been rock solid and is acting as a media storage device, NFS, and backup server. wurmfood@helios64:~$ uname -a Linux helios64 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux ZFS on 4 Seagate 6 Tb disks plus a 250 Gb M.2 SSD. I haven't had to do any of the governor stuff other people have. The only problems I've run into have to do with remembering to rebuild the ZFS module when I update the kernel. One thing I've noticed is that a number of people having problem seem to be using OMV and
  14. Might help to add to the ZFS page to do something like this when done: for disk in /sys/block/sd[a-e]/queue/scheduler; do echo none > $disk; done (Assuming all 5 disks are using ZFS.)
  15. The problem with copying the file system is the UUIDs of the devices are wrong. This is why dd will actually work (and yes, so will ddrescue) because it copies the disk block by block. That means the new partitions have the same UUID. I know this works because I just did it on my main computer. The backup script above basically copies the file system and then adjusts /etc/fstab to have the correct UUIDs, so it should work.