jbergler

  • Posts

    23
  • Joined

  • Last visited

Reputation Activity

  1. Like
    jbergler reacted to Gareth Halfacree in Random rant   
    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?
  2. Like
    jbergler reacted to Gareth Halfacree in Random rant   
    I am calm. What I am not is accepting of abuse.
  3. Like
    jbergler got a reaction from TRS-80 in ZFS on Helios64   
    The problem here is that it‘s not possible to compile the module on Debian because of how the kernel has been built.
    I reported the issue here and while I could *fix* it, it really strikes me as something the core armbian team needs to weigh in on.
    One option is to use an older GCC in the build system, the other is to disable per task stack protections in the kernel - neither seem like great choices to me.
     
  4. Like
    jbergler got a reaction from deucalion in ZFS on Helios64   
    The problem here is that it‘s not possible to compile the module on Debian because of how the kernel has been built.
    I reported the issue here and while I could *fix* it, it really strikes me as something the core armbian team needs to weigh in on.
    One option is to use an older GCC in the build system, the other is to disable per task stack protections in the kernel - neither seem like great choices to me.
     
  5. Like
    jbergler reacted to SIGSEGV in iSCSI on Helios64 [Working great on Armbian 20.11 test images]   
    @jbergler
    It's called cockpit - it listens on port 9090
    You can install it with:
    sudo apt -y install cockpit cockpit-networkmanager cockpit-packagekit cockpit-storaged  
  6. Like
    jbergler reacted to Igor in Helios64 Support   
    That is expected and normal.
    https://forums.xilinx.com/t5/Embedded-Linux/U-Boot-Initialization-Issues/td-p/983852
  7. Like
    jbergler reacted to ShadowDance in Helios64 Support   
    @jbergler I had the same issue with panics on 20.08.21 Buster (also using ZFS). Problem went away after I switched from ondemand to performance governor via armbian-config.
  8. Like
    jbergler got a reaction from registr123 in Helios64 Support   
    If you, like myself, installed on eMMC and are experiencing the crashes on 20.08.14 - I booted up via a 20.08.10 sdcard and fixed the environment on emmc
     
    # mount the emmc + get ready to chroot mkdir /mnt/chroot mount /dev/mmcblk1p2 /mnt/chroot/ mount /dev/mmcblk1p1 /mnt/chroot/media/mmcboot mount --bind /mnt/chroot/media/mmcboot/boot/ /mnt/chroot/boot/ mount --bind /dev /mnt/chroot/dev/ mount --bind /proc /mnt/chroot/proc/ mount --bind /tmp /mnt/chroot/tmp/ # chroot in and downgrade to 20.08.10 chroot /mnt/chroot/ /bin/bash apt install \ linux-dtb-current-rockchip64=20.08.10 \ linux-headers-current-rockchip64=20.08.10 \ linux-image-current-rockchip64=20.08.10 \ armbian-config=20.08.10 \ armbian-firmware=20.08.10 \ linux-focal-root-current-helios64=20.08.10 \ linux-u-boot-helios64-current=20.08.10 exit # now remove the sd card and hit reset  
    @aprayoga It's probably unrelated, but while working through the above I noticed that I ran out of space on /boot.
    I installed to eMMC the first version that was working, if that helps. I chose f2fs when I installed on eMMAC and this is the resulting partition layout
    mmcblk1 179:32 0 14.6G 0 disk ├─mmcblk1p1 179:33 0 96M 0 part └─mmcblk1p2 179:34 0 14.3G 0 part mmcblk1boot0 179:64 0 4M 1 disk mmcblk1boot1 179:96 0 4M 1 disk Sadly I didn't grab enough info from what was in the boot partition before I nuked it and reinstalled the appropriate packages.
     
  9. Like
    jbergler got a reaction from aprayoga in Helios64 Support   
    @aprayoga if you still need it here's a full boot log of the crash (the actual stacktrace of the crash is inconsistent for me)
     
     
     
  10. Like
    jbergler got a reaction from aprayoga in Helios64 Support   
    If you, like myself, installed on eMMC and are experiencing the crashes on 20.08.14 - I booted up via a 20.08.10 sdcard and fixed the environment on emmc
     
    # mount the emmc + get ready to chroot mkdir /mnt/chroot mount /dev/mmcblk1p2 /mnt/chroot/ mount /dev/mmcblk1p1 /mnt/chroot/media/mmcboot mount --bind /mnt/chroot/media/mmcboot/boot/ /mnt/chroot/boot/ mount --bind /dev /mnt/chroot/dev/ mount --bind /proc /mnt/chroot/proc/ mount --bind /tmp /mnt/chroot/tmp/ # chroot in and downgrade to 20.08.10 chroot /mnt/chroot/ /bin/bash apt install \ linux-dtb-current-rockchip64=20.08.10 \ linux-headers-current-rockchip64=20.08.10 \ linux-image-current-rockchip64=20.08.10 \ armbian-config=20.08.10 \ armbian-firmware=20.08.10 \ linux-focal-root-current-helios64=20.08.10 \ linux-u-boot-helios64-current=20.08.10 exit # now remove the sd card and hit reset  
    @aprayoga It's probably unrelated, but while working through the above I noticed that I ran out of space on /boot.
    I installed to eMMC the first version that was working, if that helps. I chose f2fs when I installed on eMMAC and this is the resulting partition layout
    mmcblk1 179:32 0 14.6G 0 disk ├─mmcblk1p1 179:33 0 96M 0 part └─mmcblk1p2 179:34 0 14.3G 0 part mmcblk1boot0 179:64 0 4M 1 disk mmcblk1boot1 179:96 0 4M 1 disk Sadly I didn't grab enough info from what was in the boot partition before I nuked it and reinstalled the appropriate packages.
     
  11. Like
    jbergler got a reaction from robbixc in unable to build zfs module on buster rockchip64   
    These won't be exact instructions, since I decided to switch to focal (mostly for other reasons).
     
    mkdir zfs-scratch cd zfs-scratch apt-get download linux-headers-current-rockchip64 git clone -b zfs-0.8.5 https://github.com/openzfs/zfs.git docker run --rm -it -v $(pwd):/scratch ubuntu:focal # inside the container cd /scratch apt update apt install build-essential autoconf automake bison flex libtool gawk alien fakeroot dkms libblkid-dev uuid-dev libudev-dev libssl-dev zlib1g-dev libaio-dev libattr1-dev libelf-dev python3 python3-dev python3-setuptools python3-cffi libffi-dev dpkg -i linux-headers-current-*.deb cd zfs sh autogen.sh ./configure make -s -j$(nproc) deb  
    At that point you can exit the container (it'l vanish because of the --rm) and inside zfs-scratch/zfs you should have a bunch of Debian packages you can install
     
  12. Like
    jbergler got a reaction from antsu in unable to build zfs module on buster rockchip64   
    These won't be exact instructions, since I decided to switch to focal (mostly for other reasons).
     
    mkdir zfs-scratch cd zfs-scratch apt-get download linux-headers-current-rockchip64 git clone -b zfs-0.8.5 https://github.com/openzfs/zfs.git docker run --rm -it -v $(pwd):/scratch ubuntu:focal # inside the container cd /scratch apt update apt install build-essential autoconf automake bison flex libtool gawk alien fakeroot dkms libblkid-dev uuid-dev libudev-dev libssl-dev zlib1g-dev libaio-dev libattr1-dev libelf-dev python3 python3-dev python3-setuptools python3-cffi libffi-dev dpkg -i linux-headers-current-*.deb cd zfs sh autogen.sh ./configure make -s -j$(nproc) deb  
    At that point you can exit the container (it'l vanish because of the --rm) and inside zfs-scratch/zfs you should have a bunch of Debian packages you can install