Search the Community

Showing results for tags 'tutorial'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements & first aid
    • Announcements
    • Board doesn't start
  • Community forums
    • Common issues / peer to peer technical support
    • Reviews, Tutorials, Hardware hacks
    • Help wanted
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker - supported boards and images only
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner A64, H5, H6 and H616
    • Armada A388, A3700
    • Amlogic S905(x), S922X
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Rockchip 3399
    • Other supported boards
  • Development
    • Development
  • TV Boxes's General Chat
  • TV Boxes's Reviews/Tutorials
  • TV Boxes's FAQ
  • TV Boxes's TV Boxes running Armbian
  • TV Boxes's Rockchip CPU Boxes
  • TV Boxes's Amlogic CPU Boxes
  • TV Boxes's Allwinner CPU Boxes
  • Android fanboys's Forums
  • Gaming on ARM's Reviews
  • Gaming on ARM's Issues
  • Kobol Forum's Helios4
  • Kobol Forum's Helios64

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP


Skype


Github


Location


Interests

  1. Canon provides source code for cups driver, but with some proprietary binary libs. This libs available only for x86. No way for direct compiling cnijfilter for ARM (and other architectures). But we have qemu! We can transparently run x86 executables on any other host architectures. Easy steps to run cnijfilter on ARM (or any other arch): - Build https://github.com/endlessm/cnijfilter-common for x86 - Copy all needed x86 libs using recursive ldd. And copy it to /usr/lib/bjlib/ - Patch all executables: set interpreter to /usr/lib/bjlib/x86/ld-linux.so.2 and rpath to /usr/lib/bjlib/ - Install these patched packages to ARM system - Install qemu-user and qemu-user-binfmt (or qemu-arm-static) You do not need to do this manually. I have implemented an automated build system: https://github.com/Azq2/cnijfilter-arm-build All you need is any x86 machine to do the build. How to use 1. On any x86 machine: # Install dependencies sudo apt install debootstrap git util-linux # Get build system git clone https://github.com/Azq2/cnijfilter-arm-build # Start building cd cnijfilter-arm-build sudo ./build.sh build # Get .deb packages ls -lah ./result/full ls -lah ./result/light After build we have two variants of packages: full and light Item Full Light PPD files + + CUPS filters + + CUPS backends + - lgmon + - canon-maintenance + - cngpij + - cngpijmnt + - cnijlgmon2 + - cnijnetprn + - cnijnpr + - docs + - In most cases, a light package is completely sufficient: - We don't need canon usb backend, because cups have builtin USB support - We don't need canon network backend, because cups have builtin BJNP support (package cups-backend-bjnp) - Other canon maintenance utils are useless (in my opinion) 2. Copy .deb from result/light or result/full to your ARM machine. 3. On your ARM machine: # Install dependencies sudo apt install qemu-user qemu-user-binfmt # or sudo apt install qemu-user-static # Install common for all printers package sudo dpkg -i cnijfilter-common.deb # Install printer-specific package # Choose right package for your printer! e400series only for reference! sudo dpkg -i cnijfilter-e400series.deb 4. Done. You can now configure CUPS. Security with apparmor (optional) CUPS filters don't need any specific permissions. Create file /etc/apparmor.d/cnijfilter-filters with contents: #include <tunables/global> /usr/bin/bjfilter* { #include <abstractions/base> @{PROC}/sys/vm/mmap_min_addr r, } /usr/bin/cif[a-z]*[0-9d]* { #include <abstractions/base> @{PROC}/sys/vm/mmap_min_addr r, } /usr/lib/cups/filter/{cmdtocanonij,pstocanonbj,pstocanonij} { #include <abstractions/base> @{PROC}/sys/vm/mmap_min_addr r, } Then restart apparmor: sudo systemctl reload apparmor sudo aa-enforce cnijfilter-filters Note: this minimal file full coverage all executables in light package. For full package you need write additional rules by yourself.
  2. Dear Armbian community, although I'm using Armbian a lot, I never had to submit anything to this forum (fortunately, because it works so well :-)), On my PC I've experienced lags on heavy IO operations. After a short dig into available information, I found a useful Cloudflare article on Kernel queues together with dm-crypt. A good & short summary on possible actions for users can be found here: https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_performance Enabling the no-read-workqueue & no-write-workqueue options helped a lot! As I'm using a RockPi4 with the NVMe SSD with encryption, I thought this should apply to my SBC as well. Unfortunately, Armbian/Debian Buster uses cryptsetup v2.1.0 which does NOT support these options. According to the changelog, this option was introduced in v2.3.4: https://gitlab.com/cryptsetup/cryptsetup/-/blob/master/docs/v2.3.4-ReleaseNotes As Armbian uses a kernel > 5.9, the kernel infrastructure should be available. Fortunately, crypsetup v2.3.4 exists in the buster-backports repo: https://packages.debian.org/buster-backports/cryptsetup Solution: # sudo apt install cryptsetup/buster-backports
  3. Hi all. In this video I show how to install Open Media Vault on your SBC with Armbian Buster. I've used the Odroid HC4, this is the same for any board you'd like to use. Here my video. Greetings. NicoD
  4. Hi all. I've just finished a new video where I show how to build Armbian images on your ARM SBC. Here is the video. All have a jolly good Christmas or other holiday or normal day.
  5. Focal / root on eMMC / ZFS on hdd / LXD / Docker I received my Helios64 yesterday, installed the system, and decided to write down my steps before I forget them. Maybe someone will be interested. :-) Preparation: Assembly your box as described here. Download Armbian Focal image from here and flash it to SD card. You may use Ether. Insert the SD card to your Helios64 and boot. After 15-20s the box should be accessible via ssh. (Of course you have to find out it's IP address somehow. For example check your router logs or use this.) First login: ssh root@IP Password: 1234 After prompt - change password and create your daily user. You should never login as root again. Just use sudo in the future. :-) Note: The auto-generated user is member of "disk" group. I do not like it. You may remove it so: "gpasswd -d user disk". Now move your system to eMMC: apt update apt upgrade armbian-config # Go to: System -> Install -> Install to/update boot loader -> Install/Update the bootloader on SD/eMMC -> Boot from eMMC / system on eMMC You can choose root filesystem. I have chosen ext4. Possibly f2fs might be a better idea, but I have not tested it. When finished - power off, eject the sd card, power on. Your system should now boot from eMMC. If you want to change network configuration (for example set static IP) use this: "sudo nmtui". You should also change the hostname: sudo armbian-config # Go to: Personal -> Hostname ZFS on hard disk: sudo armbian-config # Go to Software and install headers. sudo apt install zfs-dkms zfsutils-linux # Optional: sudo apt install zfs-auto-snapshot # reboot Prepare necessary partitions - for example using fdisk or gdisk. Create your zfs pool. More or less this way: sudo zpool create -o ashift=12 -m /mypool -mypool mirror /dev/disk/by-partuuid/abc123 /dev/disk/by-partuuid/xyz789 Reboot and make sure the pool is imported automatically. (For example by typing "zpool status".) You should now have working system with root on eMMC and ZFS pool on HDD. Docker with ZFS: Prepare the filesystem: sudo zfs create -o mountpoint=/var/lib/docker mypool/docker-root sudo zfs create -o mountpoint=/var/lib/docker/volumes mypool/docker-volumes sudo chmod 700 /var/lib/docker/volumes # Option: If you use zfs-auto-snapshot, you might want to consider this: sudo zfs set com.sun:auto-snapshot=false mypool/docker-root sudo zfs set com.sun:auto-snapshot=true mypool/docker-volumes Create /etc/docker/daemon.json with the following content: { "storage-driver": "zfs" } Add /etc/apt/sources.list.d/docker.list with the following content: deb [arch=arm64] https://download.docker.com/linux/ubuntu focal stable # deb-src [arch=arm64] https://download.docker.com/linux/ubuntu focal stable Install Docker: sudo apt install apt-transport-https ca-certificates curl gnupg-agent software-properties-common curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add - sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io #You might want this: sudo usermod -aG docker your-user Voila! Your Docker should be ready! Test it: "docker run hello-world". Option: Install Portainer: sudo zfs create rpool/docker-volumes/portainer_data # You might omit the above line if you do not want to have separate dataset for the docker volume (bad idea). docker volume create portainer_data docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce Go to http://yourip:9000 and configure. LXD with ZFS: sudo zfs create -o mountpoint=none mypool/lxd-pool sudo apt install lxd sudo lxc init # Configure ZFS this way: Do you want to configure a new storage pool (yes/no) [default=yes]? yes Name of the new storage pool [default=default]: Name of the storage backend to use (dir, btrfs, ceph, lvm, zfs) [default=zfs]: zfs Create a new ZFS pool (yes/no) [default=yes]? no Name of the existing ZFS pool or dataset: mypool/lxd-pool [...] #You might want this: sudo usermod -aG lxd your-user # Option: If you use zfs-auto-snapshot, you might want to consider this: sudo zfs set com.sun:auto-snapshot=false mypool/lxd-pool sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/containers sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/custom sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/virtual-machines That's it. Lxd should work now on ZFS. :-)
  6. Here are the instructions to run Htop remotely using a web browser. I often use Htop to monitor the health of my boards and servers (amd64). It is a good tool for the sys admin to monitor the servers in real-time without much resources and it is not very intrusive. Recipe 1 - Clone shellinabox root@cubieboard2:~# git clone https://github.com/shellinabox/shellinabox Cloning into 'shellinabox'... remote: Enumerating objects: 3073, done. remote: Total 3073 (delta 0), reused 0 (delta 0), pack-reused 3073 Receiving objects: 100% (3073/3073), 4.31 MiB | 1.89 MiB/s, done. Resolving deltas: 100% (2418/2418), done. root@cubieboard2:~# cd shellinabox/ 2 - Build and install shellinabox shellinabox makefile is outdated for OpenSSL 1.1.y, so we need to bypass the linking process and do it manually. During the config process you get some errors, bypass the error by doing like so: root@cubieboard2:~/shellinabox# apt-get install libtool root@cubieboard2:~/shellinabox# autoreconf -i root@cubieboard2:~/shellinabox# autoconf root@cubieboard2:~/shellinabox# autoreconf -i root@cubieboard2:~/shellinabox# ./configure root@cubieboard2:~/shellinabox# make 3 - Bypass the linking error During the link process you get a missing openssl 1.1 lib, we then manually link shellinabox: root@cubieboard2:~/shellinabox# gcc -g -std=gnu99 -Wall -Os -o shellinaboxd shellinabox/shellinaboxd.o shellinabox/externalfile.o shellinabox/launcher.o shellinabox/privileges.o shellinabox/service.o shellinabox/session.o shellinabox/usercss.o ./.libs/liblogging.a ./.libs/libhttp.a -ldl -lutil -lssl -lcrypto 4 - Running Htop on the Browser I choose not to install shellinabox, just run a service to be able to run and make Htop available on the Browser. Tested on Google Chromium and FireFox (linux). root@cubieboard2:~/shellinabox# ./shellinaboxd -t -b -p 8888 --no-beep -s '/htop_app/:alex:alex:/:htop -d 10' where 8888 is the port. alex:alex is the user:group to run Htop with. Use yours [user] and [group]. Note: for security reason if you run with nobody:nogroup you wont be able to add or change any config on the Htop. Now fire the browser at http://ip_address:8888/htop_app/ and that's it, enjoy. 5 - Credits stackverflow, user ofstudio. Screenshot:
  7. I got my hands on a "Set 9" Orange Pi Lite + GC2035 camera a while back and I've finally been able to put together a self-contained object detection device using Tensorflow, without sending any image data outside for processing. Basically, its a python Flask application that captures frames from the camera using a GStreamer pipeline. It runs them through a Tensorflow object detection model and spits out the same frame with extra metadata about objects it found, and renders a box around them. Using all four cores of the H2 it can do about 2-3 fps. The app keeps track of the count of all object types it has seen and exposes the metrics in prometheus format, for easy creation of graphs of what it sees over time with Grafana I'll explain some of the more interesting aspects of how I got this to work here in case anyone else wants to try to get some use out of this very inexpensive hardware, and I am grateful to the many posts on this forum that helped me along the way! Use a 3.4 kernel with custom GC2035 driver Don't bother with anything new - the GC2035 was hopeless on any newer builds of Armbian I tried. The driver available at https://github.com/avafinger/gc2035.git provided far better image quality. After installing the updated GC2035, I run the following to get the camera up and running: sudo sunxi-pio -m "PG11<1><0><1><1>" sudo modprobe gc2035 hres=1 sudo modprobe vfe_v4l2 Install Tensorflow lite runtime Google provides a tensorflow runtime as a binary wheel built for python 3.5 armv7. When pip installing, expect it to take 20 minutes or so as it will need to compile numpy (the apt repo version isn't recent enough) wget https://github.com/google-coral/pycoral/releases/download/release-frogfish/tflite_runtime-2.5.0-cp35-cp35m-linux_armv7l.whl sudo -H pip3 install tflite_runtime-2.5.0-cp35-cp35m-linux_armv7l.whl Build opencv for python 3.5 bindings This was something I tried everything I could to avoid, but I just could not get the colour conversion from the YUV format of the GC2035 to an RGB image using anything else I found online, so I was dependent on a single color-conversion utility function. To build the 3.4.12 version for use with python (grab lunch - takes about 1.5 hours :-O ) cmake -DCMAKE_INSTALL_PREFIX=/home/atomic/local -DSOFTFP=ON \ -DBUILD_TESTS=OFF -D BUILD_PERF_TESTS=OFF -D BUILD_opencv_python2=0 \ -D BUILD_opencv_python3=1 -D WITH_GSTREAMER=ON \ -D PYTHON3_INCLUDE_PATH=/usr/include/python3.5 .. make -j 4 make install # Check that ~/local/lib/python3.5/dist-packages should now have the cv2 shlib export PYTHONPATH=/home/atomic/local/lib/python3.5/dist-packages Build gstreamer plugin for Cedar H264 encoder This is required to get a working gstreamer pipeline for the video feed: git clone https://github.com/gtalusan/gst-plugin-cedar ./autogen.sh sudo make install # When trying against a pipc I had to copy into .local to get gstreamer to recognise it cp /usr/local/lib/gstreamer-1.0/libgst* ~/.local/share/gstreamer-1.0/plugins/ # Confirm that plugin is installed: gst-inspect-1.0 cedar_h264enc Processing images The full app source is on github, but the more interesting parts that took me some time to figure out were about getting python to cooperate with gstreamer: Frames from the camera arrive to python at the end of the pipeline as an appsink. The Gstreamer pipeline I configured via python was: src = Gst.ElementFactory.make("v4l2src") src.set_property("device", "/dev/video0") src.set_property("do-timestamp", 1) filt = Gst.ElementFactory.make("capsfilter") filt.set_property("caps", Gst.caps_from_string("video/x-raw,format=NV12,width=800,height=600,framerate=12/1")) p1 = Gst.ElementFactory.make("cedar_h264enc") p2 = Gst.ElementFactory.make("h264parse") p3 = Gst.ElementFactory.make("rtph264pay") p3.set_property("config-interval", 1) p3.set_property("pt", 96) p4 = Gst.ElementFactory.make("rtph264depay") p5 = Gst.ElementFactory.make("avdec_h264") sink = Gst.ElementFactory.make("appsink", "sink") pipeline_elements = [src, filt, p1, p2, p3, p4, p5, sink] sink.set_property("max-buffers", 10) sink.set_property('emit-signals', True) sink.set_property('sync', False) sink.connect("new-sample", on_buffer, sink) This pipeline definition causes a callback on_buffer to be called every time a frame is emitted from the camera: def on_buffer(sink: GstApp.AppSink, data: typing.Any) -> Gst.FlowReturn: # Sample will be a 800x900 byte array in a very frustrating YUV420 format sample = sink.emit("pull-sample") # Gst.Sample ... conversion to numpy array # rgb is now in a format that Pillow can easily work with # These two calls are what you compiled opencv for 1.5 hours for :-D rgb = cv2.cvtColor(img_arr, cv2.COLOR_YUV2BGR_I420) rgb = cv2.cvtColor(rgb, cv2.COLOR_BGR2RGB) Once you have a nice pillow RGB image, it's easy to pass this into a Tensorflow model, and there is tons of material on the web for how you can do things like that. For fast but not so accurate detection, I used the ssdlite_mobilenet_v2_coco pretrained model, which can handle about 0.5 frames per second per core of the H2 Allwinner CPU. There are some problems I still have to work out. Occasionally the video stream stalls and I haven't figured out how to recover from this without restarting the app completely. The way frame data is passed around tensorflow worker processes is probably not ideal and needs to be cleaned up, but it does allow me to get much better throughput using all four cores. For more details, including a detailed build script, the full source is here: https://github.com/atomic77/opilite-object-detect
  8. 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!
  9. Hi all, Maybe there are a lot people who got this working but for me was today the day. I buyed a time a go a cheap but fast NVME SSD from Aliexpress. The smallest one a 128GB. I have also a 512GB in my laptop and for the price they are really good. But i needed also a USB-NVME external housing. That is the Ugreen NVME 10GBps to USB adapter. In very short but i will explain more in the future. 1. Flash a MicroSD card with your favourite Armbian to the MicroSD. Update with sudo apt-get update. Also with a SSH session not a problem. 2. Place the USB disk in a USB 3.0 port of the Orange Pi. By the OrangePi 4 it´s the blue one on the top. 3. run the command lsusb 4. Notice the dev id. In my situation it´s 174c:2362 5. Run the command with off course your dev id. Notice the :u at the end that must be added. echo "174c:2362:u" | sudo tee /sys/module/usb_storage/parameters/quirks 6. Replug the USB drive. I see the activity led on the drive short flashing. 7. Run the following command sudo nano /boot/armbianEnv.txt 8. Add the dev id after usbstoragequirks and close and save the file. By my system is the complete row: usbstoragequirks=174c:2362:u,0x2537:0x1066:u,0x2537:0x1068:u 7. Logout and in with your root account! This is very important. With sudo is this not possible. 8. Open armbian-config. Select System->Update Bootloader-> Boot from SD, root from NVME/eMMC etc. 9. The tool will ask you the directory to the disk. Most of time is this standard correct. You get a question about the filesystem. Select EXT4. You get a warning that the disk would be erased. Click on Ok. 10. Wait patiently to finish 11. And without failures you could click reboot and boot from USB/NVME! By my is the Orange:Pi a lot faster! Booting, updating copy files. Everything. I am really happy with this!
  10. In this tutorial we build a custom .config for OrangePiOnePlus board, eg: to remove blutooth, WiFi and or USB3.x support since the hardware is not onboard, alternatively you can adjust settings to your needs which is not in the default .config. The section mentions, if file " userpatches/linux-$KERNELFAMILY-$KERNELBRANCH.config " exists, it will be used instead of default one from " config ". This means for the OPiOnePlus : " linux-sunxi64-dev.config " should be created, but please note "dev" is just one of the three options available, which are: " current ", " legacy " and " dev " The default config files are located in : " /armbian/config/kernel " and thus also holds a "linux-sunxi64-dev.config " config file. # #If user-provided kernel .config file IS NOT present yet # cd ~ git clone --depth 1 https://github.com/armbian/build armbian cd armbian ./compile.sh BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes EXTRAWIFI=no BOARD=orangepioneplus Yet rename ".config" and Save to " ~/userpatches/linux-sunxi64-dev.config " , find attached a screenshot # #If user-provided kernel .config file IS present # <script> cp -p ~/armbian/userpatches/linux-sunxi64-dev.config ~/ sudo rm -rf armbian git clone --depth 1 https://github.com/armbian/build armbian mkdir ~/armbian/userpatches cp -p ~/linux-sunxi64-dev.config ~/armbian/userpatches/ </script> Above can be scripted so you do not need to worry if for some reason you need to remove and rebuild your " armbian " directory from scratch Rest would be ( assuming your kernel has been customised to your needs ): cd armbian ./compile.sh BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no EXTRAWIFI=no BOARD=orangepioneplus Hope this addition to user-provided-kernel-config explains the idea " in depth " . Happy configuring :-)
  11. Today I did compile the NeXT-Cube/Station Emulator Previous 2.2 ( http://previous.alternative-system.com/index.php/build ) on my NanoPi A64 (with installed Desktop-option for using SDL) Installing the dependencies and compiling Previous 2.2 has been done with the follwing commands ( while compiling there were MUCH warnings ) : apt install zlib1g zlib1g-dev libsdl2-2.0-0 libsdl2-dev libpng16-16 libpng-dev libpcap0.8 libpcap0.8-dev apt install g++ cmake subversion cd /home/guido old Previous v1.8 : ===================== svn checkout svn://svn.code.sf.net/p/previous/code/branches/branch_realtime previous-code actual Previous v2.2: ===================== svn checkout https://svn.code.sf.net/p/previous/code/trunk previous-code cd previous-code ./configure make Run the program cd src ./Previous For booting the emulation you need a SCSI-HDD-dd-image of NeXTstep 3.3 You can get it at https://winworldpc.com/product/nextstep/3x inside the file Nextstep 3.3 HD Image With Previous The NanoPi A64 gets only 50-100% emulation speed of an original NeXT A little bit more while using a 68030 CPU and less on the 68040 CPU emulation. PS: because the emulator is using SDL for gfx you need to start the emulator from a graphical terminal on the NanoPi...
  12. Hi there, i hope you can help me as i saw there are a few Wireguard Users here as well. I did setup Armbian 20.05.4 Buster on my Cubietruck and configured Wireguard. After a few mistakes the connection from outside (iOS Client) is stable but very slow. I went to the obvious roads and found the MTU setting on the client side could be an issue as well some PostUp command parameters can improve performance. But for any reason my wireguard doesn´t want to accept anything with PostUp, Safeconfig etc in my wg0.conf file: Parsing error. But without that been solved i assume i can´t work on the Performance improvement. Here a few lines of code showing the relevant config Files and the Error: root@cubietruck:/etc/wireguard# cat wg0.conf [Interface] ListenPort=40404 PrivateKey=blablablaServerKey PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; iptables -D FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT [Peer] PublicKey=blablabla Public Key AllowedIPs=192.168.42.100,fd00:42::100 root@cubietruck:/etc/wireguard# cat clients/omasiphone.conf [Interface] PrivateKey=blablablaclientkey Address=192.168.42.100/24,fd00:42::100/64 DNS=1.1.1.1,2606:4700:4700::1111 MTU = 1412 PostUp = ip route add SERVER_PUBLIC_IP/32 via 192.168.1.200 dev eth0; iptables -A FORWARD -i wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT; iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu PostDown = ip route del SERVER_PUBLIC_IP/32 via 192.168.1.200 dev eth0; iptables -D FORWARD -i wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT; iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu [Peer] PublicKey=blablablaclientkey Endpoint=ganzgeheim.myfritz.net:40404 AllowedIPs=0.0.0.0/0,::/0 root@cubietruck:/etc/wireguard# wg setconf wg0 /etc/wireguard/wg0.conf Line unrecognized: `PostUp=iptables-AFORWARD-iwg0-jACCEPT;iptables-tnat-APOSTROUTING-oeth0-jMASQUERADE;iptables-AFORWARD-ieth0-mstate--stateRELATED,ESTABLISHED-jACCEPT' Configuration parsing error Can you help me here a bit?
  13. It seems that the actual install routine of Pihole doenst detect buster with kernel 5.8 correctly. At "my" normal install command "curl -sSL https://install.pi-hole.net | bash" I did get [✗] Unsupported OS detected: Armbian 20.08.0-trunk Buster https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems e.g: If you are seeing this message on a fresh install, you can run: 'curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash' If you are seeing this message after having run pihole -up: 'PIHOLE_SKIP_OS_CHECK=true sudo -E pihole -r' (In this case, your previous run of pihole -up will have already updated the local repository) but after giving (as written above) the install command with the option "to not check the OS" curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash the installation went fine
  14. On some devices (mostly headless) like Pine A64 LTS and other SBCs with Allwinner SoCs is Lima blacklisted by default or not supported by distribution. For getting Lima work, you need to use distribution, which have already Mesa with Lima support (Mesa 20.1+) (or compile latest Mesa from sources, but this is not included in this tutorial). At the moment of writing, it's Ubuntu Focal and Debian Bullseye. I personally prefer Debian more, so in my case, download Debian Bullseye image for your SBC and burn it into the board. After booting into your board, find file named /etc/modprobe.d/blacklist-NAMEOFYOURSBC.conf (for me it's blacklist-pinea64-lts.conf), find line with: blacklist lima and comment it by adding # at begin of this line, so it will look like this: # blacklist lima Reboot the device and Lima should work finely. If you will have any questions or issues, let me know - gamiee
  15. Hi, I've been running Octoprint on armbian for several months with good results of a couple of printers with good performance no relevant problems. Installation process is not complex but I decided to build a simple a plug&play meta-distribution like OctoPi for Rpi boards but based on armbian so it can be used potentially in any of the supported boards. I started with the popular Opi Zero as it is really cheap and the four cores of the H2+ processor handle perfectly a 3d printer load and is 3 times cheaper than a typical RPI3B that octoPi requires. You can find it here: https://github.com/ludiazv/octocitrico Built-in features are: Core (installed and enabled): Optimized armbian Debian buster. Latest stable octoprint version. Selection of top octoprint plugins. HAProxy with self signed keys for ssl access. Avahi service: Bonjur addvertisement (this enable to acces with host-name.local via ssh or http/s) SSH console access. USB OTG console access (if available in the board) Enabled i2c-dev,spidev (if available on the board) 3D printer related software (installed but disabled): Klipper PlatformIo core for building 3D printer firmware. Marlin 1.1.x & Marlin 2.x.x firmware (bugfix versions) Extras (installed but disabled): MPGStreamer USB camera support (experimental) SMB shares to remote edit configuration files from a remote PC. Feedback and contributions are welcome. Thanks armbian guys for the awesome work you do.
  16. I've used Zabbix professionally and at home to monitor servers, IoT, and IP devices. I've built scripts for the server and client to automate the install process including moving the MySQL database, so you can locate it to a NFS mount instead of serving the database from the slower SD card. The deb packages do not work for ARM, so you have to build it from source using my scripts. Install Zabbix
  17. If you know the movie "Wargames" then you may know the computer of "David Lightman" a IMSAI 8080 Udo Munk did create the software z80pack (last version from 2017 v1.36 at https://www.autometer.de/unix4fun/z80pack/ ) which does include - IMSAI 8080 - Altair - Cromemco Z1 and - cpmsim Emulation. Against the text based cpmsim emulation the other features a graphical frontpanel with "blinken lights" Yesterday I did try to compile/start my favourite IMSAI 8080. I did follow the instructions - which I collect and wrote for me - see attached to this message. But yesterdy I only got limited success (after many "bad" compiles with missing dependencies) in starting the IMSAI 8080 emulation. I did get the graphical frontend *yeah* - but after POWERON/RUN the computer I didnt get any terminal-output After MANY retries I did give up Today I did the same compile-session on a PC with Ubuntu MATE 20.04LTS and it did work in the first try At first I got no idea what wasnt working....but then I discovered that - when moving the graphical frontpanel - the terminal-output was written VERY SLOWLY to the terminal-screen *Aha* Because the garphical frontpanel seem to work perfectly (and did also compile very well) I searched inside the directorys of imsaisim and found in the "conf"-directory the file system.conf There in system.conf is a line where the FPS-rate of the frontpanel as default is configured to 60 FPS (Frames per second). While taking a look at htop the NanoPi A64 (where my armbian buster Desktop does run) the cpu-utilization is near 90% So my gut instinct did tell me thats to much and the NanoPi has to much work with the frontpanel than writing to the terminal. I changed the framerate in - for the IMSAI 8080: ~/z80pack-1.36/imsaisim/conf/systemconf - for the Altair: ~/z80pack-1.36/altairsim/conf/systemconf - for the Cromemco Z1: ~/z80pack-1.36/cromemcosim/conf/systemconf to # front panel framerate fp_fps 10 After that change all 3 emulators with graphical frontend did startup and give output on the terminal I contacted Udo Munk via email about this topic and he already knew it He wrote that he had implemented the FPS option, because some lower-spec systems had problems to achieve the power for producing a framerate of 60 FPS for the frontpanel. Here my write-up / documentation how I did compile / successfully start the IMSAI 8080 emulation: (many thanks to John Kennedy from the FB-Group Altair 8800 for double-checking my instructions!) ====================================================================== My normal evironment for compiling source: ====================================================================== apt install gcc libncurses5-dev liblua5.3-dev git make zip unzip -y ====================================================================== Getting z80pack-source: ====================================================================== cd ~ wget https://www.autometer.de/unix4fun/z80pack/ftp/z80pack-1.36.tgz tar -xvf z80pack-1.36.tgz cd ~/z80pack-1.36/ ====================================================================== Dependencies named by z80pack: ====================================================================== libjpeg X11 OpenGL c++ compiler (g++) libpthread ====================================================================== Packages for the z80pack-dpendencies: ------------------------------------- apt install libjpeg-dev x11-common libpthread-stubs0-dev libxmu-dev apt install mesa-common-dev z80asm libglu1-mesa-dev freeglut3-dev ====================================================================== ==> <== ==> I built all packages of z80pack in the following order: <== ==> <== ==> ATTENTION: for some commands you may have to use sudo <== ====================================================================== 1.) FRONTPANEL ====================================================================== cd ~/z80pack-1.36/frontpanel/ make -f Makefile.linux NOTE: Be sure to copy libfrontpanel.so to a shared library path! NOTE: cp ~/z80pack-1.36/frontpanel/libfrontpanel.so /usr/lib make -f Makefile.linux clean ====================================================================== 2.) CPMSIM ====================================================================== cd ~/z80pack-1.36/cpmsim/srcsim/ make -f Makefile.linux make -f Makefile.linux clean ====================================================================== 3.) CPMSIM-TOOLS ====================================================================== if you are user root: mkdir /root/bin if you are user pi: mkdir /home/pi/bin cd ~/z80pack-1.36/cpmsim/srctools make make install NOTE: (does install in /root/bin/) NOTE: Tools installed in /root/bin, make sure it is NOTE: included in the systems search PATH NOTE: export PATH=$PATH:/root/bin NOTE: or NOTE: export PATH=$PATH:/home/pi/bin make clean ====================================================================== 4.) ALTAIRSIM ====================================================================== cd ~/z80pack-1.36/altairsim/srcsim/ make -f Makefile.linux make -f Makefile.linux clean NOTE: change framerate to "fp_fps 10" in NOTE: ~/z80pack-1.36/altairsim/conf/system.conf ====================================================================== 5.) CROMEMCOSIM ====================================================================== cd ~/z80pack-1.36/cromemcosim/srcsim/ make -f Makefile.linux make -f Makefile.linux clean NOTE: change framerate to "fp_fps 10" in NOTE: ~/z80pack-1.36/cromemcosim/conf/system.conf ====================================================================== 6.) IMSAISIM ====================================================================== cd ~/z80pack-1.36/imsaisim/srcsim/ make -f Makefile.linux make -f Makefile.linux clean NOTE: change framerate to "fp_fps 10" in NOTE: ~/z80pack-1.36/imsaisim/conf/system.conf ====================================================================== PREPARE 1st start of imsaisim; ====================================================================== cp ~/z80pack-1.36/frontpanel/libfrontpanel.so /usr/lib cd ~/z80pack-1.36/imsaisim rm conf ln -s conf_2d conf export PATH=$PATH:/root/bin NOTE: maybe add the export-command to your ~/.bashrc ====================================================================== START of IMSAI 8080 CPM v2.2 from the x-terminal on the desktop (needs to be a "x-terminal) for connecting to the X-Server for creating the graphical frontpanel: ====================================================================== ./cpm22 NOTE: maybe root has to give access-rights: NOTE: chmod -R 666 ~/z80pack-1.36/imsaisim/disks NOTE: on the x-terminal root and the to the desktop logged in user can NOTE :start the application and connect to the X-server on a NOTE: SSH-terminal ONLY the to the desktop logged in user can start the NOTE: application and connect to the X-server to give root access to NOTE: the X-server from a SSH-terminal the he to the desktop logged NOTE: in user has to give root access via the xhost command: NOTE: xhost SI:localuser:root ====================================================================== POWER-UP the IMSAI 8080 in the graphical frontpanel ====================================================================== Press "POWER ON " upper part on the first switch on the right side (POWER ON / POWER OFF) Press "RUN" upper part of the third (red) switch (RUN/STOP) ====================================================================== Exit the IMSAI 8080 ====================================================================== Enter "bye" on the CP/M-commandline OR press "POWER OFF " lower part on the first switch on the right side (POWER ON / POWER OFF) OR close the graphical frontpanel with the close button X (Window-Manager-close) Pictures (screenshots are done with Mirage as you can see) of my "success"
  18. For "retro-reasons" I would like to SSH from my old Windows 98SE PC via putty 0.63 ( which is the last known to work under Windows98SE ) into armbian. This did work fine until armbian bullseye dev with kernel 5.6.8, because here we get the "new" openssh-serve 8.2p1: armbian bullseye kernel 5.6.8 openssh-server 1:8.2p1-4 arm64 secure shell (SSH) server, for secure access from remote machines before bullseye we had with armbian buster and so on the "older" open-ssh-server <=7.9p1 (where we didnt got this problem) armbian buster kernel 5.6.8 openssh-server 1:7.9p1-10+deb10u2 arm64 secure shell (SSH) server, for secure access from remote machines with open-ssh-server 8.2p1 there was a "little" change: https://www.openssh.com/releasenotes.html OpenSSH 8.2/8.2p1 (2020-02-14) Potentially-incompatible changes ================================ * ssh(1), sshd(8): this release removes diffie-hellman-group14-sha1 from the default key exchange proposal for both the client and server. So the old putty 0.63 ( which is the last known to work under Windows 98 ) does produce the error-message: couldn't agree a key exchange algorithm After comparing many many configs and commands (also ssh -Q kex) the solution "only" was nano /etc/ssh/sshd_config # put at the end of /etc/sshd_config KexAlgorithms +diffie-hellman-group14-sha1 /etc/init.d/ssh restart Maybe this will help someone also using a older putty or other SSH-Client. With a newer version of putty on newer Windows there was no problem with that
  19. Tested this on clearfog base, banana pi m64, banana pi m2+ ## Building and providing The elastic team doesn't provide deb packages for ARM devices. But together with docker, we're able to build the main executable for it. We will create a build directory which includes anything to install filebeat on a ARM device. So please stay inside the build directory the whole time you are using this tutorial. mkdir build && cd $_ ## Prepare source code First we will download, check and extract the source code of filebeat. Source: https://www.elastic.co/downloads/past-releases/filebeat-7-6-2 wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.6.0-linux-x86.tar.gz wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.6.0-linux-x86.tar.gz.sha512 sha512sum filebeat-7.6.0-linux-x86.tar.gz Extract and prepare tar xfz filebeat-7.6.0-linux-x86.tar.gz --transform 's/filebeat-7.6.0-linux-x86/filebeat-latest/' ## Using docker Install docker on any machine you want. We use a host with Debian Buster installed. ### Install docker on a Debian Buster x64 machine sudo apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common wget -q -O - https://download.docker.com/linux/debian/gpg | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian stretch stable apt update sudo apt install docker-ce Instantiate a go container for cross-compilation (Debian Buster x64) Using latest docker go image docker run -it --rm -v `pwd`:/build golang:1.14 /bin/bash Inside the "go" docker container create filebeat for arm modules.listand arm64 go get github.com/elastic/beats cd /go/src/github.com/elastic/beats/filebeat/ git checkout v7.6.0 GOARCH=arm go build cp filebeat /build/filebeat-arm GOARCH=arm64 go build cp filebeat /build/filebeat-arm64 exit You can find the filebeat executeable inside your build directory. Leave it there for the moment. ## Download installation scripts I wrote an install script and collected a few files from other filebeat installations and uploaded them to github.com. You can find any information on the github repository itself. So we will clone the repository to the build directory. git clone https://github.com/rothirschtec/RT-Blog-elastic.git ## Filebeat configuration Now you have to copy the filebeat.yml so that that the install.sh we'll use later on can move it to the right place. cp filebeat-latest/filebeat.yml my-filebeat.yml and change it to your needs vi my-filebeat.yml ## Other configurations There are other configurations that might interests you. cp filebeat-latest/modules.d/YOUR_MODULE.yml.disabled my-YOUR_MODULE.yml Change this files too vi my-YOUR_MODULE.yml The install script will loop through all .yml files starting with my- and will copy them to the right direction ## Ready for installation The build directory is ready to use. You are able to upload the build directory to a ARM server of your choice and execute the install.sh there. rsync -av --exclude={".git","*.tar.gz","*.tar.gz.sha512"} ../build/ server-of-your-choice:/opt/build/ ssh server-of-your-choice cd /opt/build/ bash /opt/build/RT-Blog-elastic/install.sh rm -rf /opt/build/ ## Modules You're able to enable modules with the installation script. Create a file called modules.list inside the build directory and write the modules separated by whitespaces like iptables system apache
  20. Hi, There's been a few guides around on how to get RDP working with Armbian so you can login from your Windows or other PC. Some solutions mentioned in various threads here were: Install tightvncserver instead + x2go bloat (i.e. use VNC) Only login as root - didn't seem to make any difference for me Change some permissions of a log file in your home directory. Well, this is what I did on my Orange PI PC running Buster desktop with Kernel 5.4, as of April 2020. sudo apt install xrdp xorgxrdp sudo systemctl enable xrdp sudo reboot ... and that was it. The missing piece of the puzzel appeared to be the install of xorgxrdp, this isn't installed automatically by 'xrdp' package, and it's useless without it. Update June 2020: Also works with RetroOrangePi 4.3 super quickly (given this is based on Armbian Bionic 18.04). Can RDP in and use Armbian Desktop whilst Kodi plays a 4k movie on the TV from the same device... Awesome!
  21. Maybe someone does know the old/historical SAM (Software Automatic Mouth) speech synthesizer for the Commodore 64? Today I did found the github-page with the source-code and compiled it on my Orange Pi R1 - using armbian For compiling the default SDL-version I had to install the 2 additional packages with apt - libsdl1.2-dev - libsdl1.2debian before SAM did compile on armbian. I also did try libsdl2-2.0.0 (and -dev), but this didnt worked well while compiling The souce-code could be found at: https://github.com/s-macke/SAM Hear here, how this OLD speech synthesizer sounds https://www.youtube.com/watch?v=Rm4ZCGgzeeU Test him ONLINE: https://simulationcorner.net/index.php?page=sam Or read about him in the Wikipedia: https://en.wikipedia.org/wiki/Software_Automatic_Mouth
  22. All, Don´t know if anybody else did it... but I got Bluetooth running by modifying the device tree and adding support for communication between the RTL8723BS and UART1 and loading the needed RTL8723B firmware. Distro: Armbian Buster Kernel version: 5.4.30-sunxi64 This is how I did it: 1) Create a patch (xx.patch) with the next content and place it in ~/build/userpatches/kernel/sunxi-current/ --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts 2020-04-06 12:37:45.584912094 +0200 +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts 2020-04-06 12:37:45.584912094 +0200 @@ -498,6 +498,21 @@ status = "okay"; }; +/* On Wifi/BT connector, with RTS/CTS */ +&uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; + status = "okay"; + + bluetooth { + compatible = "realtek,rtl8723bs-bt"; + device-wake-gpios = <&r_pio 1 1 GPIO_ACTIVE_HIGH>; /* PM1 */ + host-wake-gpios = <&r_pio 1 2 GPIO_ACTIVE_HIGH>; /* PM2 */ + reset-gpios = <&r_pio 1 4 GPIO_ACTIVE_LOW>; /* PM4 */ + post-power-on-delay-ms = <200>; + }; +}; + &usb2otg { dr_mode = "host"; status = "okay"; 2) Run sudo ./compile with your favorite config (Desktop/server/blablabla) 3) Flash the image to an SD card or eMMC module. 4) Start your Pine64 H64 model-B 4) Connect to a network and run the firmware update/upgrades (armbian-config) and install the Bluetooth tools. 5) DO NOT ENABLE SERIAL 1 !!!! in armbian-config 6) Download the next git repo to your board: https://github.com/lwfinger/rtl8723bs_bt.git 7) Unpack the archive, run make 8) Copy the next firmware files to /lib/firmwares/rtl_bt: sudo cp rtlbt_fw_new /lib/firmware/rtl_bt/rtl8723bs_fw.bin sudo cp rtlbt_config /lib/firmware/rtl_bt/rtl8723bs_config.bin 9) Reboot Expected dmesg output: [ 45.107273] Bluetooth: HCI UART driver ver 2.3 [ 45.107279] Bluetooth: HCI UART protocol H4 registered [ 45.107281] Bluetooth: HCI UART protocol BCSP registered [ 45.107329] Bluetooth: HCI UART protocol LL registered [ 45.107331] Bluetooth: HCI UART protocol ATH3K registered [ 45.107375] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 45.107509] Bluetooth: HCI UART protocol Intel registered [ 45.107592] Bluetooth: HCI UART protocol Broadcom registered [ 45.107614] Bluetooth: HCI UART protocol QCA registered [ 45.107616] Bluetooth: HCI UART protocol AG6XX registered [ 45.107642] Bluetooth: HCI UART protocol Marvell registered [ 45.845446] Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723 [ 45.849521] Bluetooth: hci0: RTL: rom_version status=0 version=1 [ 45.849529] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_fw.bin [ 46.055000] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_config.bin [ 46.096579] Bluetooth: hci0: RTL: cfg_sz 55, total sz 23699 [ 46.929071] Bluetooth: hci0: RTL: fw version 0x373e6962 'hciconfig list' output: hci0: Type: Primary Bus: UART BD Address: 48:46:C1:3A:6B:5F ACL MTU: 820:8 SCO MTU: 255:16 UP RUNNING PSCAN ISCAN RX bytes:1982677 acl:3028 sco:0 events:491 errors:0 TX bytes:91688 acl:232 sco:0 commands:225 errors:0 File transfer from Pine to Samsung is working... haven't tested anything else.. Regards, __Dirk__
  23. Hi all. I wrote a small guide on enabling pps-gpio by modifying the device tree. With a PPS signal it's possible to setup your board as a Stratum 1 time server for your local network or the NTP pool. I used this method on a Rock64 but it should be applicable on most board. PPS-GPIO on Rock64 with Armbian legacy (4.4.X) kernel Cheers.
  24. So this guy made a simple yet brilliant inquiry into his thoughts on how to hack the at&t restrictions. I hope theres a status update soon cause, Id love to know how his progress has gone so far. https://ltehacks.com/viewtopic.php?f=31&t=783
  25. I've posted in the Armbian forums in the past about Kerberos.io video surveillance software. For some reasons it was (at the time) not always that easy or impossible to compile or get it up and running. But: Times have changed (for the good this time!) and I've tried it again on a H3 1GB memory OrangePi plus with kernel 5.4 using a *FRESH and CLEAN* Ubuntu Bionic Server image. I was able to get the Kerberos software 2.8.0 up and running straight away, just by *EXACT* following the instructions on the website of Kerberos.io (Generic installation Instructions page). It takes some time to compile ffmpeg and the machinery module, but it is certainly worth the effort! Go grab a drink, or do something else that's useful. Performance is ok, even though I think the hardware acceleration is not working. Just lower the FPS and/or resolution a bit. Performance is still great for everyday video surveillance with this excellent piece of software. I've tested successfully two different Logitech USB cams and two el-cheapo Chinese IP cameras using the RTSP stream. Other information can also be found on the Kerberos.io website to get the software up and running. Please take care of defining exact camera type and resolution!