Gareth Halfacree

  • Posts

  • Joined

  • Last visited

 Content Type 


Member Map




Posts posted by Gareth Halfacree

  1. My Helios64 has been booting from an M.2 drive since I got it, and while I've been doing regular apt-upgrades I've been ignoring the bootloader. This post suggests that could be a problem, so I figured I'd upgrade the bootloader through armbian-config. Trouble is, I can't.


    I can load armbian-config without error, but when I go into System there's no Install option any more. All I have are Freeze, Nightly, Lowlevel, Bootenv, CPU, Avahi, Hardware, Other, SSH, Firmware, ZSH, Default.


    Is there another way to ensure the bootloader is up-to-date?

  2. 1 hour ago, Koen Vervloesem said:

    Does anyone have the same experience of this low encrypted ZFS performance on the Helios64? Is this because of the encryption? Looking at the output of top during the benchmark, the CPU seems to be taxed much, while on the HPE machine CPU usage is much less.


    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.


  3. 1 hour ago, Eric Poscher-Mika said:

    What kind of private data could a drive UUID disclose?

    The UUID itself is a universally unique identifier - that's what UUID means, after all. There are a wide range of scenarios where public knowledge of the UUID could be a problem, all absolutely vanishingly unlikely - think things like "state-level actors falsifying evidence about what data they found on a system and using their knowledge of the drive's UUID as 'proof' that the evidence was legitimately collected instead of just made up from whole cloth."


    Given it takes a whopping four seconds to elide the UUID, and absence of the UUID has zero impact on diagnosing the problem, why wouldn't I keep it private?


    Back on topic: I still haven't rebooted since the update. Would I be safe to do so, or shall I keep on truckin' until we're closer to figuring out the root cause of the issue?

  4. Thanks, @FloBaoti - my post-upgrade one looks like this:




    The drive UUID, elided for privacy, refers to /dev/sda1 - which is the SATA SSD I've got the operating system installed on, with /dev/mmcblk1p1 being on a UUID starting b72a980c. In other words, everything looks fine - though I'm still hanging fire on a reboot to check that fact!

  5. I'm seeing the same on my Helios64, on ata2.00 - a bunch on Monday January 4th, then even more on Thursday January 14th. None since.


    ata2.00 is a Western Digital Red Plus 6TB, purchased new for the Helios64. It's in a mirror with a 6TB Seagate IronWolf; the only other drive in the system is a 240GB M.2 SSD on the mainboard. The drive has completed SMART tests without errors, and the only thing of interest in the SMART attributes is 199 UDMA CRC Error Count at 5. The hard drives are in bays 2 & 4; 1, 3, and 5 are empty.


    Board serial number is 000100001123, running Ubuntu 20.04.1 LTS 5.9.14-rockchip64.

  6. Received my Helios64 and installed Armbian Focal. All seems well for me, except:


    $ lscpu
    Architecture:                    aarch64
    CPU op-mode(s):                  32-bit, 64-bit
    Byte Order:                      Little Endian
    CPU(s):                          6
    On-line CPU(s) list:             0-5
    Thread(s) per core:              1
    Core(s) per socket:              3
    Socket(s):                       2
    NUMA node(s):                    1
    Vendor ID:                       ARM
    Model:                           4
    Model name:                      Cortex-A53
    Stepping:                        r0p4
    CPU max MHz:                     1800.0000
    CPU min MHz:                     408.0000
    BogoMIPS:                        48.00
    NUMA node0 CPU(s):               0-5
    Vulnerability Itlb multihit:     Not affected
    Vulnerability L1tf:              Not affected
    Vulnerability Mds:               Not affected
    Vulnerability Meltdown:          Not affected
    Vulnerability Spec store bypass: Vulnerable
    Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
    Vulnerability Spectre v2:        Vulnerable
    Vulnerability Srbds:             Not affected
    Vulnerability Tsx async abort:   Not affected
    Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid


    Are there mitigations in the works for those speculative store bypass and SPECTRE v2 vulnerabilities?


    Also, is there any way to monitor the UPS battery's charge status? I've found gpio-charger/status, which gives me "Not charging" when it's fully topped up and "Charging" when it's charging or (confusingly) discharging, but I can't find anything else of use in there.