Jump to content

Search the Community

Showing results for tags 'tutorial'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Product Groups

  • Misc
  • Support

Categories

  • Armbian
  • Armbian releases

Categories

  • Volunteering opportunities

Calendars

  • Community Calendar

Categories

  • Members

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/Jabber


Skype


Github


Discord


Location


Interests

  1. For enabling - to use stockfish/armfish-chess-engine - as a TCP service we need to configure (add the lines at the end of the file) /etc/inetd.conf #:OTHER: Other services stockfish08 stream tcp nowait guido /usr/games/stockfish stockfish10 stream tcp nowait guido /usr/games/stockfish_10_64 armfish stream tcp nowait guido /usr/games/armfish_aarch64 and add the TCP-Port - we want to use - to the /etc/services (for optical reasons after pop3s port 995/tcp) pop3s 995/tcp # POP-3 over SSL # # stockfish08 1024/tcp # stockfish 8 chess engine stockfish10 1025/tcp # stockfish 10 chess engine armfish 1026/tcp # armfish chess engine at the end we have to restart inetd (or reboot) systemctl restart inetd Additional (important?) informations: - guido is a local user on my system - you need to change the name for the /etc/inetd.conf to a local user of your system - /usr/games/stockfish is the stockfish-binary installes by apt install stockfish - the stockfish-binary we compiled for stockfish v10 64Bit in another thread from ./Stockfish-master/src/stockfish (directory of the cloned github-repository) to /usr/games/stockfish_10_64 - /usr/games/armfish_aarch64 is the (on a 64Bit PC-Linux compiled with fasmg) assembler-version of stockfish which could run twice as fast see https://github.com/lantonov/asmFish precompiled aarch64-binary as attachment (think about the chmod 755 armfish_aarch64 after the transfer ) Binary-Overview in /usr/games/ root@t95k-pro(192.168.6.62):/usr/games# ls -l insgesamt 644 -rwxr-xr-x 1 root root 128050 Mär 14 22:08 armfish_aarch64 -rwxr-xr-x 1 root root 216216 Nov 12 2016 stockfish -rwxr-xr-x 1 root root 308896 Mär 14 13:57 stockfish_10_64 armfish_aarch64
  2. 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
  3. Normally you could install (if you use a 64Bit arm-system/OS) the 64Bit version of stockfish with apt install stockfish stockfish is a uci-chess-engine where some Chessboard-Display-Apps can conenct to (later I would show how to use this with TCP) Then you will get (at this time) the Version 8 64Bit = 8 64 = 11/2016 But the actual stockfish-engine is at Version 10 = 12/2018 ( see http://blog.stockfishchess.org/ ) So I did clone the git-master at https://github.com/official-stockfish/Stockfish as .zip After unzipping and cd to ./Stockfish-master/src you could do -make clean -make help BUT there is for arm only a ARCH=armv7 (32Bit) option When using the ARCH=general-64 option make build ARCH=general64 COMP=gcc COMPCXX=g++ then the start of the compile did fail because g++ says that he didnt knows the -m64 commandline-option I searched the Web and found there no solution So I did take a look into the Makefile and first I didnt found anything about -m64, but then I discoverd in the gcc-options the follwing part which I then deleted: else CXXFLAGS += -m$(bits) LDFLAGS += -m$(bits) after that I did create a aarch64-ARCH-section under the armv7-ARCH-section: ifeq ($(ARCH),aarch64) arch = any prefetch = yes bits = 64 endif arch = any is copied from the "general-64" section, prefetch is copied from the "armv7"-section and maybe the "bits = 64" is obsolete? Now we can compile - there are two options: dpkg -l|grep 'g++' ii g++ 4:6.3.0-4 arm64 GNU C++ compiler ii g++-6 6.3.0-18+deb9u1 arm64 GNU C++ compiler make build ARCH=aarch64 COMP=gcc COMPCXX=g++ make build ARCH=aarch64 COMP=gcc COMPCXX=g++-6 When the compile has completed you will have the executeable stockfish in your ./Stockfish-master/src directory. see stockfish_10_64 as attached binary at the end of this thread-message When started you will see: Stockfish 140319 64 by T. Romstad, M. Costalba, J. Kiiski, G. Linscott Enter uci and you will see the stockfish-info: id name Stockfish 140319 64 id author T. Romstad, M. Costalba, J. Kiiski, G. Linscott option name Debug Log File type string default option name Contempt type spin default 24 min -100 max 100 option name Analysis Contempt type combo default Both var Off var White var Black var Both option name Threads type spin default 1 min 1 max 512 option name Hash type spin default 16 min 1 max 131072 option name Clear Hash type button option name Ponder type check default false option name MultiPV type spin default 1 min 1 max 500 option name Skill Level type spin default 20 min 0 max 20 option name Move Overhead type spin default 30 min 0 max 5000 option name Minimum Thinking Time type spin default 20 min 0 max 5000 option name Slow Mover type spin default 84 min 10 max 1000 option name nodestime type spin default 0 min 0 max 10000 option name UCI_Chess960 type check default false option name UCI_AnalyseMode type check default false option name SyzygyPath type string default <empty> option name SyzygyProbeDepth type spin default 1 min 1 max 100 option name Syzygy50MoveRule type check default true option name SyzygyProbeLimit type spin default 7 min 0 max 7 uciok You could leave the stockfish chess-engine with quit I will add (these days) a tutorial for setting up stockfish as TCP-Service (via inetd) and then we could connect via Windows/Android/Linux ChessBoard-Display-Apps to play with the stockfish engine on your 64Bit ARM-System Preview-Information-Links for setting up , connecting and playing with the engine: https://somoit.net/linux/linux-create-custom-inetd-service https://jerrygreenblog.wordpress.com/2016/08/26/linux-stockfish-chess-engine-as-remote-service/ http://aartbik.blogspot.com/2012/03/connecting-chess-for-android-to-remote.html stockfish_10_64
  4. Over a year (or two?) I used a PS1-line in my ~/-bashrc with many cryptic ANSI-Escape-codes which were hard to read and edit export PS1='\[\033[1;36m\]\u\[\033[1;37m\]@\[\033[1;33m\]\h\[\033[1;37m\](\[\033[1;32m\]$THEIP\[\033[1;37m\])\[\033[1;31m\]:\[\033[1;36m\]\w\[\033[1;31m\]\$\[\033[0m\] ' Today I did installed Linux Lite 4.6 on a PC (a former Chromebox) and did see the nice Powerline prompt and did try to use that on a nanoPi Neo2. I installed the packages fonts-powerline & powerline and copied the powerline-script /usr/share/powerline/bindings/bash/powerline.sh from the pc to the NanoPi Neo2. It did work after I used UTF8 translation in pUTTY, but it wasnt very perfomant So I decided to cleanup my PS1 line for better reading, I had to define some variables and then I did put these in my PS1 export line in ~/.bashrc: export THEIP="$(/sbin/ifconfig | grep "inet " | grep -v 127.0.0. | awk '{print $2}')" BRed='\[\033[31;1m\]' BGreen='\[\033[32;1m\]' BYellow='\[\033[33;1m\]' BCyan='\[\033[36;1m\]' BWhite='\[\033[37;1m\]' Reset='\[\033[0m\]' UserPromptPS1='\$' export PS1="${BCyan}\u${BWhite}@${BYellow}\h${BWhite}(${BGreen}${THEIP}${BWhite})${BRed}:${BCyan}\w${BRed}${UserPromptPS1}${Reset} " # \u = User # @ = @ # \h = Host # \w = working directory # \$ = # for root (uid=0) or $ for user That worked well and did give me the same result as my old but bad readable PS1-line Now its - for me - much more easy to edit As Information some more useable color-definition (B before the color is for Bright and colors starting with On are for the Background): Black='\[\033[30m\]' Red='\[\033[31m\]' Green='\[\033[32m\]' Yellow='\[\033[33m\]' Blue='\[\033[34m\]' Magenta='\[\033[35m\]' Cyan='\[\033[36m\]' White='\[\033[37m\]' BBlack='\[\033[30;1m\]' BRed='\[\033[31;1m\]' BGreen='\[\033[32;1m\]' BYellow='\[\033[33;1m\]' BBlue='\[\033[34;1m\]' BMagenta='\[\033[35;1m\]' BCyan='\[\033[36;1m\]' BWhite='\[\033[37;1m\]' OnBlack='\[\033[40m\]' OnRed='\[\033[41m\]' OnGreen='\[\033[42m\]' OnYellow='\[\033[43m\]' OnBlue='\[\033[44m\]' OnMagenta='\[\033[45m\]' OnCyan='\[\033[46m\]' OnWhite='\[\033[47m\]' OnBBlack='\[\033[40;1m\]' OnBRed='\[\033[41;1m\]' OnBGreen='\[\033[42;1m\]' OnBYellow='\[\033[43;1m\]' OnBBlue='\[\033[44;1m\]' OnBMagenta='\[\033[45;1m\]' OnBCyan='\[\033[46;1m\]' OnBWhite='\[\033[47;1m\]' Reset='\[\033[0m\]'
  5. 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
  6. Panfrost instructions Armbian !!!! I made a script that does all this, check a few posts later for the script !!!!! This tutorial explains how to build an Armbian image with panfrost. And what else you need to make it work. These are early drivers. Many things don't work yet. Only OpenGL 2.1 works now. You need to build an image with kernel 5.2 or later. For this you need an x86 pc with Ubuntu 18.04 or a virtual Ubuntu 18.04 x86 image. First install git, then clone the build folder from Armbian, and enter the build directory. apt-get -y -qq install git git clone --depth 1 https://github.com/armbian/build cd build Now run the script with EXPERT=yes so you can choose to build a dev image. sudo ./compile EXPERT=yes Choose "Full OS image for flashing" Then "Show a kernel configuration menu before compilation" Choose your board. If it's not in the regular list, look in "Show SCS/WIP/EOS/TVB". Choose Development version kernel configuration -> device drivers -> graphic drivers -> panfrost Let it run until it's finished. The image will be in the /build/output/images Burn it to an SD-card/eMMC/... Now we need to install all the needed software sudo apt install flex bison python3-mako libwayland-egl-backend-dev libxcb-dri3-dev libxcb-dri2-0-dev libxcb-glx0-dev libx11-xcb-dev libxcb-present-dev libxcb-sync-dev libxxf86vm-dev libxshmfence-dev libxrandr-dev libwayland-dev libxdamage-dev libxext-dev libxfixes-dev x11proto-dri2-dev x11proto-dri3-dev x11proto-present-dev x11proto-gl-dev x11proto-xf86vidmode-dev libexpat1-dev libudev-dev gettext glmark2 glmark2-es2 mesa-utils xutils-dev libpthread-stubs0-dev ninja-build bc python-pip flex bison cmake git valgrind llvm llvm-8-dev python3-pip pkg-config zlib1g-dev wayland-protocols Download and install meson wget http://ftp.de.debian.org/debian/pool/main/m/meson/meson_0.55.3-1_all.deb sudo dpkg -i meson_0.55.3-1_all.deb Download and install mesa DRM git clone git://anongit.freedesktop.org/mesa/drm cd drm meson build --prefix=/usr ninja -C build sudo -E ninja -C build install cd .. Download and install mesa graphics git clone git://anongit.freedesktop.org/mesa/mesa cd mesa meson -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dprefix=/usr build/ ninja -C build/ sudo ninja -C build/ install REBOOT Optionally, update sdl (recommended) git clone https://github.com/SDL-mirror/SDL.git cd SDL mkdir build cd build cmake ../ make -j6 sudo make install REBOOT Only thing that works ok with it is supertuxkart, to install it. sudo apt install supertuxkart Panfrost - Linux games working from repo SuperTuxKart - Works well ExtremeTuxRacer - lots of glitches AssaultCube - lots of glitches Instructions by Salvador Liébana & NicoD
  7. 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.
  8. Is OPI ONE a toy or a toy ? Yes and yes and a fun one too ! The following experiment shows the OPI ONE in use as a Virtual Desktop Server AND Virtual Desktop Client. Setup as Virtual Desktop Server ( remotely access headless OPI ONE desktop ) OPI ONE : install xrdp and tightvncserver <clients> : install and configure remote desktop ( rdesktop on linux, aRDP on android - not yet tested on OS-X or WIN ) Setup as Virtual Desktop Client ( OPI ONE securely accesses a remote linux desktop ) OPI ONE : install x2goclient <server> : install x2goserver on linux server ( physical or virtual ) of choice This document explains the experiment ( you have to click/enlarge pictures in your browser .. sorry ) And here is a screenshot of the actual session : Red : Linux server desktop connecting to OPI ONE via rdesktop / xrdp Orange : OPI ONE desktop connecting to UK virtual server via x2goclient/x2goserver Purple : virtual server (UK) desktop running libreoffice White : actual document being edited ( incl. drawings ! ) in window ( Headline : Italian guy in Switzerland abuses OPI ONE to edit nerd stuff in the UK ) Remote desktop access from smartphone ( cheap Wiko Lenny 2 ) for touch-fumbling nano-fingers Remote desktop access from tablet ( Galaxy Note 8.0 ) using pen There are numerous use cases covered with the simple techniques employed.Thanks to the Armbian team and the forum buddies for their excellent job in making OPI ONE usable. Have fun !
  9. 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:
  10. 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
  11. As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities. Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material). However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash. So this is a step-by step guide on how to make everything work: 0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here. >> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install Hold the ffmpeg packages, so they don't get upgraded: $ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \ Restart the service: $ sudo service emby-server restart Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation). For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done: And that's it! As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding). Enjoy! And please, share your experiences and comments here.
  12. 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
  13. Full root filesystem encryption on an Armbian/Orange Pi PC 2 system MMGen (https://github.com/mmgen) WARNING: This tutorial has been obsoleted by Full root filesystem encryption on an Armbian system. In addition, an automated script is available, which can be downloaded here or by cloning the following repository: git clone https://github.com/mmgen/mmgen-geek-tools This tutorial provides detailed, step-by-step instructions for setting up full root filesystem encryption on an Armbian/Orange Pi PC2 system. With minor changes, it can be adapted to other Armbian-supported boards. The disk is unlocked remotely via ssh, permitting unattended bootup. Requirements: Linux host system One Orange Pi PC 2 Two blank Micro-SD cards (or a working Armbian system for your board + one blank SD card) USB Micro-SD card reader Ability to edit text files and do simple administrative tasks on the Linux command line Part 1 - Get, unpack and copy an Armbian image for your board Create your build directory: $ mkdir armbenc-build && cd armbenc-build Download and unpack an Armbian image for your board and place it in this directory. If you have two blank SD cards, the first will hold an ordinary unencrypted Armbian system used for the setup process, while the second will hold the target encrypted system. Alternatively, if you already have a working Armbian system for your board, you can use it for the setup process. In that case, your one blank SD card will be considered the “second” card, and you can ignore all instructions hereafter pertaining to the first card. Note that for the remainder of this section, the first SD card will be referred to as '/dev/sdX' and the second as '/dev/sdY'. You'll replace these with the SD cards' true device filenames. The device names can be discovered using the command 'dmesg' or 'lsblk'. If you remove the first card before inserting the second, it's possible (but not guaranteed) that the cards will have the same device name. Insert the first blank SD card and copy the image to it: $ sudo dd if=$(echo *.img) of=/dev/sdX bs=4M After the command exits, you may remove the first card. Now insert the second SD card, which will hold a small unencrypted boot partition plus your encrypted Armbian system. Copy the image's boot loader to it: $ sudo dd if=$(echo *.img) of=/dev/sdY bs=512 count=32768 Now partition the card: $ sudo fdisk /dev/sdY Within fdisk, create a new DOS disklabel with the 'o' command. Use the 'n' command to create a primary partition of size +200M beginning at sector 32768. Type 'p' to view the partition table. Note the end sector. Now create a second primary partition beginning one sector after the first partition's end sector and filling the remainder of the card. When you're finished, your partition table will look something like this: Device Boot Start End Sectors Size Id Type /dev/sdY1 32768 442367 409600 200M 83 Linux /dev/sdY2 442368 123596799 123154432 58.7G 83 Linux Double-check that the second partition begins one sector after the end of the first one. If you mess something up, use 'd' to delete partitions or 'q' to exit fdisk and try again. Once everything looks correct, type 'w' to write the partition table. Now you'll begin the process of copying the system to the second card. First you'll associate the image file with a loop device and mount the device: $ losetup -f # displays the name of the loop device; remember this $ sudo losetup -Pf *.img # associate image file with the above loop device $ mkdir mnt boot root $ sudo mount /dev/loopXp1 mnt # replace '/dev/loopX' with the above loop device Create a filesystem on the SD card's boot partition and copy the boot partition data from the image file to it: $ sudo mkfs.ext4 /dev/sdY1 $ sudo e2label /dev/sdY1 OPI_PC2_BOOT # don't omit this step! $ sudo mount /dev/sdY1 boot $ sudo cp -av mnt/boot/* boot $ (cd boot; sudo ln -s . boot) Create the encrypted root partition (for this the 'cryptsetup-bin' package must be installed on the host). You'll be prompted for a passphrase. It's recommended to choose an easy one like 'abc' for now. The passphrase can easily be changed later (consult the 'cryptsetup' man page for details): $ sudo cryptsetup --pbkdf argon2i --pbkdf-memory 600000 luksFormat /dev/sdY2 Note that the --pbkdf-memory argument must be less than the available free memory in kilobytes at bootup time. Otherwise you’ll get an out-of-memory error and your disk will fail to unlock. 600000 is a safe value for the Orange Pi PC2 with its 1GB of RAM. Activate the encrypted root partition, create a filesystem on it and mount it: $ sudo cryptsetup luksOpen /dev/sdY2 foo # enter your passphrase from above $ sudo mkfs.ext4 /dev/mapper/foo $ sudo mount /dev/mapper/foo root Copy the system to the encrypted root partition: $ (cd mnt && sudo rsync -av --exclude=boot * ../root) $ sync # be patient, this could take a while $ sudo mkdir root/boot $ sudo touch root/root/.no_rootfs_resize Unmount the mounted image and second SD card, and free the loop device and encrypted mapping: $ sudo umount mnt boot root $ sudo losetup -d /dev/loopX $ sudo cryptsetup luksClose foo From here on, all your work will be done on the Orange Pi. Part 2 - boot into the unencrypted Armbian system If applicable, insert the first (unencrypted) SD card into the Pi's Micro-SD card slot. Insert a USB card reader holding the second SD card into a USB port on the Pi. Boot the Pi. If applicable, log in as root with password '1234', follow the password update instructions, and stay logged in as root. The following steps will be performed from a root shell. Part 3 - set up the unencrypted Armbian system Update the APT package index and install cryptsetup: # apt-get update # apt-get install cryptsetup Part 4 - set up the encrypted Armbian system Prepare the encrypted system chroot: # BOOT_PART=($(lsblk -l -o NAME,LABEL | grep OPI_PC2_BOOT)) # ROOT_PART=${BOOT_PART%1}2 # cryptsetup luksOpen /dev/$ROOT_PART foo # mkdir /mnt/enc_root # mount /dev/mapper/foo /mnt/enc_root # mount /dev/$BOOT_PART /mnt/enc_root/boot # cd /mnt/enc_root # mount -o rbind /dev dev # mount -t proc proc proc # mount -t sysfs sys sys Copy some key files so you'll have a working Internet connection within the chroot: # cat /etc/resolv.conf > etc/resolv.conf # cat /etc/hosts > etc/hosts Now chroot into the encrypted system. From this point on, all work will be done inside the chroot: # chroot . # apt-get update # echo 'export CRYPTSETUP=y' > /etc/initramfs-tools/conf.d/cryptsetup # apt-get install cryptsetup-initramfs dropbear-initramfs # for focal and buster # apt-get install cryptsetup dropbear-initramfs # for bionic Check to see that the cryptsetup scripts are present in the initramfs (command should produce output): # gunzip -c /boot/initrd.img* | cpio --quiet -t | grep cryptsetup Edit '/etc/fstab' to look exactly like this: /dev/mapper/rootfs / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 /dev/mmcblk0p1 /boot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2 tmpfs /tmp tmpfs defaults,nosuid 0 0 Add the following lines to '/etc/initramfs-tools/initramfs.conf'. If the Orange Pi's IP address will be statically configured, substitute the correct static IP address after 'IP='. If it will be configured via DHCP, omit the IP line entirely: DEVICE=eth0 IP=192.168.0.88:::255.255.255.0::eth0:off Add the following parameters to the quoted bootargs line in '/boot/boot.cmd'. Note that the 'root' parameter replaces the existing one: root=/dev/mapper/rootfs cryptopts=source=/dev/mmcblk0p2,target=rootfs If you want to be able to unlock the disk from the virtual console (which you probably do) as well as via ssh, then comment out the following line: # if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttyS0,115200"; fi In case you're wondering, 'setenv console "display"' doesn't work. Don't ask me why. Compile the boot menu: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Copy the SSH public key from the machine you'll be unlocking the disk from to the Armbian machine: # rsync yourusername@remote_machine:.ssh/id_*.pub /etc/dropbear-initramfs/authorized_keys If you'll be unlocking the disk from more than one host, then edit the authorized_keys file by hand and add the additional SSH public keys. Edit '/etc/dropbear-initramfs/config', adding the following lines: DROPBEAR_OPTIONS="-p 2222" DROPBEAR=y Reconfigure dropbear: # dpkg-reconfigure dropbear-initramfs Make sure everything was included in the initramfs (both commands should produce output): # gunzip -c /boot/initrd.img* | cpio --quiet -t | grep dropbear # gunzip -c /boot/initrd.img* | cpio --quiet -t | grep authorized_keys Your work is finished! Exit the chroot and shut down the Orange Pi: # exit # halt -p Swap the SD cards and restart the Pi. Unlock the disk by executing the following command on your remote machine. Substitute the Pi's correct static or DHCP-configured IP address for the one below. If necessary, also substitute the correct disk password in place of 'abc': $ ssh -p 2222 -x root@192.168.0.88 'echo -n abc > /lib/cryptsetup/passfifo' If you choose to unlock the disk from the tty, just enter your disk password and hit ENTER. If all went well, your root-filesystem encrypted Armbian system is now up and running!
  14. 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!
  15. Hi, This topic was a initially a question and become a tutorial to use push buttons on orange pi PC. This tutorial has been made with an Orange PI PC running on "Armbian_5.35_Orangepipc_Debian_jessie_default_3.4.113.img". With this example you will be able to launch 3 different scripts for each push button : /usr/local/bin/run<Wpi GPIO number>short.sh -> immediately launched when a button is pressed /usr/local/bin/run<Wpi GPIO number>long.sh -> launched after a long pression /usr/local/bin/run<Wpi GPIO number>release.sh -> launched when a button is released (but not after a long pression) I've made this image to know easily see the correspondence between WiringOP and physical Orange PI PC connector : Mhhh if you want to modify it, you'll find the excel source file here. Sources : http://orangepi.club/showthread.php?tid=2173 -> excellent tutorial for beginners ! https://github.com/zhaolei/WiringOP -> a modified WiringPi for OrangePi http://nix.zeya.org/wiki/разработка_средств_аппаратного_управления_для_orange_pi_pc -> a very good example of program in C to use Orange PI GPIO with push buttons To install and compile the WiringOP library : mkdir downloads cd downloads git clone https://github.com/zhaolei/WiringOP.git -b h3 cd WiringOP/ sudo ./build Make a test : gpio readall You should obtain something like that : +-----+-----+----------+------+---+-Orange Pi+---+---+------+---------+-----+--+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 12 | 8 | SDA.0 | ALT5 | 0 | 3 || 4 | | | 5V | | | | 11 | 9 | SCL.0 | ALT5 | 0 | 5 || 6 | | | 0v | | | | 6 | 7 | GPIO.7 | ALT3 | 0 | 7 || 8 | 0 | ALT3 | TxD3 | 15 | 13 | | | | 0v | | | 9 || 10 | 0 | ALT3 | RxD3 | 16 | 14 | | 1 | 0 | RxD2 | ALT3 | 0 | 11 || 12 | 0 | ALT3 | GPIO.1 | 1 | 110 | | 0 | 2 | TxD2 | ALT3 | 1 | 13 || 14 | | | 0v | | | | 3 | 3 | CTS2 | IN | 1 | 15 || 16 | 0 | ALT3 | GPIO.4 | 4 | 68 | | | | 3.3v | | | 17 || 18 | 0 | ALT3 | GPIO.5 | 5 | 71 | | 64 | 12 | MOSI | ALT4 | 0 | 19 || 20 | | | 0v | | | | 65 | 13 | MISO | ALT4 | 0 | 21 || 22 | 0 | ALT3 | RTS2 | 6 | 2 | | 66 | 14 | SCLK | ALT4 | 0 | 23 || 24 | 0 | ALT4 | CE0 | 10 | 67 | | | | 0v | | | 25 || 26 | 0 | ALT5 | GPIO.11 | 11 | 21 | | 19 | 30 | SDA.1 | ALT5 | 0 | 27 || 28 | 0 | ALT5 | SCL.1 | 31 | 18 | | 7 | 21 | GPIO.21 | IN | 1 | 29 || 30 | | | 0v | | | | 8 | 22 | GPIO.22 | IN | 1 | 31 || 32 | 0 | ALT3 | RTS1 | 26 | 200 | | 9 | 23 | GPIO.23 | IN | 1 | 33 || 34 | | | 0v | | | | 10 | 24 | GPIO.24 | IN | 1 | 35 || 36 | 0 | ALT3 | CTS1 | 27 | 201 | | 20 | 25 | GPIO.25 | ALT5 | 0 | 37 || 38 | 0 | ALT3 | TxD1 | 28 | 198 | | | | 0v | | | 39 || 40 | 0 | ALT3 | RxD1 | 29 | 199 | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+-Orange Pi+---+------+----------+-----+-----+ Now we are going to write a program in C to detects pushes on buttons : nano pushbuttons.c The copy / paste the C program below : (you should modify the numbers of buttons that you use, the WiringOP pins that you use, you can create scripts later) OK now compile it and run it : gcc -lwiringPi -lwiringPiDev -o pushbuttons pushbuttons.c ./pushbuttons Press a button and you're done FYI : To use the native button on the motherboard of the orange PI PC you can use "acpid" to make working for reboot I hope it will be useful to some of you.
  16. 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 :-)
  17. Armbian implements some basic 'system logging' at every startup and shutdown and contains a little utility to provide this collected information combined with some more useful debug info from user installations. All that's needed is executing 'sudo armbianmonitor -u' (or armbian-config --> Software --> Diagnostics) and then all this support related information is uploaded to an online pasteboard service automagically (see example output) How to interpret this wall of text? The output is best read from bottom to top since the most important information is collected during upload: At the bottom /proc/interrupts contents to check for IRQ affinity problems (interrupt collissions on some CPU cores negatively affecting performance) Then last 250 lines dmesg output are included. Here you might find important information wrt the last (kernel) events that happened on the machine uptime output including average load statistics (1, 5 and 15 min) free output telling how much physical memory is available and how much swap and/or zram is used (you need to look directly above whether zram is active or not to interpret the 'Swap:' line) vmstat output contains virtual memory usage information since last reboot iostat output contains the same but allows for a 'per device' view since all devices are listed with individual statistics (so it's easy to spot IO bottlenecks by looking at these numbers and also looking at %iowait value) 'Current system health' displays what the system is actually doing while uploading the debug log (on systems where DC-IN monitoring is available also allowing for underpowering diagnosis -- if you read here numbers below 5.0V stop reading the log and tell the user to fix his underpowering issues first) In case the installation has been moved from SD card to other storage nand-sata-install.log will be included in the output 'Loaded modules' allow to look for module related problems If it's an Allwinner board running legacy kernel the whole script.bin contents are included 'Installed packages' shows version numbers of relevant Armbian packages 'Group membership of' should list all groups the user is member of. If this line is missing ignore the whole contents and ask the user to re-submit debug info, this time doing it correctly not as root but using 'sudo armbianmonitor -u' (group memberships are important to understand certain problems, eg. users not being member of audio group won't have success getting noise out of their devices) If the board is PCIe capable list of attached PCIe devices is included The lsusb output lists all connected USB devices and also information about speed (12M, 480M, 5000M) and protocol/connection details (mass-storage vs uas for example) If the user installed the lshw utility and verbosity is set to 4 or above in /boot/armbianEnv.txt some more disk related information will be included Important: The debug output also contains all collected support files that follow this naming scheme: /tmp/armbianmonitor_checks_* -- so if a user complains about 'transmission so slow' or 'latest files are always missing' ask him to run 'armbianmonitor -c /path/to/torrent-storage' and afterwards 'sudo armbianmonitor -u' without a reboot in between since then the checking results will also be contained. Everything above of this information at the output's bottom is result of regular logging at startup and shutdown (the contents of /var/log/armhwinfo.log). At startup the following items are logged: dmesg output, /etc/armbian-release and /boot/armbianEnv.txt contents, lsusb and lscpu output, /proc/cpuinfo and /proc/meminfo contents, network interface information, available partitions and filesystems, on Allwinner boards where /boot/script.bin points to, some metadata information for all MMC media connected to the host (eg. SD card and/or eMMC) and some system health information. At shutdown iostat, vmstat and free output are added to /var/log/armhwinfo.log as well as the last 100 lines from dmesg output. If these '### shutdown' entries are missing after reboots the system crashed while shutting down.
  18. tkaiser has built a new Kernel with i2s Modules. With this Kernel and some cheap DAC e.g. (http://www.ebay.de/itm/Audiophonics-I2S-DAC-ES9023-Sabre-to-Analog-24bit-192KHZ-fur-Raspberry-PI-/291573327639?hash=item43e31fe717:g:TTwAAOSw~OdVZXtm) it is possible to get good quality sound out of the Orange Pis. After installing the Kernel Two Things have to be changed in the fex File: Change Directory to boot: cd /boot Turn the script.bin to a fex-File and open it in an Editor sudo bin2fex script.bin script.fex sudo nano script.fex Now change the following Entries: [twi1] twi_used = 1 to [twi1] twi_used = 0 and [pcm0] daudio_used = 0 to [pcm0] daudio_used = 1 Save your changes and do : sudo fex2bin script.fex script.bin After a reboot your done. I do not know for what the Section [twi1] is good for, i hope nothing serious.. This connections have to be made: 5V > Pin 2 Gnd > Pin6 BCK > Pin 27 LRCK > Pin 28 Data > Pin37 (according to the Picture "giachi" has posted on the diyaudio Forum http://www.diyaudio.com/forums/pc-based/285427-i2s-connection-orange-dac.html#post4587580 see below) The second Picture is only for orientation on an Orangepi PC, the red Wire is 5V ! Be aware that the Header is rotated by 180°on the One! That´s all . Regards
  19. 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?
  20. 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...
  21. 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
  22. 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
  23. 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"
  24. Yesterday i did install Armbian_5.86_Aml-s905_Debian_buster_default_5.1.0_20190514.img from @balbes150 on my Sunvell T95KPro (S912). While installing Pihole the Installation does break when trying to start lighttpd. After checking with journalctl -u lighttpd it turns out that the file /usr/share/lighttpd/create-mime.assign.pl is missing, because in the newer lighttpd-version of debian buster the file has be renamed to /usr/share/lighttpd/create-mime.conf.pl (see also https://discourse.pi-hole.net/t/lighttpd-does-not-start/6207/11 ) Pihole doesnt know/use the new name with debian buster, so it fails to start the lighttpd So I did find 2 ways to resolve the problem. First (quick and dirty?) way: cp /usr/share/lighttpd/create-mime.conf.pl /usr/share/lighttpd/create-mime.assign.pl or ln -s /usr/share/lighttpd/create-mime.conf.pl /usr/share/lighttpd/create-mime.assign.pl read also: Pihole breaks lighttpd on Debian Buster #2557 https://github.com/pi-hole/pi-hole/issues/2557 the second way (found it at https://forum.kuketz-blog.de/viewtopic.php?t=3067 ) is to edit /etc/lighttpd/lighttpd.conf and search for the 2 following lines and comment them out (found the 2nd one at the end of the file): #include_shell "/usr/share/lighttpd/create-mime.assign.pl" #include_shell "cat external.conf 2>/dev/null" and add the follwoing line to the file: include_shell "/usr/share/lighttpd/create-mime.conf.pl" After saving the file you should be able to restart lighttpd via sudo /etc/init.d/lighttpd restart or sudo service lighttpd restart or sudo service lighttpd stop sudo service lighttpd start BUT second way does not work good with updating or repair-install of pihole, because I think this will set the config-file to the old state (also for server.error-handler-404) So maybe the first way will work better while pihole doenst know the new file-name - or you also can do both ways BTW: If you are experience a 400 Bad Request while only using the IP for getting to the Pihole-Webpage (and the redirect should ask you if you want to use the /admin page - but it doenst) then try the follwing small resolution - edit a line in the file /etc/lighttpd/lighttpd.conf from: server.error-handler-404 = "pihole/index.php" to: server.error-handler-404 = "/pihole/index.php" lighttpd.conf
  25. https://www.openhab.org/docs/installation/armbian.html
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines