hartraft

Members
  • Posts

    12
  • Joined

  • Last visited

Reputation Activity

  1. Like
    hartraft reacted to gounthar in What would be the beefiest armv7 platform?   
    I do love the XU4, but it only sports 2GB of RAM.
  2. Like
    hartraft reacted to bunducafe in Does anyone actually have a stable system?   
    I am working with: Linux helios64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux
    I have snapraid configered via the OMV interface but MergerFS and LUKs manually because the plugins were not present at the time but I am not sure if this really does any difference. Beyond that I am using some Dockers like Airsonic, Jellyfin, Nextcloud.
    And the ondemand governor is now between 400-1800MHz and runs all the tasks (Snapraid + rsync + smart on a weekly basis) smoothly. My current uptime now is 21 days.
  3. Like
    hartraft reacted to IcerJo in Does anyone actually have a stable system?   
    Mind if I ask which kernel are you using? and did you experience any problems adding any addon's? I had no problems with a fresh install of Bullseye on my Helios4 but had issues when I tried adding snapraid and mergerfs on my Helios64 with the stock Bullseye Kernel.
     
    Also Experiencing a freeze/issue When installing OMV through armbian-config where it freezes at the end while processing triggers for man-db
  4. Like
    hartraft reacted to bunducafe in Does anyone actually have a stable system?   
    Since 4 weeks now I am runnign the helios64 together with OpenMediavault 6 with the full CPU capacity and ondemand governor.
    Before I had always problems when doing an scheduled task but with OMV6 the problem seems to be solved. I am quite pleased now with the performance and a rocksolid NAS.
     
  5. Like
    hartraft reacted to manman in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED   
    UPDATE:
    Even changing the cables, the disks keep failing over time. I wasn't able to have my NAS running more than a day or two without a failure on the disks. After buying an APC UPS with Boost and Trim Automatic Voltage Regulation (AVR), my NAS is now running without any failure over more than a week!
    So the problem was the unstable energy in my house. Maybe I'll try to put back the original ones to see if it works.
  6. Like
    hartraft reacted to bunducafe in OpenMediaVault 6 on Bullseye   
    Go ahead, OMV6 works fairly well with the Helios64... there are some bits and pieces that are not completely ported (plugins for example) and some need a bit of adjustment whatsoever. But all in all it is okay.
     
    I am running OMV6 together with SnapRaid. MergerFS and Luks I am running outside of OMV as I do find it easier to customize for my needs.
  7. Like
    hartraft reacted to robrob in Helios64 network bonding   
    I have been trying for a while now the edge kernels and I have found that after the HW-mod (above) the network bonding has started to work... not consistently but once setup, the next reboot will actually enable the full network bonding. Currently I'm running 5.15.4, had to rebuild ZFS but that was it.

    Packages I've upgraded:
    - linux-dtb-edge-rockchip64/focal 21.11.0-trunk.65 arm64
    - linux-headers-edge-rockchip64/focal 21.11.0-trunk.65 arm64
    - linux-image-edge-rockchip64/focal 21.11.0-trunk.65 arm64

    - Package: zfs-dkms
      - Version: 2.1.1-0york0~20.04
      - Priority: optional
      - Section: kernel
      - Source: zfs-linux
     
    $ cat /proc/net/bonding/nm-bond0 Ethernet Channel Bonding Driver: v5.15.4-rockchip64 Bonding Mode: transmit load balancing Primary Slave: None Currently Active Slave: eth1 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Peer Notification Delay (ms): 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 64:62:66:xx:xx:xx Slave queue ID: 0 Slave Interface: eth0 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 64:62:66:xx:xx:xx Slave queue ID: 0  
  8. Like
    hartraft reacted to alchemist in vanilla kernel 5.15 and fancontrol   
    Hi,
     
    I thought this forum did support on the Helios{4,64} regardless of the OS since Kobol is now closed.
    More, the issues I encounter testing the Armbian patches can be helpful for the future Armbian releases (I had the eMMC issues long time before many Armbian users were impacted with the Buster update).
    I did tried to apply the Armbian patches for kernel 5.15, but they fail because Helios4 and 64 are now mainlined.
     
    But not problem, I will try to fix it by myself, and report back the solution here. I have the skills to do it.
    BTW I have the same issue with vanilla kernel 5.15 and Helios4. I will test it first on the helios4 because it's not used anymore.
     
    Kind regards,
    Xavier Miller
  9. Like
    hartraft reacted to NickS in Network activity LED no longer works   
    Hi jotapesse, yes same for me ... but on closer inspection ... the flashing of the LAN activity light no longer seems
    to be tied to real network activity!
     
    1/ It flashes a lot less than it used to do.
    2/ If I download a large movie file from the Helios64 to my PC I occasionally see a brief flash, but not the sustained activity that
    I'd expect from a download that takes several minutes.
    3/ Inspecting my network router, I can see constant low level activity on the Helios64 ip address (I only have one ethernet cable attached to the Helios64)
    but don't see any flashing LED.
     
    So in conclusion ... its still not working properly!  
  10. Like
    hartraft reacted to jotapesse in Network activity LED no longer works   
    Hi everyone! Just to let you all know that I have updated today my Helios64 to Armbian 21.08.3 Bullseye and the "LAN" front panel led now works again. :-) Great!
  11. Like
    hartraft reacted to balbes150 in Board Bring Up Station P1 rk3399, M1 rk3328   
    New version 20211007-edge with 5.14.9 core. All equipment works, including analog sound and remote control.
     
    @JMCC
    I checked the operation of your KODI-18 packages on this kernel, KODI starts, but there is still an error and the video does not play, maybe I forgot some kernel options or a patch. I plan to check it again in the near future.
  12. Like
    hartraft reacted to prahal in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    bisected eMMC breakage:
    06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 is the first bad commit
     
    commit 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Date: Thu May 20 01:12:23 2021 +0300 regulator: core: resolve supply for boot-on/always-on regulators commit 98e48cd9283dbac0e1445ee780889f10b3d1db6a upstream. For the boot-on/always-on regulators the set_machine_constrainst() is called before resolving rdev->supply. Thus the code would try to enable rdev before enabling supplying regulator. Enforce resolving supply regulator before enabling rdev. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210519221224.2868496-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> drivers/regulator/core.c | 6 ++++++ 1 file changed, 6 insertions(+)  
    is https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/regulator/core.c?id=98e48cd9283dbac0e1445ee780889f10b3d1db6a
    from thread https://lore.kernel.org/all/20210519221224.2868496-1-dmitry.baryshkov@linaro.org/
     
    diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 7b3de8b0b1ca..043b5f63b94a 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1422,6 +1422,12 @@ static int set_machine_constraints(struct regulator_dev *rdev) * and we have control then make sure it is enabled. */ if (rdev->constraints->always_on || rdev->constraints->boot_on) { + /* If we want to enable this regulator, make sure that we know + * the supplying regulator. + */ + if (rdev->supply_name && !rdev->supply) + return -EPROBE_DEFER; + if (rdev->supply) { ret = regulator_enable(rdev->supply); if (ret < 0) {  
    EDIT 1: this change to return EPROBE_DEFER if regulator has a supply name but no supply ready was intended to complete commit aea6cb99703e17019e025aa71643b4d3e0a24413 which  expects set_machine_constraints to return this eprobe_defer error to attempt to resolve the supply ( before attempting a second run of set_machine_constraints).
     
    One still need to find out if aea6cb99703e17019e025aa71643b4d3e0a24413 fails to resolve the supply and thus does not make a second attempt to set_machine_constraints thus leaves the regulator disabled or else.
     
     
    commit aea6cb99703e17019e025aa71643b4d3e0a24413 Author: Micha? Miros?aw <mirq-linux@rere.qmqm.pl> Date: Sat Sep 26 23:32:41 2020 +0200 regulator: resolve supply after creating regulator When creating a new regulator its supply cannot create the sysfs link because the device is not yet published. Remove early supply resolving since it will be done later anyway. This makes the following error disappear and the symlinks get created instead. DCDC_REG1: supplied by VSYS VSYS: could not add device link regulator.3 err -2 Note: It doesn't fix the problem for bypassed regulators, though. Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators") Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index ff8e99ca0306..9f704a6c4802 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5280,15 +5280,20 @@ regulator_register(const struct regulator_desc *regulator_desc, else if (regulator_desc->supply_name) rdev->supply_name = regulator_desc->supply_name; - /* - * Attempt to resolve the regulator supply, if specified, - * but don't return an error if we fail because we will try - * to resolve it again later as more regulators are added. - */ - if (regulator_resolve_supply(rdev)) - rdev_dbg(rdev, "unable to resolve supply\n"); - ret = set_machine_constraints(rdev, constraints); + if (ret == -EPROBE_DEFER) { + /* Regulator might be in bypass mode and so needs its supply + * to set the constraints */ + /* FIXME: this currently triggers a chicken-and-egg problem + * when creating -SUPPLY symlink in sysfs to a regulator + * that is just being created */ + ret = regulator_resolve_supply(rdev); + if (!ret) + ret = set_machine_constraints(rdev, constraints); + else + rdev_dbg(rdev, "unable to resolve supply early: %pe\n", + ERR_PTR(ret)); + } if (ret < 0) goto wash;  
     
     
    My logs for bad shows:
    [ 1.257297] reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517 [ 1.257446] reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517 [ 1.257588] reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517 [ 1.257728] reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517 [ 1.258114] reg-fixed-voltage pcie-power: Failed to register regulator: -517 [ 1.258312] reg-fixed-voltage vcc3v3-sys-s3: Failed to register regulator: -517 [ 1.258451] reg-fixed-voltage vcc3v0-sd: Failed to register regulator: -517 [ 1.258705] reg-fixed-voltage vcc5v0-usb: Failed to register regulator: -517 [ 1.261721] reg-fixed-voltage usblan-power: Failed to register regulator: -517 [ 2.158719] vdd_log: supplied by regulator-dummy [ 2.230749] rk808-regulator rk808-regulator: there is no dvs0 gpio [ 2.230781] rk808-regulator rk808-regulator: there is no dvs1 gpio [ 2.230792] rk808-regulator rk808-regulator: max buck steps per change: 4 [ 2.240854] rk808 0-001b: failed to register 12 regulator [ 2.249848] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected! [ 2.253127] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected! [ 2.423549] reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517 [ 2.424263] reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517 [ 2.424830] reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517 [ 2.425443] reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517 [ 2.556287] rk808-regulator rk808-regulator: there is no dvs0 gpio [ 2.556318] rk808-regulator rk808-regulator: there is no dvs1 gpio [ 2.556328] rk808-regulator rk808-regulator: max buck steps per change: 4  
    while for good:
    [ 2.172993] vdd_log: supplied by regulator-dummy [ 2.330040] rk808-regulator rk808-regulator: there is no dvs0 gpio [ 2.330071] rk808-regulator rk808-regulator: there is no dvs1 gpio [ 2.330081] rk808-regulator rk808-regulator: max buck steps per change: 4 [ 2.347345] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected! [ 2.350525] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected!
  13. Like
    hartraft reacted to lanefu in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    I have slightly different approach to going's solution, but this would be compatible with it
     
     
  14. Like
    hartraft reacted to ebin-dev in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    @piter75 commited the emmc fix into Armbian and built Armbian 21.08.2 which is already available through the Armbian mirrors (via 'apt update && apt upgrade').
     
    It is save to upgrade your Buster or Bullseye installation to Armbian 21.08.2 - but emmc read speed will be about 50% what it used to be.
     
    You can roll back to the previous linux 5.10.43 kernel if you don't like that - just install those files with 'dpkg -i *.deb'.
     
  15. Like
    hartraft reacted to ebin-dev in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Really ?
    If you are on macOS Big Sur all the drivers and apps are already there. If you need to access the serial console of your Helios64, just connect your mac to the USB-C port of your Helios64. A device such as  /dev/tty.usbserial-XXXXXXXX will be recognised by macOS. All you need to do then is to enter the following into the Terminal of your mac (X to be replaced):
     
    screen /dev/tty.usbserial-XXXXXXXX 1500000 -L  
    Edit: If the 'screen' command on macOS does not show the output of the bootloader (scrambled characters) you could use the app serial. The only thing you need to configure is to set the serial speed manually to 1500000 bps.
     
    If someone would like to contribute in kernel testing - the Armbian build system is very easy to install and use. All you need is an Ubuntu 21.04 (amd64) installation. All the rest is explained here. To compile your own kernel is then as simple as this:
    ./compile.sh BOARD=helios64 BRANCH=current KERNEL_ONLY=yes RELEASE=bullseye  
  16. Like
    hartraft reacted to piter75 in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Armbian "current" (5.10.y) compiles without issues.
    I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
    I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
     
    However I did find that with the unit I have the issue happens only in hs400{,es} modes.
    With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
     
    If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
    Upgrade the kernel to 5.10.60, but don't reboot yet.
    Run:
    curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
    If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
    There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
    Below you can find the comparison between hs400 and hs200 modes using iozone.
     
  17. Like
    hartraft reacted to aprayoga in Kobol Team is pulling the plug ;(   
    Hi everyone, thank you for all of your support.
    I'll be still around but not in full time as before.
     
    I saw Helios64 has several issues in this new release. I will start looking into it.
  18. Like
    hartraft got a reaction from calvin_thefreak in Feature / Changes requests for future Helios64 board or enclosure revisions   
    Like everyone I'm sad for the news. While the reality is difficult, in the end Kobol still achieved a great job in delivering the product in these circumstances. Considering how many kickstarters fail and have vapourware products. My only hope is that this will inspire a future aarch64 NAS whether it's by Kobol or another manufacturer. 
     
    Would it be possible for the Kobol team to share the 3D print files for the drive trays? So that if some need repair we can fix this ourselves? 
  19. Like
    hartraft reacted to barnumbirr in Does anyone actually have a stable system?   
    I've had a secondary device connected to my Helios64 over serial for the last couple of months. Unfortunately, even at verbosity 7 it dies so suddenly that the output doesn't actually provide any valuable information:

     
    Starting kernel ... [ 2.721938] cacheinfo: Unable to detect cache hierarchy for CPU 0 [ 2.881028] vcc3v3_sys_s0: failed to get the current voltage: -EPROBE_DEFER [ 2.900490] dw_wdt ff848000.watchdog: No valid TOPs array specified [ 3.012992] dwmmc_rockchip fe320000.mmc: All phases bad! [ 3.013479] mmc1: tuning execution failed: -5 [ 3.013881] mmc1: error -5 whilst initialising SD card [ 3.135010] dwmmc_rockchip fe320000.mmc: All phases bad! [ 3.135502] mmc1: tuning execution failed: -5 [ 12.521811] rk_gmac-dwmac fe300000.ethernet: cannot get clock clk_mac_speed [ 15.212309] dw-apb-uart ff1a0000.serial: forbid DMA for kernel console [ 17.035708] lm75 2-004c: supply vs not found, using dummy regulator [ 18.572536] rk_gmac-dwmac fe300000.ethernet eth0: PTP not supported by HW [ 18.817621] OF: graph: no port node found in /i2c@ff3d0000/typec-portc@22 [ 18.833386] OF: graph: no port node found in /syscon@ff770000/usb2-phy@e450/otg-port [ 19.262970] [drm] unsupported AFBC format[3231564e] [ 19.366283] rockchip_vdec: module is from the staging directory, the quality is unknown, you have been warned. [ 19.410603] r8152 4-1.4:1.0 (unnamed net_device) (uninitialized): netif_napi_add() called with weight 256 [ 19.421732] hantro_vpu: module is from the staging directory, the quality is unknown, you have been warned. [ 24.903650] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 helios64 login: DDR Version 1.24 20191016 In soft reset SRX channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 This is what my uptime looks like over the last 90 days. Again, none of the reboots were triggered by me.


     
    Reboots wouldn't be such a pain the backside on their own if 90% of them didn't retrigger a mdadm RAID resync...
  20. Like
    hartraft reacted to wurmfood 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?
  21. Like
    hartraft reacted to griefman in Failing to Boot   
    So, 
    after struggling for quite some time i finally was able to get things back to normal without losing data (at least i think so).
     
    The problem was apparently a broken kernel upgrade to version 5.10.43 . There were broken symlinks and not only. 
     
    In the end what solved it was the following:
    I first put the latest stable armbian on an sd card and booted with it. then i actually upgraded that image to the latest kernel and copied all version related files from /boot of the sd card to the /boot of the mmc. I also copied the 5.10.45 modules from /lib/module from the sd card to the mmc.
    Fixed all symlinks in /boot and then the device finally booted. After that it was all about reinstalling kernel headers, cleaning up wrong zfs versions and packages and rebooting frequently enough in between
     
    Hope that i didnt break too much and that this helps someone.
  22. Like
    hartraft reacted to djurny in ArmbianEnv.txt file being overwritten   
    Hi,
    You can try the following to get an idea of which process is modifying the file:
     
    sudo apt-get install auditd sudo auditctl -w /boot/armbianEnv.txt -p wa sudo tail -F /var/log/audit/audit.log  
    The output should show actions performed on the file and (IIRC) the process ID performing those actions, perhaps that might help?
     
    e.g.:
    type=CWD msg=audit(1624526184.097:207): cwd="/home/djurny" type=PATH msg=audit(1624526184.097:207): item=0 name="/boot/" inode=7601 dev=b3:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1624526184.097:207): item=1 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.097:207): proctitle=xx type=SYSCALL msg=audit(1624526184.109:208): arch=40000028 syscall=94 per=800000 success=yes exit=0 a0=3 a1=81a4 a2=c80eeb00 a3=81a4 items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=PATH msg=audit(1624526184.109:208): item=0 name=(null) inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:208): proctitle=xx type=SYSCALL msg=audit(1624526184.109:209): arch=40000028 syscall=226 per=800000 success=yes exit=0 a0=1787820 a1=b6e3e1a0 a2=1907fc0 a3=1c items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=CWD msg=audit(1624526184.109:209): cwd="/home/djurny" type=PATH msg=audit(1624526184.109:209): item=0 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:209): proctitle=xx  
    Source: Find which process is modifying a file [duplicate]
     
    It honestly sounds a bit more like a filesystem that has lost track or a inode mixup somewhere? As someone mentioned, perhaps something else is writing to this file, thinking it is something else? Perhaps try to locate a symbolic (or hard)link to armbanEnv.txt:
    ## find any symbolic links to armbianEnv.txt sudo find / -xdev -type l -ls | egrep -i -- armbianEnv.txt ## find hardlinks to armbianEnv.txt - need to be on the same filesystem! sudo find / -xdev -samefile /boot/armbianEnv.txt  
    Groetjes,
  23. Like
    hartraft reacted to Polarisgeek in ArmbianEnv.txt file being overwritten   
    I've been having a recent issue over the last couple months where my ArmbianEvn.txt file is being overwritten thus causing Helios to hang in the boot process.  Using some samples i've found on these forums, I was able to re-create my file and get the Helios back up and running and have since stored a copy so that when it happens, I can just copy and paste and back up running in no time.  To date, i've had this happen to me 4 times.
     
    I'm not worried about having go through this at this point in time, but I was curious if anyone else has seen this issue or not?  I've saved a couple samples of what was written into the ArmbianEnv.txt file:
    /var/log/armbian-hardware-monitor.log {
      rotate 12
      weekly
      compress
      missi
     
    /var/log/alternatives.log {
    monthly
    rotate 12
    compress
    delaycompress
    missingok
    notifempty
    create 644 root root
    }
     
    I'm running Buster 5.10.21.  I have 5-14TB EXOS drives in Raid 6 and have OMV as the only thing installed.  
  24. Like
    hartraft reacted to SIGSEGV in We want YOU for armbian   
    Hello @Igor, @Werner,
    I'm open to collaborating to the armbian project, my background is on software development and system administration and I have a small Helios64 to test things with.
  25. Like
    hartraft reacted to Heisath in eMMc drive filled to 90% overnight and no idea why.   
    might need to do 
    sudo ncdu -x /  
    Then you can navigate through a tree-view, and figure out where the size comes from. 
     
    As a general step-by-step guide:
    - use "df -h" (or something like that), to figure out which device / mountpoint is getting full
    user@builder:~$ df -h Filesystem Size Used Avail Use% Mounted on tmpfs 1,6G 1,2M 1,6G 1% /run /dev/sda3 79G 31G 44G 41% / tmpfs 7,9G 0 7,9G 0% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 4,0M 0 4,0M 0% /sys/fs/cgroup /dev/sda2 94M 5,2M 89M 6% /boot/efi tmpfs 1,6G 136K 1,6G 1% /run/user/1000 We now know, /dev/sda3 is fullest, and is mounted on /
     
    - next use "sudo ncdu -x /" to check the contents / where the space goes:
    ncdu 1.15.1 ~ Use the arrow keys to navigate, press ? for help --- / -------------------------------------------------------------------------- 17,2 GiB [##########] /home 8,5 GiB [#### ] /usr 2,0 GiB [# ] swapfile 1,0 GiB [ ] /var 760,0 MiB [ ] /root 508,4 MiB [ ] /opt 251,1 MiB [ ] /boot 11,6 MiB [ ] /etc 68,0 KiB [ ] /tmp 36,0 KiB [ ] /snap e 16,0 KiB [ ] /lost+found 8,0 KiB [ ] /media e 4,0 KiB [ ] /srv e 4,0 KiB [ ] /mnt e 4,0 KiB [ ] /cdrom @ 0,0 B [ ] libx32 @ 0,0 B [ ] lib64 @ 0,0 B [ ] lib32 @ 0,0 B [ ] sbin @ 0,0 B [ ] lib @ 0,0 B [ ] bin Total disk usage: 30,1 GiB Apparent size: 28,8 GiB Items: 789697 We see that most storage goes to /home, /usr and the swapfile.
     
    As the interface is interactive, you can just navigate down the folder structure to find the culprit.