Jump to content

Gareth Halfacree

  • Posts

    34
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Gareth Halfacree got a reaction from aaditya in No "Install" option in armbian-config - how to upgrade bootloader?   
    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. Like
    Gareth Halfacree 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
  3. Like
    Gareth Halfacree got a reaction from ShadowDance in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    As I can see, which is why I am making sure to move away from Armbian - and I recommend anyone reading this to do the same. It's simply not a project you can rely upon for daily use. For messing around with as a hobbyist, sure, why not. But to actually rely upon? Impossible.
     
    Especially when the founder doesn't understand that bug reports - especially bug reports from beta/nightly users, which have been specifically requested right here in this thread - have value to the project. With an attitude like that, Armbian will never become anything more than a hobbyist's curiosity.
     
    I'll repeat for clarity, so others reading this thread don't misunderstand my meaning: this is going to keep happening. Future updates will continue to break the Helios64, and other devices, and there is nothing you can do about it. Armbian, as Igor says, simply doesn't have the resources to properly test its updates before release, much less actually respond to bug reports. You will not be able to rely on it to keep your Helios64 running and your data safe. If you're happy with that, by all means continue to use it; otherwise, I'd advise looking into alternative software and/or moving to a new NAS altogether.
  4. Like
    Gareth Halfacree got a reaction from ShadowDance in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Oh, I've tried reporting problems. Igor told me (and many, many others) that if I wasn't paying €50 a month to Armbian he wasn't interested, so I stopped.
  5. Like
    Gareth Halfacree got a reaction from Willy Moto in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    If anyone has installed the update but *not* rebooted, it's a quick (temporary) fix:
     
    sudo apt install linux-dtb-current-rockchip64=21.05.4 linux-headers-current-rockchip64=21.05.4 linux-image-current-rockchip64=21.05.4  
  6. Like
    Gareth Halfacree got a reaction from clostro in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Oh, I've tried reporting problems. Igor told me (and many, many others) that if I wasn't paying €50 a month to Armbian he wasn't interested, so I stopped.
  7. Like
    Gareth Halfacree got a reaction from Schroedingers Cat in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    No, the storage is fine - Armbian 21.08.1 is yet another update that hoses something on the Helios64. Last time it was the fans, the time before that the 2.5Gb Ethernet port (twice), and this time it's the eMMC.
     
    You'll need to follow the instructions upthread to downgrade the kernel to get the eMMC working again. Then cross your fingers it gets fixed at some point in the future.
  8. Like
    Gareth Halfacree got a reaction from IcerJo in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    No, the storage is fine - Armbian 21.08.1 is yet another update that hoses something on the Helios64. Last time it was the fans, the time before that the 2.5Gb Ethernet port (twice), and this time it's the eMMC.
     
    You'll need to follow the instructions upthread to downgrade the kernel to get the eMMC working again. Then cross your fingers it gets fixed at some point in the future.
  9. Like
    Gareth Halfacree got a reaction from clostro in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    If anyone has installed the update but *not* rebooted, it's a quick (temporary) fix:
     
    sudo apt install linux-dtb-current-rockchip64=21.05.4 linux-headers-current-rockchip64=21.05.4 linux-image-current-rockchip64=21.05.4  
  10. Like
    Gareth Halfacree got a reaction from TDCroPower in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    If anyone has installed the update but *not* rebooted, it's a quick (temporary) fix:
     
    sudo apt install linux-dtb-current-rockchip64=21.05.4 linux-headers-current-rockchip64=21.05.4 linux-image-current-rockchip64=21.05.4  
  11. Like
    Gareth Halfacree got a reaction from IcerJo in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    If anyone has installed the update but *not* rebooted, it's a quick (temporary) fix:
     
    sudo apt install linux-dtb-current-rockchip64=21.05.4 linux-headers-current-rockchip64=21.05.4 linux-image-current-rockchip64=21.05.4  
  12. Like
    Gareth Halfacree got a reaction from clostro in Feature / Changes requests for future Helios64 board or enclosure revisions   
    The key upgrade for me would be moving away from Armbian to a professional distribution like mainstream Ubuntu or Debian.
  13. Like
    Gareth Halfacree got a reaction from gprovost in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED   
    I'd suggest getting one or more drives, setting them up in a btrfs mirror, dding a bunch of random onto them, and scrubbing. It's possible dding alone will trigger the error, but if it doesn't then scrubbing certainly should.
     
    $ sudo mkfs.btrfs -L testdisks -m raid1 -d raid1 /dev/sdX /dev/sdY /dev/sdZ $ sudo mkdir /media/testdisks $ sudo chown USER /media/testdisks $ sudo mount /dev/sdX /media/testdisks -o user,defaults,noatime,nodiratime,compress=zstd,space_cache $ cd /media/testdisks $ dd if=/dev/urandom of=/media/testdisks/001.testfile bs=10M count=1024 $ for i in {002..100}; do cp /media/testdisks/001.testfile /media/testdisks/$i.testfile; done $ sudo btrfs scrub start -Bd /media/testdisks  
    The options on the mount are set to mimic my own. Obviously change the number and name of the devices and the username to match your own. It's also set to create 100 files of 10GB each for a total of 1TB of data; you could try with 10 files for 100GB total first to speed things up, but I've around a terabyte of data on my system so figured it was worth matching the real-world scenario as closely as possible.
  14. Like
    Gareth Halfacree got a reaction from Alexander Eiblinger in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED   
    It's the first of the month, so another automated btrfs scrub took place - and again triggered a bunch of DRDY drive resets on ata2.00. Are we any closer to figuring out what the problem is, here?
  15. Like
    Gareth Halfacree reacted to clostro in Feature / Changes requests for future Helios64 board or enclosure revisions   
    @Gareth Halfacree If you would be interested in FreeBSD, @SleepWalker was experimenting with it some time ago. Maybe still is.
     
  16. Like
    Gareth Halfacree reacted to gprovost in No "Install" option in armbian-config - how to upgrade bootloader?   
    Ok here the dirty way to update it in your specific case where eMMC is at /dev/mmcblk1
     
     
    We will work on nand-sata-install to support the use case of rootfs on HDD/SSD and bootloader on eMMC.
  17. Like
    Gareth Halfacree got a reaction from allen--smithee 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.
     
  18. Like
    Gareth Halfacree got a reaction from wurmfood 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.
     
  19. Like
    Gareth Halfacree got a reaction from TRS-80 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.
     
  20. Like
    Gareth Halfacree got a reaction from clostro 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.
     
  21. Like
    Gareth Halfacree got a reaction from Koen Vervloesem 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.
     
  22. Like
    Gareth Halfacree reacted to FloBaoti in [SOLVED] Helios64 won't boot after latest update   
    Here is mine (not yet upgraded) :
     
     
    Maybe problem could be on rootdev UUID ? For me it refers to /dev/mmcblk1p1
×
×
  • Create New...