aprayoga

  • Content Count

    135
  • Joined

  • Last visited

Reputation Activity

  1. Like
    aprayoga got a reaction from SIGSEGV in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED   
    Hi all, you could download the SATA firmware update at https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_update_00021_200624.img.xz
     
    Instruction:
    1. Download the sd card image
    2. Flash the image into a microSD card
    3. Insert microSD card into Helios64 and power on. Helios64 should automatically boot from microSD. If Helios64 still boot from eMMC, disable the eMMC 
    4. Wait for a while, the system will do a reboot and then power off if firmware flashing succeed.
       If failed, both System Status and System Fault LEDs will blink
    5. Remove the microSD card and boot Helios64 normally. See if there is any improvement.
     
    Our officially supported stock firmware can be downloaded from https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_factory_00020_190702.img.xz. If there is no improvement on newer firmware, please revert back to this stock firmware.
     
    SHA256SUM:
    e5dfbe84f4709a3e2138ffb620f0ee62ecbcc79a8f83692c1c1d7a4361f0d30f *Helios64_SATA_FW_factory_00020_190702.img.xz 0d78fec569dd699fd667acf59ba7b07c420a2865e1bcb8b85b26b61d404998c5 *Helios64_SATA_FW_update_00021_200624.img.xz  
  2. Like
    aprayoga got a reaction from hartraft in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED   
    Hi all, you could download the SATA firmware update at https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_update_00021_200624.img.xz
     
    Instruction:
    1. Download the sd card image
    2. Flash the image into a microSD card
    3. Insert microSD card into Helios64 and power on. Helios64 should automatically boot from microSD. If Helios64 still boot from eMMC, disable the eMMC 
    4. Wait for a while, the system will do a reboot and then power off if firmware flashing succeed.
       If failed, both System Status and System Fault LEDs will blink
    5. Remove the microSD card and boot Helios64 normally. See if there is any improvement.
     
    Our officially supported stock firmware can be downloaded from https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_factory_00020_190702.img.xz. If there is no improvement on newer firmware, please revert back to this stock firmware.
     
    SHA256SUM:
    e5dfbe84f4709a3e2138ffb620f0ee62ecbcc79a8f83692c1c1d7a4361f0d30f *Helios64_SATA_FW_factory_00020_190702.img.xz 0d78fec569dd699fd667acf59ba7b07c420a2865e1bcb8b85b26b61d404998c5 *Helios64_SATA_FW_update_00021_200624.img.xz  
  3. Like
    aprayoga got a reaction from gprovost in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED   
    Hi all, you could download the SATA firmware update at https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_update_00021_200624.img.xz
     
    Instruction:
    1. Download the sd card image
    2. Flash the image into a microSD card
    3. Insert microSD card into Helios64 and power on. Helios64 should automatically boot from microSD. If Helios64 still boot from eMMC, disable the eMMC 
    4. Wait for a while, the system will do a reboot and then power off if firmware flashing succeed.
       If failed, both System Status and System Fault LEDs will blink
    5. Remove the microSD card and boot Helios64 normally. See if there is any improvement.
     
    Our officially supported stock firmware can be downloaded from https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_factory_00020_190702.img.xz. If there is no improvement on newer firmware, please revert back to this stock firmware.
     
    SHA256SUM:
    e5dfbe84f4709a3e2138ffb620f0ee62ecbcc79a8f83692c1c1d7a4361f0d30f *Helios64_SATA_FW_factory_00020_190702.img.xz 0d78fec569dd699fd667acf59ba7b07c420a2865e1bcb8b85b26b61d404998c5 *Helios64_SATA_FW_update_00021_200624.img.xz  
  4. Like
    aprayoga got a reaction from hartraft 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
     
     
  5. Like
    aprayoga got a reaction from clostro 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
     
     
  6. Like
    aprayoga got a reaction from wurmfood 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
     
     
  7. Like
    aprayoga got a reaction from hartraft in RK3399 Legacy Multimedia Framework   
    @JMCC Thanks for the hint. i'll take a look.
  8. Like
    aprayoga reacted to Declan in [Solved] Wireguard Client Up Error: Unknown interface 'tun': No such device   
    I found this thread, https://www.reddit.com/r/WireGuard/comments/m16v3k/unable_to_start_wg_interface_with_wgquick_up/
     
    After removing the DNS field from my config it works.
     
    Hope it helps if anyone else finds the same issue
     
  9. Like
    aprayoga reacted to Heisath in Armbian v21.05 (Jerboa) Release Thread   
    Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
    (let me know if this is a bad date, because it is around easter holiday in Germany for example)
     
    Code Freeze: 2021-04-19 (Monday April 19th)
    Release Date: 2021-05-02 (Sunday May 2nd, estimate)
    Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
    Changelog: <will be added on releae>
    Coordinator: @Heisath
     
    The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
     
    Open topics:
    - complete desktop branch merge into master (this seems generally done, but might need fine tuning)
    - enable 3D support (also done? Bugfixing)
    - discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
    - check if remaining boards can / have been updated to LK5.10 (some were left out last release)
    - check possible u-boot updates
    - complete remaining Jira issues
    - cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
    - late topics: 
    - business meeting schedule
    - kernel config changes on arm64
     
    Release Planning Meeting Agenda:
     
    Please add developers and more topics below, I will then also add them here.
    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali
  10. Like
    aprayoga reacted to ploubi in How can I move the root filesystem manually from sata drive to eMMC   
    Hello,
     
    After I first installed my Helios64, I feared the 16Gb eMMC would be quickly filled.
    So when I used nand-sata-install, I chose to boot from eMMC but to have the root filesystem on a 500Gb sata drive.
     
    I have now second thoughts about it, since I realized that the OS take less than 8Gb, AND I'd like to add a 5th disk to my raid
    Halas nand-sata-install doesn't seem to work on an already moved filsystem.
     
    lsblk show this for the eMMC and the root partition
    peyo@helios64:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465,8G 0 disk └─sda1 8:1 0 465,8G 0 part / ... mmcblk2 179:0 0 14,6G 0 disk └─mmcblk2p1 179:1 0 14,4G 0 part /media/mmcboot  
    And /etc/fstab shows this
     
    UUID=f2d7d6e7-902c-44dc-bdae-aedeb4495385 /media/mmcboot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 /media/mmcboot/boot /boot none bind 0 0 UUID=0fcd9a2c-9a46-4a5e-a0f5-e407bd34e8fb / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 ... And in /media I have this
    peyo@helios64:~$ ll /media/ total 8 drwxr-xr-x 3 root root 4096 déc. 6 11:31 mmcboot drwxr-xr-x 2 root root 4096 déc. 6 11:31 mmcroot  
     
    Would it be so simple as
    1 - rsync all that's on my present / (except for the NFS export and /tmp)?
    2 - changin /etc/fstab to this
    UUID=f2d7d6e7-902c-44dc-bdae-aedeb4495385 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 3 - reboot (with crossed fingers)
     
    Thanks for you help
  11. Like
    aprayoga reacted to bunducafe in SD-Card to eMMC OS issue   
    Hi folks,
     
    just a heads up in this thread (maybe related to others experiencing boot issues with Helios64 and OMV5):
     
    If you use the setup: OMV5, Multiple Hdds, LUKS encryption + UnionFS
     
    then it is very likely that the machine does not come up instead is booting into revocery mode. That's because it cannot find any mountpoints because of LUKS. In order to get the helios booting again you have to add a "nofail" into the mergerfs option.
     
    Unfortunately the merferfs pool does not getting mounted automatically once you decrypted the hdds within LUKS Plugin. That's a bit of a nuisance but it is bearable if you do not boot your machine every day. In my case I had to remove the nofail, the mergerfs did mount immediately and then I did put the nofail in again. There might be a more elegant possibility but at least it is a remedy to get the helios working again.
     
    Jump over to the OMV-forums and do a search for LUKS + UnionFS + nofail and you find several threads about that issue.
     
    I have no idea if it is better to swith to the merferfsfolder plugin because I have no knowledge so far if I just can change the plugins without any errors.
  12. Like
    aprayoga reacted to oneo in Easy way to up boot precedence for microSD   
    Hey there, so I was curious is there an easier way to make microSD take precedence in the boot order then having to futz with jumpers?
     
    Wanting to try out a new distro on microSD before deciding to make the switch and flash it to eMMC.

    If I do futz with jumpers I'll still be able to mount and write to the eMMC correct?
  13. Like
    aprayoga got a reaction from kabo in Helios64 won't boot   
    @kabo is this new fresh sd card image?
    I assume it is not, looking on u-boot build date that is quite old. Did you recently update & upgrade the Armbian?
    You can try my instruction on following thread:
     
  14. Like
    aprayoga got a reaction from Dee Cheung in RK3399 Legacy Multimedia Framework   
    @JMCC Thanks for the hint. i'll take a look.
  15. Like
    aprayoga got a reaction from gprovost in Failing to boot from EMMC   
    @qrthi it seems something wrong during writing to eMMC.
    Your log show these lines
    Wrong image format for "source" command SCRIPT FAILED: continuing... How did you write the image? We recommend to use Etcher because it has write verification.
     
     
    The boot mode jumper only needed if for some reason the bootloader corrupted and to fix it you need to completely bypass the boot device.
    If the bootloader (u-boot) just fine, it will load Armbian from the sdcard first.
    The "Card did not respond to voltage select" is because you removed the sdcard.
    If you put Armbian sdcard, the lines would be
    Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3185 bytes read in 6 ms (517.6 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1  
    My suggestion,
    1. Download latest Armbian image.
    2. Since you already have u-boot on your eMMC, no need to download and write the helios64_sdcard_u-boot-only.img.xz into sdcard.
    3. Power on and enter UMS recovery mode
    4. Write the image using Etcher. No need to extract the image. Etcher can handle it just fine.
    5. Reboot Helios64.
     
     
  16. Like
    aprayoga reacted to qrthi in Failing to boot from EMMC   
    Hi, everyone. The Kobo site is kind of difficult to navigate if you're looking for relevant information, but I came to the conclusion that this is the right place for support. Forgive me if I'm mistaken.
     
    I was wondering if someone could help me interpret these bootlogs from serial term when trying to boot my Helios64 from the EMMC. Following the instructions on Kobol's site, I flashed their u-boot image to an sd card, booted the Helios64 off of said sd, fetched the latest image of Armbian, unpacked that image, and flashed it from my laptop to the Helios64 via usbc to what I presume is the correct interface. Could it be that I messed up? Here's a quick example of the weird behaviour when I take the sd card out and turn on the machine:
     
     
    Basicall, it keeps repeating this dialogue but with different files. So, for the one above, it says "Retrieving file: pxelinux.cfg/01-64-62-66-d0-03-42", but then it'll go on and say "Retrieving file: pxelinux.cfg/C0A8018", and so on. It'll keep doing that for a bunch of files, after which there's no boot screen or login prompt or anything. I haven't managed to ssh into it, either, but it may be my mistake that I can't figure out how to do so.
     
    If I unplug the ethernet, it looks like this:
     
    I'm really dreading the idea that I have to take apart the chassis and jump the board so that I can boot from the sd card. I don't understand why the sd card wouldn't be before the emmc in Helios64's boot order. That seems absurd to me.
     
    Anyway, here's at least part of the log. I didn't feel like sitting around to let it go through all the files:
     
  17. Like
    aprayoga reacted to qtmax in Helios4 performance concerns   
    I found the offending commit with bisect: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5ff9f19231a0e670b3d79c563f1b0b185abeca91
     
    Reverting it on 5.10.10 restores the write performance, while not hurting read performance (i.e. keeps it high).
     
    I'm going to submit the revert to upstream very soon — it would be great if it also could be applied as a patch to armbian.
     
    (I would post a link here after I submit the patch, but this forum won't allow me to post more than one message a day — is there any way to lift this limitation?)
     
    @gprovost, could you reproduce the bug on your NAS?
  18. Like
    aprayoga reacted to Heisath in Only LED8 light up...!?   
    @Mangix probably not, if he hasn't used it for a few months.
     
     
    @pierre LED 8 is the power led, if nothing else shows (not even LED1 / 2 which are system / error) I'd assume your board is not even starting and your SD card might be corrupt. 
    For further debugging you'll need to attach a computer to the micro usb and listen with some serial terminal to the output (and post it here). Or you could burn another SD card and try with that one.
     
    For LED meaning: https://wiki.kobol.io/helios4/hardware/
    For Setup (also includes connecting serial terminal): https://wiki.kobol.io/helios4/install/
  19. Like
    aprayoga reacted to apocrypha in helios4 Use USB Gadget Ethernet option available?   
    Is helios4 usb gadget Ethernet enabled?
    If it is available, how can it be activated?
    If the usb gadget Ethernet is not default build , which helios4 kernel build options should I modify?
  20. Like
    aprayoga reacted to lalaw in DAS Mode and Capture One   
    Quick update here, I was running some benchmarks today.  Off the top of my head:
     
    1. local SSD was getting something like 1200 MB/s write and 1500 MB/s read
    2. USB connected HDD was getting ~175 MB/s write and 175 MB/s read
    3. NAS (not helios) connected at 1 Gbps was getting ~100 MB/s read/write
    4. Helios in DAS mode and on Raid 10 was getting approximately 170 write and 250 read.
    5. Helios in DAS mode on a single drive was getting 190 write and 220 read. 
     
    For the capture 1 use case, I think a solid contender.  Unfortunately, as I described in the other thread, I can't get my whole array presented in DAS mode (it wants to give me 200GB for a 18TB array).
     
     
    Updated: also ran on a single drive instead of the array.  Slightly better write numbers with slightly worse read numbers.  Also, frustratingly, drive capacity was off -- this time showing 1.2 TB instead of 10.
  21. Like
    aprayoga reacted to brunof in Missing RAID array after power loss   
    Good morning. Sorry for my English.
    I have the exact same problem, but with a difference when I use the commands: 
    mdadm /dev/md0 --assemble /dev/sd[abc]
     
    root@Server-Archivos:~# mdadm /dev/md127 --assemble /dev/sd[abc]
    mdadm: /dev/sda is busy - skipping
    mdadm: /dev/sdb is busy - skipping
    mdadm: /dev/sdc is busy - skipping
     
    I leave the same information to know if you can help me.
     
     
    This is the syslog.
     
     
  22. Like
    aprayoga reacted to freed00m in smartctl tests are always cancelled by host.   
    Hello,
     
    I've bought 3 new identical drives and put 2 of them in the Helios64 and 1 onto my desktop.
    I ran smartctl longtest+shortest on both drives simultanously but all of them were aborted/interupted by host.
     
    `# /usr/sbin/smartctl -a /dev/sda`
    Output: http://ix.io/2OLt
     
    On my desktop the longtest from smartctl succeeds without error and all 3 drives received the same care, I just bough them and installed them, so unlikely the drives are physically damaged. 
     
    The complete diagnostic log: http://ix.io/2OBr
     
    So anyone got an idea why are my SMART extended tests being canceled?
     
    Note: I've tried even the trick with running background task to prevent drives from some vendor sleep `while true; do dd if=/dev/sda of=/dev/null count=1; sleep 60; done`
  23. Like
    aprayoga reacted to Benjamin Arntzen in Crazy instability :(   
    Hi there,
     
    I love my Helios64 to death. I'm running MooseFS CE and MooseFS PRO.
     
    The problem is I'm absolutely hammering it with I/O and it's consistently hard crashing, and no fix I've tried helps.
     
    Should I revert to the older kernel version or something? Or is this a useful test case...
  24. Like
    aprayoga got a reaction from gprovost in Mystery red light on helios64   
    Hi @snakekick, @clostro, @silver0480, @ShadowDance
    could you add following lines to the beginning of /boot/boot.cmd
    regulator dev vdd_log regulator value 930000 regulator dev vdd_center regulator value 950000 run
    mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr and reboot. Verify whether it can improve stability.
     
     
     
    You could also use the attached boot.scr
     
     
    boot.scr
  25. Like
    aprayoga reacted to ShadowDance in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED   
    Hey, sorry I haven't updated this thread until now.
     
    The Kobol team sent me, as promised, a new harness and a power-only harness so that I could do some testing:
    Cutting off capacitors from the my original harness did not make a difference The new (normal) harness had the exact same issue as the original one With the power-only harness and my own SATA cables, I was unable to reproduce the issue (even at 6 Gbps) Final test was to go to town on my original harness and cut the connector in two, this allowed me to use my own SATA cable with the original harness and there was, again, no issue (at 6 Gbps) Judging from my initial results, it would seem that there is an issue with the SATA cables in the stock harness. But I should try to do this for a longer period of time -- problem was I didn't have SATA cables for all disks, once I do I'll try to do a week long stress test. I reported my result to the Kobol team but haven't heard back yet.
     
    Even with the 3.0 Gbps limit, I still occasionally run into this issue with the original harness, has happened 2 times since I did the experiment.
     
    If someone else is willing to repeat this experiment with a good set of SATA cables, please do contact Kobol to see if they'd be willing to ship out another set of test harnesses, or perhaps they have other plans.
     
    Here's some pics of my test setup, including the mutilated connector: