wurmfood

  • Posts

    36
  • Joined

  • Last visited

Everything posted by wurmfood

  1. Sorry, the line about disabling was just to make sure you disable the armbian-zram-config service by setting ENABLED to false. As a warning, though, I found some problems with this if you log to a zfs share. It seems you have to make sure zfs gets loaded before the logging starts up, otherwise you can get a kernel panic on occasion. I didn't really dig into how to fix this, so I just log and swap to a usb drive instead now.
  2. That certainly could be added. I think the assumption was that as long as people were following the directions it would be fine. Otherwise, since the rule is that air exhausts on the side of the fan with the motor, it's clear from the picture that air would be pushed out the back of the case.
  3. Yup, fixed. Thank you. It may be the default and non-changeable, but it's a suggestion that has been put in from the Kobol team, which is why I included it.
  4. They apply to a variety of problems, but the CPU/voltage throttling can help with random freezes/reboots and the extraargs bit can help with errors accessing drives.
  5. You can set up logging to go to a flash drive, but capturing the console is going to be the best bet. Do you have another computer you can leave on with the serial console connected? For example, I have a small NUC where I keep picocom running in a tmux session, that way I don't lose anything. You can use the -g option to have picocom log to a file, as well.
  6. There are a number of modifications that have been suggested that people implement to address certain issues. The ones I can find are: - In /boot/armbianEnv.txt: extraargs=libata.force=3.0 - If doing debugging, also add: verbosity=7 console=serial extraargs=earlyprintk ignore_loglevel - In /boot/boot.cmd regulator dev vdd_log regulator value 930000 regulator dev vdd_center regulator value 950000 and then run: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr - In /etc/default/cpufrequtils: ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand (or 1200000 instead of 1800000) - And if using ZFS: for disk in /sys/block/sd[a-e]/queue/scheduler; do echo none > $disk; done I've gathered these from a variety of threads. Am I missing any here?
  7. After a recent update to non-kernel stuff, my Helios64 will no longer boot. When attempting to, I get this error: [ 32.425508] xhci-hcd xhci-hcd.3.auto: Host halt failed, -110 [ 35.019496] xhci-hcd xhci-hcd.3.auto: Host halt failed, -110 [ 35.020028] xhci-hcd xhci-hcd.3.auto: Host controller not halted, aborting reset. I had been using the eMMC on board to boot with the SD card as a backup, but now neither one is working. Anyone know if there's a way to fix this? Here's more, using verbosity=4 in the armbianEnv.txt.
  8. Enjoy your well deserved break. It's been a rough year for all of us, but I will saying that getting my Helios64 set up and running has been a welcome diversion and bright spot during this time. Thanks all and I can't wait to see what comes next.
  9. It's showing it boot completely. There's a login prompt there on the console. Why it's showing the extra characters, I'm not sure. My picocom configuration matches yours and I don't see that. What's interesting is you've got the SysRq coming up when, I believe, that's normally only triggered by a key combination. I wonder if something is causing extra characters to be sent over the serial console that's causing the problem.
  10. 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/gpio-charger/online') # Only use for testing: # main_power=0 if [ "$main_power" == 0 ]; then val=$(cat '/sys/bus/iio/devices/iio:device0/in_voltage2_raw') sca=$(cat '/sys/bus/iio/devices/iio:device0/in_voltage_scale') # The division is required to make the test later work. adc=$(echo "$val * $sca /1" | bc) echo "Main power lost. Current charge: $adc" | systemd-cat -p $warnlevel echo "Shutdown at $TH" | systemd-cat -p $warnlevel # Uncomment for testing # echo "Current values:" # echo -e "\tMain Power = $main_power" # echo -e "\tRaw Voltage = $val" # echo -e "\tVoltage Scale = $sca" # echo -e "\tVoltage = $adc" if [ "$adc" -le $TH ]; then echo "Critical power level reached. Powering off." | systemd-cat -p $warnlevel /usr/sbin/poweroff fi fi sleep 20 done
  11. 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.
  12. 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.
  13. @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.
  14. 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.
  15. 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
  16. 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.
  17. Thank you. I wanted to make sure I understood it correctly since I hadn't encountered this on other Linux systems.
  18. 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 zram swap device? 2. I can understand this on devices with slower storage, but would it be reasonable to disable this and instead use swap on an SSD?
  19. 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.
  20. 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.
  21. 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.
  22. 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 I'm not.
  23. 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.)
  24. 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.
  25. I believe it's not enabled by default. You have to choose to set it. At least, none of my pools have been created with it and I never specified not to. As a side note, I doubled checked my compression on all of my datasets and I noticed that some of my docker data sees massive compression with zstd on. Most are in the 1-3x range, but I have several in the 8-9x range.