bunducafe

  • Posts

    20
  • Joined

  • Last visited

Reputation Activity

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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."  
  6. 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/
     
  7. 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.
  8. 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.
  9. 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)
     
     
     
  10. 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.
  11. 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.
  12. 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.
  13. 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?! 
  14. 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.