Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

  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. wurmfood

    Failing to Boot

    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
  • Create New...