Werner

  • Posts

    2648
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Werner got a reaction from hello_world.c in SOLVED: Kernel headers installed, but where do I find .config for stock kernel?   
    .config file matching the installed kernel is always in /boot.
  2. Like
    Werner reacted to Pali in How to make ESPRESSObin v7 stable?   
    It looks like that even with latest patches is 1.2 GHz mode unstable on more boards. Therefore there is a proposed patch which completely disables cpufreq driver on 1.2 GHz variant of all A3720 SoC including Espressobin:
    https://lore.kernel.org/linux-pm/20210630135942.29730-1-kabel@kernel.org/t/#u
     
    If you have any input on this or reaction from Marvell / GlobalScale, please reply.
  3. Like
    Werner got a reaction from Kiel in OrangePi Zero2 - Allwinner H616   
    https://github.com/armbian/build/pull/2907
  4. Like
    Werner got a reaction from NicoD in Review of the PineBook Pro with Armbian   
    Glad you have fun with it
     
  5. Like
    Werner reacted to NicoD in Review of the PineBook Pro with Armbian   
    Hi al.
    I've finished my review of the PineBook Pro. I just love this thing. Runs great with Armbian.
    Here my video.
    Here all my gathered information:
     
  6. Like
    Werner reacted to Igor in banana m1+ builtin wifi card not working with the latest debian/ubuntu+kernel   
    This is forum - you are welcome to talk about, but demanding support is a bad idea. You can report bugs here but only if you pay commercial price for fixing it & if we agree / are free to accept a deal or if you will be the one fixing it.
     
     
    By who? Why? Several years ago (i would estimate about 5 years) we have concluded its not possible without breaking others or without severe framework customisation / rework ... This is when incompetent people are making hardware and when you expect software can fix all those mistakes in this chaotic world. And you also believe we have to waste our private money for that. Attitude. Open source is not slavery.
  7. Like
    Werner reacted to NicoD in Videos : Armbian instructions for beginners - Install, Network access, What is Armbian...   
    That gave my videos a sudden boost. Thank you
  8. Like
    Werner reacted to lanefu in Odroid N2+ / N2 Plus   
    Had similar report for a user of stable helios4 after their rootfs package updated. 
     
    Ive modified jira issue to reflect broader scope
  9. Like
    Werner got a reaction from Z11ntal33r in Odroid N2+ / N2 Plus   
    Needs to be checked. https://armbian.atlassian.net/browse/AR-822?atlOrigin=eyJpIjoiZWQzYjJiZjM3NDEwNDY5Y2IxMzI2ZWRiZTRlZDRmYjciLCJwIjoiaiJ9
     
    To reduce wear on sdcard logs are written to a ramdisk and only synced periodically. To debug such things the best way is to put a serial console to it and log everything from there.
  10. Like
    Werner reacted to NicoD in Managing cpufreq on big.LITTLE   
    Feel free to try to add it to armbian-config.
    https://github.com/armbian/config
    The script is indeed dated. And no devs have time to work on it.
    I've always manually set it up in /etc/rc.local.
  11. Like
    Werner got a reaction from lampra in OrangePi Zero2 - Allwinner H616   
    https://github.com/armbian/build/pull/2907
  12. Like
    Werner reacted to MMGen in Full root filesystem encryption on an Armbian system (NEW, replaces 2017 tutorial on this topic)   
    Full root filesystem encryption on an Armbian system
    (new, fully rewritten, replaces my earlier tutorial on this topic)
     
    MMGen (https://github.com/mmgen)
     
    This tutorial provides detailed, step-by-step instructions for setting up full root filesystem encryption on an Armbian system.  The disk can be unlocked remotely via SSH or the serial console, permitting unattended bootup.
     
    An automated script that performs the same steps, saving you much time and effort, can be found at https://github.com/mmgen/mmgen-geek-tools
     
    Note that unlike my earlier tutorial all steps are performed within a running Armbian system.
     
    The tutorial is known to work with the following board/image combinations:
     Orange Pi PC2  Debian Buster mainline / Ubuntu Bionic and Focal legacy  RockPi 4  Debian Buster mainline / Ubuntu Bionic and Focal legacy  RockPro 64  Ubuntu Focal mainline  Odroid HC4  Debian Buster mainline / Ubuntu Focal mainline  
     
     
     
     
    You may have success with other boards/images too. If so, please post the details below (or open an issue in the mmgen-geek-tools Github repository), and I’ll add your board to the list.
     
    Requirements:
    A SoC with a running, upgradeable and Internet-connected Armbian system A blank Micro-SD card and USB card reader, or, alternatively, a blank eMMC installed on the board The ability to edit text files and do simple administrative tasks on the Linux command line  
    Step 1 - Preliminaries
     
    All steps in this tutorial are performed as root user on a running Armbian system (the “host”).
     
    The encrypted system (the “target”) will be created on a blank micro-SD card.  If your board has an eMMC not currently in use, the system can be created on it instead.
     
    Architecture of host and target (e.g. 64-bit or 32-bit ARM) must be the same.
     
    For best results, the host and target hardware should also be identical or similar.  Building on a host with more memory than the target, for example, may lead to disk unlocking failure on the target.
     
    If you’re building the target system for the currently running board and with the currently running image, which is the recommended approach, the two preceding points will be a non-issue.
     
    Packages will be installed using APT, so the host machine must be Internet-connected and its clock correctly set.
     
     
    Step 2 - Upgrade your system and install the cryptsetup-bin package
     
    # apt update && apt upgrade # apt install cryptsetup-bin  
     
    Step 3 - Get and unpack the latest Armbian image for your board
     
    Create your build directory:
    # mkdir armbenc-build && cd armbenc-build  
    Download the Armbian image of your choice for your board, place it in this directory and unpack:
    # xz -dv *.img.xz  
     
    Step 4 - Create mount directories and set up the loop mount
     
    Create the mount directories:
    # mkdir -p mnt boot root  
    Determine your first free loop device:
    # losetup -f  
    Associate the image file with the loop device name displayed by the previous command.  This will be '/dev/loop0' in most cases, but if your output was different, substitute that for '/dev/loop0' in the following steps.
    # losetup -P /dev/loop0 *.img  
    Examine the disk image using fdisk on the loop device:
    # fdisk -l /dev/loop0  
    The output should look something like this:
    Device Boot Start End Sectors Size Id Type /dev/loop0p1 32768 3489791 3457024 1.7G 83 Linux  
    Make a note of the start sector (32768 in this case).  You’ll need this value in the steps below.
     
    Now mount the loop device:
    # mount /dev/loop0p1 mnt  
     
    Step 5 - Copy the boot loader to the SD card
     
    Insert the blank micro-SD card and card reader into a USB port.
     
    Determine the SD card’s device name using 'dmesg' or 'lsblk'.  We’ll assume it to be '/dev/sda', since that’s the most likely case.  If your device name is different, substitute it for '/dev/sda' in the the following steps.  For an eMMC, the device name will probably be '/dev/mmcblk1'.
     
    WARNING: if '/dev/sda' refers to some other storage device, running the following commands unchanged will destroy data on that device, so always remember to substitute the correct device name!!!  The best way to eliminate this danger is to disconnect all unused storage devices on the board before proceeding further.
     
    Copy the image’s boot loader to the SD card, using the Start sector value from Step 4 as the argument for 'count':
    # dd if=$(echo *.img) of=/dev/sda bs=512 count=32768  
     
    Step 6 - Partition the SD card
     
    # fdisk /dev/sda  
    At the fdisk prompt, create a new DOS disk label with the 'o' command.  Use the 'n' command to create a primary partition of size +200M beginning at the same Start sector as the disk image.  Type 'p' to view the partition table, which should now look something like this:
    Device Boot Start End Sectors Size Id Type /dev/sda1 32768 442367 409600 200M 83 Linux  
    Use 'n' again to create another primary partition beginning one sector after the first partition’s end sector and filling the remainder of the card.  Type 'p' once more to view the partition table:
    Device Boot Start End Sectors Size Id Type /dev/sda1 32768 442367 409600 200M 83 Linux /dev/sda2 442368 30636031 30193664 14.4G 83 Linux  
    Ensure that the first partition’s Start sector matches that of the disk image (32768 in this example) and that the second partition’s Start sector is one greater than the End sector of the first (442368 and 442367, respectively, in this example).  If you’ve made a mistake, use 'd' to delete a partition and start again.

    Once everything looks correct, type 'w' to write the partition table to disk.
     
     
    Step 7 - Copy the system to the SD card
     
    The following commands will create a filesystem on the SD card’s boot partition and copy the boot partition data from the image file to it.  Don’t forget to substitute the correct device name if necessary.  If you’re building the system on an eMMC, the boot partition device is likely to be '/dev/mmcblk1p1' instead of '/dev/sda1'.
    # mkfs.ext4 /dev/sda1 # or '/dev/mmcblk1p1', for an eMMC target # e2label /dev/sda1 CRYPTO_BOOT # mount /dev/sda1 boot # cp -av mnt/boot/* boot # (cd boot; ln -s . boot)  
    Create the encrypted root partition.  When prompted for a passphrase, it’s advisable to choose an easy one like 'abc' for now.  The passphrase can be changed later with the 'cryptsetup luksChangeKey' command (type 'man cryptsetup' for details) once your encrypted system is up and running.
    # cryptsetup luksFormat /dev/sda2 # or '/dev/mmcblk1p2', for an eMMC target  
    Activate the encrypted root partition and create a filesystem on it:
    # cryptsetup luksOpen /dev/sda2 rootfs # enter your passphrase from above # mkfs.ext4 /dev/mapper/rootfs  
    Mount the encrypted root partition and copy the system to it:
    # mount /dev/mapper/rootfs root # (cd mnt && rsync -a --info=progress2 --exclude=boot * ../root) # sync # be patient, this could take a while # mkdir root/boot # touch root/root/.no_rootfs_resize  
    Unmount the boot partition and image and free the loop device:
    # umount mnt boot # losetup -d /dev/loop0  
     
    Step 8 - Prepare the target system chroot
     
    # BOOT_PART=($(lsblk -l -o NAME,LABEL | grep CRYPTO_BOOT)) # ROOT_PART=${BOOT_PART%1}2 # ROOT_UUID="$(lsblk --nodeps --noheadings --output=UUID /dev/$ROOT_PART)" # BOOT_UUID="$(lsblk --noheadings --output=UUID /dev/$BOOT_PART)" # cd root # mount /dev/$BOOT_PART boot # mount -o rbind /dev dev # mount -t proc proc proc # mount -t sysfs sys sys  
    Copy '/etc/resolv.conf' and '/etc/hosts' so you’ll have a working Internet connection within the chroot:
    # cat /etc/resolv.conf > etc/resolv.conf # cat /etc/hosts > etc/hosts  
    If you’re using non-default APT repositories, you may need to copy their configuration files as well so that 'apt update' and 'apt install' will use them inside the chroot.  Note that you can only do this if the host and target systems have the same distro/version.  If that’s not the case, you’ll have to edit the target files by hand.
    # cat /etc/apt/sources.list > etc/apt/sources.list # cat /etc/apt/sources.list.d/armbian.list > etc/apt/sources.list.d/armbian.list  
    If you’re using an apt proxy, then copy its configuration file too:
    # cp /etc/apt/apt.conf.d/*proxy etc/apt/apt.conf.d/  
     
    Step 9 - Edit or create required configuration files in the target system
     
    Perform the editing steps below using a text editor of your choice:
    Edit 'boot/armbianEnv.txt' so that the 'rootdev', 'console' and 'bootlogo' lines read as follows.  If you’ll be unlocking the disk via the serial console, then use 'console=serial' instead of 'console=display'. Note that enabling the serial console will make it impossible to unlock the disk from the keyboard and monitor, though unlocking via SSH will still work:
    rootdev=/dev/mapper/rootfs console=display bootlogo=false Edit 'etc/initramfs-tools/initramfs.conf'.  If your board will have a statically configured IP, add the following line to the end of the file, substituting the correct IP in place of 192.168.0.88:
    IP=192.168.0.88:::255.255.255.0::eth0:off If the board will be configured via DHCP, then edit the DEVICE line as follows:
    DEVICE=eth0 If host and target systems are both Debian buster, you may wish add some key modules to the initramfs to avoid a blank display at bootup time.  The easiest way to do this is to add all currently loaded modules as follows: # lsmod | cut -d ' ' -f1 | tail -n+2 > etc/initramfs-tools/modules Retrieve the SSH public key from the remote unlocking host and copy it to the target:
    # mkdir -p etc/dropbear-initramfs # rsync yourusername@remote_machine:.ssh/id_*.pub etc/dropbear-initramfs/authorized_keys If you want to unlock the disk from more than one host, then edit the authorized_keys file by hand, adding the required additional keys.
    Create 'etc/crypttab':
    # echo "rootfs UUID=$ROOT_UUID none initramfs,luks" > etc/crypttab Create 'etc/fstab':
    # echo '/dev/mapper/rootfs / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1' > etc/fstab # echo "UUID=$BOOT_UUID /boot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2" >> etc/fstab # echo 'tmpfs /tmp tmpfs defaults,nosuid 0 0' >> etc/fstab Create the dropbear configuration file:
    # echo 'DROPBEAR_OPTIONS="-p 2222"' > etc/dropbear-initramfs/config # echo 'DROPBEAR=y' >> etc/dropbear-initramfs/config If the target is Ubuntu bionic, then a deprecated environment variable must be set as follows:
    # echo 'export CRYPTSETUP=y' > etc/initramfs-tools/conf.d/cryptsetup  
    Set up automatic disk unlock prompt. Performing this optional step will cause the disk password prompt to appear automatically when you log in remotely via SSH to unlock the disk. Using your text editor, create the file 'etc/initramfs-tools/hooks/cryptroot-unlock.sh' with the following contents: #!/bin/sh if [ "$1" = 'prereqs' ]; then echo 'dropbear-initramfs'; exit 0; fi . /usr/share/initramfs-tools/hook-functions source='/tmp/cryptroot-unlock-profile' root_home=$(echo $DESTDIR/root-*) root_home=${root_home#$DESTDIR} echo 'if [ "$SSH_CLIENT" ]; then /usr/bin/cryptroot-unlock; fi' > $source copy_file ssh_login_profile $source $root_home/.profile exit 0 Save the file and execute the command:
    chmod 755 'etc/initramfs-tools/hooks/cryptroot-unlock.sh'  
     
    Step 10 - Chroot into the target system, install packages and configure
     
    Now chroot into the encrypted system.  All remaining steps will be performed inside the chroot:
    # chroot .  
    Install the cryptsetup package and the dropbear SSH server:
    # apt update # echo 'force-confdef' > /root/.dpkg.cfg # apt --yes install cryptsetup-initramfs dropbear-initramfs # for a buster or focal image # apt --yes install cryptsetup dropbear-initramfs # for a bionic image # rm /root/.dpkg.cfg  
    Make sure everything was included in the initramfs (all three commands should produce output):
    # lsinitramfs /boot/initrd.img* | grep 'usr.*cryptsetup' # lsinitramfs /boot/initrd.img* | grep dropbear # lsinitramfs /boot/initrd.img* | grep authorized_keys  
    Your work is finished! Exit the chroot and shut down the board:
    # exit # halt -p  
    Insert your freshly written SD card into the board’s main SD slot (or, if the target is an eMMC, just remove the SD card from that slot) and reboot.

    Unlock the disk by executing the following command on your remote unlocking machine, substituting the correct IP address if necessary:
    $ ssh -p 2222 root@192.168.0.88  
    If you performed step 9.10 above, the disk password prompt should appear automatically after login.  If not, you must enter the command 'cryptroot-unlock'.
     
    You may also unlock the disk from the target board’s console if you wish.  Note, however, that certain disk images (RockPi 4 buster mainline, for example) might give you a blank display at startup, so you’ll have to enter your disk password “blindly”.  This bug will hopefully be fixed in the future.

    If all went well, your root-filesystem encrypted Armbian system is now up and running!
  13. Like
    Werner reacted to Igor in Armbian 21.08 (Caracal) Release Thread   
    Manually or by driving our test rig?
     
     
     
  14. Like
    Werner reacted to balbes150 in Board Bring Up Station P1 rk3399, M1 rk3328   
    new version of Armbian  20210614 with core 5.10.43.
    Added support for analog audio and a standard remote control.
  15. Like
    Werner reacted to lanefu in Armbian 21.08 (Caracal) Release Thread   
    Cleaned up and sorted Jira Board

    https://armbian.atlassian.net/secure/RapidBoard.jspa?rapidView=2&selectedIssue=AR-572&atlOrigin=eyJpIjoiY2FjZTM3YjZmZDI2NDI0MmIzY2MzYzdmYzg3Nzc1YjIiLCJwIjoiaiJ9
  16. Like
    Werner reacted to jock in MX9 4GB - Allwinner h3   
    Well 4 gigabits are actually 512 megabytes.
    I guess they are just faking specs as they do often.
  17. Like
    Werner got a reaction from ghoul in RK3566 and Armbian   
    In terms of mainline support this should be possible if the device tree is known since lots of stuff for rk3568 has been spotted in the Linux ARM mailing list.
    However it seems like only initial support has been approved yet and is up to being released with 5.13.
     
  18. Like
    Werner reacted to ericde45 in Asus Tinkerboard on kernel 4.4.213-rockchip bricked after shutdown   
    i flashed file Armbian_21.05.1_Tinkerboard_buster_legacy_4.4.213_xfce_desktop.img.xz to SD
    i booted and followed boot log through serial , log above
     
    i got the error : ** File not found /boot/dtb/rk3288-tinker-s.dtb **
     
    so i get to the conclusion that the current 4.4.213 build for tinkerboard is broken.
    do you agree ?
     
    ----------------------------------------------------------------------------------------------------------
     
     
     
    U-Boot 2018.11-armbian (May 06 2021 - 19:47:58 +0000)
    Model: Tinker-RK3288
    DRAM:  2 GiB
    MMC:   dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0
    Loading Environment from EXT4... Card did not respond to voltage select!
    In:    serial
    Out:   serial
    Err:   serial
    Model: Tinker-RK3288
    Net:   eth0: ethernet@ff290000
    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
    3395 bytes read in 1 ms (3.2 MiB/s)
    ## Executing script at 00000000
    Boot script loaded from mmc 1
    161 bytes read in 1 ms (157.2 KiB/s)
    5829234 bytes read in 2450 ms (2.3 MiB/s)
    8580280 bytes read in 3588 ms (2.3 MiB/s)
    ** File not found /boot/dtb/rk3288-tinker-s.dtb **
    libfdt fdt_check_header(): FDT_ERR_BADMAGIC
    No FDT memory address configured. Please configure
    the FDT address via "fdt addr <address>" command.
    Aborting!
    286 bytes read in 1 ms (279.3 KiB/s)
    Applying kernel provided DT overlay rockchip-i2c1.dtbo
    No FDT memory address configured. Please configure
    the FDT address via "fdt addr <address>" command.
    Aborting!
    286 bytes read in 1 ms (279.3 KiB/s)
    Applying kernel provided DT overlay rockchip-i2c4.dtbo
    No FDT memory address configured. Please configure
    the FDT address via "fdt addr <address>" command.
    Aborting!
    311 bytes read in 1 ms (303.7 KiB/s)
    Applying kernel provided DT overlay rockchip-spi2.dtbo
    No FDT memory address configured. Please configure
    the FDT address via "fdt addr <address>" command.
    Aborting!
    537 bytes read in 2 ms (261.7 KiB/s)
    Applying kernel provided DT overlay rockchip-spidev2.dtbo
    No FDT memory address configured. Please configure
    the FDT address via "fdt addr <address>" command.
    Aborting!
    287 bytes read in 1 ms (280.3 KiB/s)
    Applying kernel provided DT overlay rockchip-uart1.dtbo
    No FDT memory address configured. Please configure
    the FDT address via "fdt addr <address>" command.
    Aborting!
    287 bytes read in 1 ms (280.3 KiB/s)
    Applying kernel provided DT overlay rockchip-uart2.dtbo
    No FDT memory address configured. Please configure
    the FDT address via "fdt addr <address>" command.
    Aborting!
    Error applying DT overlays, restoring original DT
    ** File not found /boot/dtb/rk3288-tinker-s.dtb **
    ## Loading init Ramdisk from Legacy Image at 21000000 ...
       Image Name:   uInitrd
       Image Type:   ARM Linux RAMDisk Image (gzip compressed)
       Data Size:    5829170 Bytes = 5.6 MiB
       Load Address: 00000000
       Entry Point:  00000000
       Verifying Checksum ... OK
    ERROR: Did not find a cmdline Flattened Device Tree
    Could not find a valid device tree
    SCRIPT FAILED: continuing...
    starting USB...
    USB0:   USB1:   scanning bus 0 for devices... cannot reset port 1!?
    cannot reset port 3!?
    5 USB Device(s) found
    scanning bus 1 for devices... 1 USB Device(s) found
           scanning usb for storage devices... 0 Storage Device(s) found
    Device 0: unknown device
    ethernet@ff290000 Waiting for PHY auto negotiation to complete....... done
    Speed: 1000, full duplex
    BOOTP broadcast 1
    BOOTP broadcast 2
    *** Unhandled DHCP Option in OFFER/ACK: 125
    *** Unhandled DHCP Option in OFFER/ACK: 125
    DHCP client bound to address 192.168.1.113 (457 ms)
    *** Warning: no boot file name; using 'C0A80171.img'
    Using ethernet@ff290000 device
    TFTP from server 192.168.1.1; our IP address is 192.168.1.113
    Filename 'C0A80171.img'.
    Load address: 0x800800
    Loading: T T T T T T T T T T
    Retry count exceeded; starting again
    missing environment variable: pxeuuid
    missing environment variable: bootfile
    Retrieving file: pxelinux.cfg/01-2c-4d-54-42-b1-16
    Speed: 1000, full duplex
    Using ethernet@ff290000 device
    TFTP from server 192.168.1.1; our IP address is 192.168.1.113
    Filename 'pxelinux.cfg/01-2c-4d-54-42-b1-16'.
    Load address: 0x100000
    Loading: T T T
     
     
  19. Like
    Werner reacted to Green Daddy in Boot from SSD using Hardkernel's Odroid HC4   
    Boot from SSD without SD card is currently not supported on HC4. However, it is easy to have only the boot loader on SD card (as @Werner stated above):
    - flash armbian image to SD Card
    - erase petitboot as stated above
    - boot armbian from SD Card
    - run nand-sata-install within armbian
    after this
    - only the boot loader rests on SD card (i.e. you need the SD card plugged in for it to be able to boot) - but no I/O on SD card after boot loader
    - OS root partition (and entire system) runs from SSD
    - any update updates boot loader and kernel where they actually reside - so no special precautions needed (despite the usual "update may break something")
     
    I am running on this setup and it works like a charm for me.
     
    Hope that helps
     
    Green Daddy
  20. Like
    Werner reacted to lanefu in Patch Management Process   
    But.... this is a great topic where we need to start working on a process / protocol for patches like this
  21. Like
    Werner reacted to lanefu in Armbian the Virtual Machine   
    Been dreaming of this one for a while.  Finally got a weekend to focus on it recently.  I'm hoping someone is eager to take what I've done and move It along some more.

    Here's what we have so far.

    * a linux 'family' called virtual.conf
    * a kernel config called linux-virtual-current.config
    * a board called virtual-qemu.wip
     
    The result is a full HVM accelerated armbian image with a kernel compiled with all the virtio drivers for disk, network and video.   Also a u-boot.bin made for qemu that can boot the image when used as the qemu bios/firmware
     
    I've ran it as a VM on ubuntu using plain qemu on a Ampere eMag box.. and using UTM (qemu) on Apple M1 in MacOS

    this is using u-boot, not uEFI.. and you need to copy the u-boot.bin manually from cache/sources/u-boot...../u-boot.bin and use it as your chosen bios for qemu.  I left some quick breadcrumbs on how to launch within the board config file.
     
    I want to keep the u-boot option, but obviously we need this to support uEFI booting to be viable for the masses.

    Next steps:

    * automatically resize and convert resulting image to qcow2 format
    * solve how to add cloud-init to image
    * solve for installing grubEFI for booting and whatever partition layout is needed
    * figure a proper way to write uboot to the image so thet qemu can boot without loading as a bios
    * strip extra hardware drivers out of kernel and make this thing lean

    PS Did I mention Desktop Works too?

     
     
     
  22. Like
    Werner reacted to Superkoning in Plans for RISC-V boards like BeagleV, Nezha RISC-V SBC and Allwinner D1 SBC?   
    FWIW: I'm an Armbian user, and, yes, I've done a few donations in the past.
  23. Like
    Werner reacted to lanefu in Plans for RISC-V boards like BeagleV, Nezha RISC-V SBC and Allwinner D1 SBC?   
    FYI your donation IS greatly appreciated. 
     
     I don't want the context of this conversation to convey the contrary. 
  24. Like
    Werner got a reaction from lanefu in IRC channels moved to Libera.chat   
    tl;dr: connect to irc.libera.chat and join #armbian
    ---------------------------------------------------------------
     
    Due to the weird stuff happening on Freenode we decided to move our channels to the recently founded Libera.chat network.
     
    The announcement thread in forums as well as our documentation have been updated accordingly.
    To make transition more comfortable a relay bot has been put in place to sync messages between the #armbian channel on both Freenode and Libera.
     
    For those who had project affiliation cloaks please drop me a message to get them reassigned. Be sure to have your nick registered with Nickserv beforehand.
     
    For more information about what happened use your favorite search engine or reddit and look for stuff like "freenode hostile takeover" or similar.
  25. Like
    Werner got a reaction from lanefu in very confused --> /etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx   
    https://github.com/armbian/build/commit/f0f10a5b68aff3c766f2e8790ac4ce9f3c3e2160