Gareth Halfacree

  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

Gareth Halfacree's Achievements

  1. 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.
  2. 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?
  3. I am calm. What I am not is accepting of abuse.
  4. So you choose to attack and abuse... because it'll attract developers? Are you sure about that logic? I can tell you now, I'll certainly not be getting involved in the project's development. Nor will I recommend anyone else to do so. First, politeness takes no more time than being abusive. Second, I literally want none of your time. I did not call you into this thread. I did not send you a private message. I did not send you an email, an instant messenger, find you on IRC... I posted a message to Kobol, on the Kobol sub-forum, which is maintained by Kobol for the support of Kobol customers. You went out of your way to visit the Kobol sub-forum, find my post, and berate me for something I haven't done. Like I said, if you spent less time doing things like that and more time bug-fixing, maybe the bills would be lower and Armbian more usable. I very much do, yes. I've created open-source projects, documented open-source projects, maintained open-source projects, donated to open-source projects, and have used nothing but open-source software for two decades. Projects both bigger and smaller than Armbian. But you wouldn't know that, because you made an assumption in the thread you specifically sought out. Please leave me alone. This is bordering on harassment now.
  5. For anyone visiting from Twitter and wondering what the fuss is about, you can find the split thread here.
  6. And yet you seem very keen to make it your business. Even when your input is clearly unwelcome. I wonder how much of the claimed €2,000 a day running costs could be reduced if you didn't spend your time writing posts about how you have no time to fix bugs? Nothing to do with intimidation, everything to do with ensuring people know what to expect - and what they can expect is an absolute inability to request support with something that's clearly broken without being attacked by you. It's literally my job to warn people about things like that. I don't want support from you. I'd be happy if you never spoke to me again. I would like support from Kobol. On this, the Kobol forum. Linked from the Kobol website. For the purpose of customer support. @gprovost Is this really the project you want to tie your company to?
  7. The key upgrade for me would be moving away from Armbian to a professional distribution like mainstream Ubuntu or Debian.
  8. No, I was not: I was asking the vendor of the network attached storage device I paid for if there was a convenient way of upgrading its bootloader. Your input was neither requested nor desired. Perhaps this is a language barrier thing, so allow me to be clear: you are being extremely hostile. When people post on this specific sub-forum, it's with the expectation they're engaging in a professional discourse with the people who support the device they paid for - i.e. Kobol. They are not attacking you personally, nor the Armbian project: they, like I, simply want to get the device they paid for to work as promised. Jumping down their throat claiming that "we owe you nothing" and demanding additional payment on top of the device cost is hostile. I'm a technology journalist, and I've already published two reviews of the Helios64 and Armbian on the Helios64. Given your attitude, I will be updating those reviews to warn that unless you're willing to either write the code yourself or contribute to Armbian's - absolutely ridiculous, from your claims - running costs you will not be able to seek assistance with the software - even from Kobol itself - without being attacked. I will further recommend that readers avoid the Armbian project as a whole, and any device which relies upon it. I feel that you've lost sight of the goals of your project: what is an operating system without its users?
  9. @gprovost Thanks, I really appreciate it. The commands ran without error, though I won't truly know if it's worked until the next reboot!
  10. @Igor I've seen you post the same copy-and-paste message to others, and I remain as unimpressed now as the first time I saw it. I'm not asking you, nor Armbian, for support, here: I'm asking Kobol, to whom I have paid money for a commercial product with support, to assist me. If you want to help me, feel free; if not, kindly leave Kobol and its appointed representatives to the task. I'll be honest: if I'd know about your user-hostile attitude before pre-ordering the Helios64, I wouldn't have ordered it at all - I'd have bought something that ran plain-Jane Ubuntu instead. It's certainly put me off using Armbian in the future, and I'm only still here because I don't want the money I've spent on the Helios64 to be wasted. @gprovost Thanks for offering your assistance. Here's the output: Everything should be pretty standard, except I increased the zram log partition size because I have a server running which generates quite a lot of log data over time.
  11. Unfortunately, that doesn't work either - and may provide a hint as to why there's no option to install from armbian-config. If I run nand-sata-install, I get a message reading "This tool must be run from SD-card!" - which, of course, it's not, it's being run from the SATA SSD. Is there a way to update the bootloader without taking the system down, booting from an SD card, updating the bootloader, removing the SD card, and rebooting back into the installed operating system again? Because that's a bit of a slog, especially if the bootloader's going to need regular updates...
  12. 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?
  13. 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.
  14. 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?