bunducafe

Members
  • Posts

    33
  • Joined

  • Last visited

Reputation Activity

  1. Like
    bunducafe got a reaction from sepp 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.
     
  2. Like
    bunducafe reacted to Werner in Kobol Team is pulling the plug ;(   
    Only general development on rockchip64 family. However since Helios64 has no maintainer changes there could also break functionality.
  3. Like
    bunducafe got a reaction from hartraft 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.
  4. Like
    bunducafe got a reaction from allen--smithee 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
    bunducafe got a reaction from hartraft 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.
     
  6. Like
    bunducafe reacted to Amix73 in Kobol Helios64 on Sale   
    @bunducafe You can also donate one-time - just go to the store and click donation - paypal is available as well, although not visible at first.
    @allen--smithee  in the end it is the same for me  as you summarized - when there will be no interesting helio64 relacement - wandering off will be quite certain.
    Right at the moment I am really happy with a working and most of the time stable Helios64-system.

    Let's hope that the status-quo remains for a while. The migration of my old QNAP419P system to Herlios64 was rather time-consuming - so I am not very motivated to start over again, although my backup strategy improved significantly ;-)
     
  7. Like
    bunducafe reacted to allen--smithee in Kobol Helios64 on Sale   
    @bunducafe
    I think people want to recover the market value to get another market product (Black friday/Christmas/New gen) or/also else be completely overwhelmed by the dt notion.
     
    https://forum.armbian.com/subscriptions/
     
    it's a good start 5€ per month = 60€ per year,
    over the lifetime of the equipment estimated at several years.
    300€ = 5years.
     
    The financing of the support therefore depends on the quality of the product.
    If my Kobol Product dies and no other Board support by Armbian Community interests me, my Armbian participation will end.
    For me the two are linked.
     
    @Amix73
    I find your intervention very chivalrous, and I thank you for supporting the Armbian project which supports this great Board (with its known flaws) produced by Kobol.
  8. Like
    bunducafe reacted to Amix73 in Kobol Helios64 on Sale   
    QUICK UPDATE:  I am NOW looking for ONLY one Helios64 (either full system or just the board).

    The reason is, that I got an explanation from Igor, that hardware donations do NOT make sense (they are deprecated)  since they are not needed - hardware is the cheapest part of the dev-process, and the devs have enough hardware.
    So the ONLY thing what would help the Armbian project would be
    a.) person-power, i.e., help for keeping the project going (development, infrastructure, build-server) OR
    b.) money donations.
     
    That's why I am NOW looking for ONLY for a single Helios64 (full system or just the board) -  when it is located in Europe. It's for my personal use and as a backup.
    @planned donation; Since I have neither the time nor the expertise to participate in development - I will make a single donation of 300€ (done) - which was the worth of the hardware.
    I will consider a subscription if it is possible to donate anonymously

    BUT STILL - if you are located in Europe and have a helio64 you want to sell - please contact me.
     
    Thank you.
     
  9. Like
    bunducafe got a reaction from hartraft 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.
  10. Like
    bunducafe got a reaction from TDCroPower in Random reboots   
    I had a similar issue with random reboots. Did DM @axelroy directly and also "tweaked" the system.
     
    I am running the helios now for almost 2 weeks without issues with the following settings:
    Min CPU speed = 400 MHz
    Max CPU speed = 1400 MHz
    CPU governor = on demand
     
    So it seems that the helios was rebooting when having to deal with intensive tasks - in my case: performing a SnapRAID scrub. Anyhow: Now I am at maximum speed of 1400MHz whereas the helios could perform even on 1800MHz. The question is if this is a problem by design? Or is there a way to fix it in order to let the machine run full CPU speed and performance governor? I am happy with the machine, no doubt, at the end this is rather a question of how I can achieve the maximum speed if needed.
  11. Like
    bunducafe reacted to SIGSEGV in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Thanks @lanefu.
    Another idea would be a "test week" (or whatever period makes sense) - a time when the users can download pre-release/test images of the upcoming version/release and the maintainers give timely feedback about issues found in the test kernels and user space binaries. I know that Fedora follows a similar approach (I get the notifications from the Fedora Magazine) - the main objective is to catch breaking bugs.
     
    Now, if the community doesn't participate - then all complaints can be considered rants. We have to participate to make sure our systems are running as smoothly as possible. Software development, QA, Trouble shooting are task that take time/effort, as @Igor has always pointed out, we need to get involved somehow in order to contribute back. In the end Armbian is a community project - if you can't/want to donate funds, donate time and effort instead.
  12. Like
    bunducafe reacted to Igor in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    I have expected you will think about why I told you that. You can skip my rant below and read https://docs.armbian.com/User-Guide_FAQ/ Most of the answers are there.
     
    I am commonly sad because I can't help people that are genuine helpful, friendly, respectful and are willing to repay when asking for help. This is the base to form a healthy relationship. People that understand they are asking for a favour.
     
    As a person in any role I can't support putting a pressure to developers / doers / makers that are around, nor support suicidal behaviour. If I notice something like that is happening I have to take a side and support one, trying to reason the other. Since I can't afford to spent indefinite time (=money) for reasoning "customers" which shows to little respect to the platform we maintain and support (I understand anger from users because something failed)  ... while crushing is cheap and usually effective. If I pick your side, you will lost people that creates you value pretty quickly. Nevertheless we wrote some community rules which should help us all avoiding having conversations derailed in first place. "Bumping topic is not a nice thing to do, seeking for attention - keep your ego to yourself, ask politely without pressure, you who came here on this forum.". 
     
    I would gladly deal with "you" on the level you expect, but there are too many of "you" any "you" are already having a huge https://en.wikipedia.org/wiki/Debt:_The_First_5000_Years while contributing 1000 x too little to match your wishes and demands. This is nothing to do with you personally. This is just a perception users have. 

    Asking what you can do for us is probably far better strategy to get something in return. We have many known bugs, and no resources to deal with them. We have much much too many requests for attention and way too little time to deal with. Some ideas: https://forum.armbian.com/forum/54-help-wanted/ When I saw someone that is also busy and inpatient, asking just for some money is perhaps best? Even chances to get costs covered by a person who is making it are close to 0%, the same goes with an interest to help that person.
  13. Like
    bunducafe reacted to ebin-dev in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    I own a Helios64  too and I store data on it I really do not want to loose.  I love this thing !
    But It is in fact ridiculous if updates are provided having the potential to render your setup unusable or even to loose your data.
     
    After Kobol stopped operations my immediate reaction a was to close the Armbian update channel and to test potential Armbian updates myself -  and not on my main system.
     
    Instead of turning away from Armbian I try to support Helios64 on this platform. As long as Kobol operations are stopped we need to build and test linux kernels ourselves before updating to any new linux version.
     
    However, there is a stable kernel 5.10.43 for Helios64 (in particular with the ondemand governor active) and it is the kernel branch Debian Bullseye is using.
    With this setup it should be already possible to operate Helios64 for the next 2-5 years in a stable manner by just receiving updates through the Debian Bullseye channel - with occasional linux updates compiled and tested by members of this forum.
     
    Everybody is invited to contribute.
  14. Like
    bunducafe got a reaction from IcerJo in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    If you do fiddle around keep us posted, would be great to know if it works... I am somehow reluctant to try it at the moment as I need a running system. Because the mentioned workaround (updating bootloader) does not make the emmc fully writeable I would rather stick to the sd card at the moment.
  15. Like
    bunducafe reacted to ebin-dev in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    First I would downgrade the system on SD to 21.05.4 (you can access emmc again without i/o errors), then format the partition on emmc 'mkfs.ext4 /dev/mmcblk2p1' (to get rid of potentially corrupt content) and rsync the content from sd to emmc (assuming that the sd contains a valid copy of your system on emmc).
    For the last step you can adapt the script I use (it is a modified Armbian script). I did no use any armbian-config routines this time.
    You may need to update the bootloader on emmc too.
     
    # cat copytoemmc.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/emmc/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/emmc exec 2>&1 mount /dev/mmcblk2p1 /mnt/emmc rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/emmc # change fstab sed -e 's/UUID=< insert uuid of sd >/UUID=< insert uuid of emmc >/g' -i /mnt/emmc/etc/fstab sed -e 's/UUID=< insert uuid of sd >/UUID=< insert uuid of emmc >/g' -i /mnt/emmc/boot/armbianEnv.txt umount /mnt/emmc rm install-exclude echo "All done."  
  16. Like
    bunducafe reacted to ebin-dev in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    In order to roll back the kernel you just need to install those packages (on sd): http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/
     
  17. Like
    bunducafe got a reaction from IcerJo in Summary of troubleshooting items   
    I am with Buster, but regarding the ondemand governor: I have set them from the very beginning from 400 and 1400 and the system has been running rocksolid after this.
  18. Like
    bunducafe got a reaction from lanefu in Does anyone actually have a stable system?   
    After fiddeling aroud I finally have the helios64 also running solid. I never had any freezes before just some problems with getting the system to boot from the emmc device and, see other thread, with setting up OMV - LUKS - Snapraid - UnionFS
     
    I am currently under: Linux helios64 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 GNU/Linux
    OMV Version 5.6.2-1 (Usul)
     
    So I would say that OMV is not the culprit out of the box. The system works fine but it always depends on what kind of plugins you are using etc. So far I have no docker installed here but I certainly will do that again. I do recommend the OMV Backup Plugin so I can boot from the latest stable release via SDcard if I mess up with something. That's also nice.
  19. Like
    bunducafe reacted to gprovost in How can I move the root filesystem manually from sata drive to eMMC   
    Yes unfortunately nand-sata-install does not work the other way around, I'm looking at it currently since there was another use case related to install on OS rootfs on HDD that wasn't also supported.
     
    The step for you case should be :
     
    1. First boot the system on a microSD card with a fresh install of Armbian.
     
    2. Copy rootfs from old destination (HDD) to new destination (eMMC)
     
    mkdir /mnt/rfs_new /mnt/rfs_old mount /dev/mmcblk2p1 /mnt/rfs_new/ mount /dev/sdX1 /mnt/rfs_old/ rsync -avrlt --delete --exclude-from=/usr/lib/nand-sata-install/exclude.txt /mnt/rfs_old/ /mnt/rfs_new/  
    3. use command blkid to know the UUID of /dev/mmcblk2p1
     
    4. Modify /mnt/rfs_new/boot/armbianEnv.txt to modify rootdev line with the UUID of /dev/mmcblk2p1
     
    verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=075c8660-77ca-4048-a04b-be3364c60a40 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
    5. Modify /mnt/rfs_new/etc/fstab 
     
    - Remove /media/mmcboot and /boot mount point lines
    - Edit / mount point to use the UUID of /dev/mmcblk2p1
     
    # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 UUID=075c8660-77ca-4048-a04b-be3364c60a40 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1  
    6. Sync and Poweroff
     
    7. Remove microSD and Poweron (maybe cross your finger also)
     
     
     
  20. Like
    bunducafe got a reaction from hartraft 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.
  21. Like
    bunducafe got a reaction from gprovost 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.
  22. Like
    bunducafe got a reaction from aprayoga 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.
  23. Like
    bunducafe got a reaction from allen--smithee in Very noisy fans   
    Hi folks,
     
    I am fairly new here, reading, trying to understand but do have some knowledge with Unix and some SBC. Now the Helios64 is on arrival and I would like to know if I should change the fans immediately in order to get a quieter case. 
     
    Is the NF-A8-PWM significantly less noisy than the stock ones? Or is there maybe a different route to go?! 
  24. Like
    bunducafe reacted to TRS-80 in eth1 (2.5) vanished: Upgrade to 20.11.3 / 5.9.14-rockchip64   
    Rare mistake by Igor!
     
    In few years I been lurking here, this is only time I can recall such thing happening.  Of course everyone make mistakes, and there were probably some I was not aware of, but this is first time I can remember such thing happening.