• Posts

  • Joined

  • Last visited


Recent Profile Visitors

2346 profile views

ebin-dev's Achievements

  1. Thank you @prahalfor digging into this !! @aprayoga@piter75 Could the emmc issue be solved now with this input ?
  2. If you could boot from SD - the current Buster image should be fine - mount your ssd, replace linux on ssd (same procedure), and check the UUIDs at the two locations hopwfully solves the problem.
  3. Hi @Flolm, what you could do to rescue your system on emmc is to boot from sd (i.e. using a fresh Armbian Buster) and reinstall linux on emmc from there (using chroot as described here). You also need to check whether the UUIDs are set correctly in /mnt/system/etc/fstab and /mnt/system/boot/armbianEnv.txt (assuming that your emmc is mounted to /mnt/system). Good luck! P.S.: in any case you should maintain a backup of your emmc (on sd).
  4. @piter75 commited the emmc fix into Armbian and built Armbian 21.08.2 which is already available through the Armbian mirrors (via 'apt update && apt upgrade'). It is save to upgrade your Buster or Bullseye installation to Armbian 21.08.2 - but emmc read speed will be about 50% what it used to be. You can roll back to the previous linux 5.10.43 kernel if you don't like that - just install those files with 'dpkg -i *.deb'.
  5. Really ? If you are on macOS Big Sur all the drivers and apps are already there. If you need to access the serial console of your Helios64, just connect your mac to the USB-C port of your Helios64. A device such as /dev/tty.usbserial-XXXXXXXX will be recognised by macOS. All you need to do then is to enter the following into the Terminal of your mac (X to be replaced): screen /dev/tty.usbserial-XXXXXXXX 1500000 -L Edit: If the 'screen' command on macOS does not show the output of the bootloader (scrambled characters) you could use the app serial. The only thing you need to configure is to set the serial speed manually to 1500000 bps. If someone would like to contribute in kernel testing - the Armbian build system is very easy to install and use. All you need is an Ubuntu 21.04 (amd64) installation. All the rest is explained here. To compile your own kernel is then as simple as this: ./compile.sh BOARD=helios64 BRANCH=current KERNEL_ONLY=yes RELEASE=bullseye
  6. Sorry - but it is difficult to help because the current state of your system is not known. You could format your system partition on emmc, rsync your backup to it and refresh the bootloader on emmc as described earlier in this thread.
  7. See the parallel thread (I have just changed the thread title). You need to downgrade linux on emmc to 5.10.43.
  8. I can confirm that your temporary fix works on my system. To test it one just needs to fully upgrade emmc to the latest Armbian 21.08.1 release and apply the above fix before a reboot. The system partition on emmc remains writable - even with kernel 5.10.60 - but with the performance penalty. (However, I switched back to kernel 5.10.43 again) So - from my point of view you could provide an updated release including this temporary fix. Please keep us informed if the underlying issue is solved. Thank you again !
  9. Hi Peter, thank you for the analysis. If someone confirms that hs200 mode is a temporary solution for linux kernels 60+ you could release an update with this fix. So everyone will have the choice to stay with linux-5.10.43 for the time being or to upgrade to newer kernels .60+ with a performance penalty on emmc (but with a writable file system).
  10. All you need to do is this (see my earlier message): The easiest way to downgrade linux on emmc now would be to copy those files to /mnt/system (root directory of your emmc) - and then change root with 'chroot /mnt/system' and install the packages with 'dpkg -i *.deb' (while your active system is on SD). You may also need to refresh your bootloader on emmc - as described in this thread. P.S.: It would appear that you have mounted your SD card (/dev/mmcblk1p1) to /mnt/system and not your emmc (/dev/mmcblk2p1). You need to boot off SD.
  11. As the topic of this thread is upgrading Buster to Bullseye, I did some further testing in this context: I would like to confirm that upgrading Buster installations to Bullseye also works fine if you use network-manager to manage your network interfaces (default), even if you have a bridge configured (using bridge-slave; binutils-bridge). Using a Buster image from the Helios64 download page and following the instructions provided in the first message in this thread, the Buster image was successfully upgraded to Bullseye and the bridge configured is also working (the first message in this thread is updated accordingly): _ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian 21.08.1 Buster with Linux 5.10.60-rockchip64 No end-user support: built from trunk System load: 3% Up time: 1 min Memory usage: 4% of 3.77G IP: xx.xx.xx.xx CPU temp: 42°C Usage of /: 8% of 29G RX today: 518.9 MiB [ General system configuration (beta): armbian-config ] # nmcli br0: connected to br0 "br0" bridge, xx:xx:xx:xx:xx:B1, sw, mtu 1500 ip4 default, ip6 default inet4 xx.xx.xx.55/24 route4 route4 xx.xx.xx.0/24 inet6 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 route6 2a02:xxxx:xxxx:xxxx::/62 route6 2a02:xxxx:xxxx:xxxx::/64 route6 ::/0 route6 fe80::/64 lxcbr0: connected (externally) to lxcbr0 "lxcbr0" bridge, xx:xx:xx:xx:xx:xx, sw, mtu 1500 inet4 route4 route4 eth0: connected to bridge-slave-eth0 "eth0" ethernet (rk_gmac-dwmac), xx:xx:xx:xx:xx:xx, hw, mtu 1500 master br0 eth1: unavailable "Realtek 10/100/1G/2.5G" ethernet (r8152), 6xx:xx:xx:xx:xx:xx, hw, mtu 1500 vethpivccu: unmanaged "vethpivccu" ethernet (veth), xx:xx:xx:xx:xx:xx, sw, mtu 1500 lo: unmanaged "lo" loopback (unknown), xx:xx:xx:xx:xx:xx, sw, mtu 65536 DNS configuration: servers: xx.xx.xx.xx domains: fritz.box interface: br0 servers: fd00::xxxx:xxxx:xxxx:xxxx interface: br0 Use "nmcli device show" to get complete information about known devices and "nmcli connection show" to get an overview on active connection profiles. Consult nmcli(1) and nmcli-examples(7) manual pages for complete usage details. The resulting system works on SD, but linux needs to be downgraded to 5.10.43 (as described above) before you transfer the system from SD to emmc.
  12. Hi @lanefu - do you mean whether or not a buster or bullseye system on emmc that is updated from Armbian 21.05.4 to 21.08.1 has non matching UUIDs in the three locations ? What I can tell is that boot.scr does not contain a UUID at all. The device /dev/mmcblk0p1 is specified instead (in boot.cmd) - also in the fresh Buster image on the download page. UUIDs are present in /boot/armbianEnv.txt and /etc/fstab. If they are correctly set to the UUID of the root filesystem, a previous Buster 21.05.4 installation was running fine on SD and on emmc. The "emmc issue" occurs after the update from 21.05.4 to 21.08.1 even if the UUIDs in /boot/armbianEnv.txt and /etc/fstab are correctly set to the UUID of the root file system on emmc.
  13. 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. Armbian is a community driven project. This is not about trying to find someone to blame, but trying to solve issues by pointing to alleged sources of the trouble. And indeed community support is there as you can see in this thread - it could be stronger though.