Jump to content

wurmfood

Members
  • Posts

    36
  • Joined

  • Last visited

Reputation Activity

  1. Like
    wurmfood got a reaction from 0x349850341010010101010100 in Migrate from ramlog to disk   
    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. Like
    wurmfood got a reaction from digwer in Summary of troubleshooting items   
    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?
  3. Like
    wurmfood got a reaction from digwer in Summary of troubleshooting items   
    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. Like
    wurmfood got a reaction from SIGSEGV in Summary of troubleshooting items   
    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?
  5. Like
    wurmfood got a reaction from clostro in Summary of troubleshooting items   
    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?
  6. Like
    wurmfood got a reaction from hartraft in Summary of troubleshooting items   
    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. Like
    wurmfood got a reaction from aegiap in Migrate from ramlog to disk   
    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
  8. Like
    wurmfood got a reaction from gprovost in Kobol Team is taking a short Break !   
    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. Like
    wurmfood got a reaction from hartraft in Kobol Team is taking a short Break !   
    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.
  10. Like
    wurmfood reacted to Igor in Kobol Team is taking a short Break !   
    ... because hardware wants to provide a working solution instead of piloting brand new SoC that might have unusable software support for years to come. We all will be frustrated, tensted, sales will go down ... WHY? 
     
    It is hard to predict more without deep investigation, but users / buyers expect top notch SW support and are willing to pay nothing for that. But someone has to pay that bill. Costs of software support is enormous, much bigger than HW design and that fact doesn't allow such products to happen. That is certainly not fault of a few people that tries to create a wonderful new hardware or folks that supports users on a voluntary basis.

    Even with reasonable well supported many years old RK3399 problems are still present in greater way we all would like.
     
     
    Wish you fast recovery. I also need that 
  11. Like
    wurmfood got a reaction from aegiap in UPS service and timer   
    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  
  12. Like
    wurmfood got a reaction from SIGSEGV in UPS service and timer   
    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  
  13. Like
    wurmfood reacted to aprayoga in UPS service and timer   
    @SIGSEGV @clostro the service is triggered by udev rules.
     
    @wurmfood, I didn't realize the timer fill the the log every 20s. Initial idea was one time timer, poweroff after 10m of power loss event. Then it was improved to add polling of the battery level and poweroff when threshold reached. Your script look good, we are considering to adapt it to official release. Thank you
     
     
  14. Like
    wurmfood got a reaction from clostro in UPS service and timer   
    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  
  15. Like
    wurmfood got a reaction from gprovost in Migrate from ramlog to disk   
    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. Like
    wurmfood got a reaction from clostro in Migrate from ramlog to disk   
    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
  17. Like
    wurmfood reacted to Werner in Migrate from ramlog to disk   
    Actually that is what I would do at first try.
  18. Like
    wurmfood reacted to ebin-dev in Backup method for system installed on SSD (slot1)   
    I am using the following script to backup my root partition to sd (it is just a slightly modified Armbian script - please adapt the device name if necessary):
     
    # cat backuptosd.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount /dev/mmcblk1p1 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude  
    The UUIDs need to be inserted (blkid is your friend) - the leftmost is the one of your root system, the other one is the UUID of the sd in this example.
    If you need a bootable system on sd - the easiest way would be to start with a fresh Armbian image flashed to the sd card and to boot from it at least once in order to expand the filesystem.
    Then you may boot from your main root partition and simply sync it to the sd card using the above script.
     
  19. Like
    wurmfood reacted to Werner in Zram questions   
    Yes.
    Also yes. Armbian by default uses 50% if available memory for zram. If you have a fast harddrive like SSD or NVMe attached it of course makes sense to put a common swap there.
  20. Like
    wurmfood got a reaction from clostro in Does anyone actually have a stable system?   
    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.
  21. Like
    wurmfood got a reaction from SIGSEGV in Crazy instability :(   
    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.)
  22. Like
    wurmfood got a reaction from gprovost in Backup method for system installed on SSD (slot1)   
    Any normal backup solution should work. In general, it sounds like you want to just make an image of the live system. The dd utility will work for this.
     
    dd if=/dev/disk/by-id/[your disk] of=/path/to/zfs/pool/root.img bs=1M status=progress  
    You can adjust the block size based on what you find works well for your system. You can later restore it using exactly the same process, just switching your in-file (if) and out-file (of). Note that file here can include block devices.
  23. Like
    wurmfood reacted to Gareth Halfacree in Encrypted OpenZFS performance   
    Your MicroServer has either an Opteron or Ryzen processor in it, either one of which is considerably more powerful than the Arm-based RK3399.
     
    As a quick test, I ran OpenSSL benchmarks for AES-256-CBC on my Ryzen 2700X desktop, an older N54L MicroServer, and the Helios64, block size 8129 bytes.
     
    Helios64: 68411.39kB/s.
    N54L: 127620.44kB/s.
    Desktop: 211711.31kB/s.
     
    From that, you can see the Helios64 CPU is your bottleneck: 68,411.39kB/s is about 67MB/s, or within shouting distance of your 62MB/s real-world throughput - and that's just encryption, without the LZ4 compression overhead.
     
  24. Like
    wurmfood got a reaction from Igor in Openmediavault & zfs   
    I suggest checking out this post and the solution a little below it, as it sounds like your same problem.
  25. Like
    wurmfood got a reaction from TRS-80 in Openmediavault & zfs   
    I suggest checking out this post and the solution a little below it, as it sounds like your same problem.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines