Elric

If this problem still unsolved, please provide: Output from "systemctl status openvpn.service" Output from "ifconfig" Output from "ip a" I don't know how to setup openvpn the network-manager style, but on cli it would be like this: 1. Copy provided .ovpn files from your VPN provider to /etc/openvpn. Rename them to .conf. (server1.ovpn --> server1.conf, server2.ovpn --> server2.conf and so on) 2. If you to have a specific VPN-server to connect durning booting (example server2), edit /etc/default/openvpn, add the line AUTOSTART=server2. Leave all the other lines commented, as they are. 3. The next boot you'll be prompted for your credentials for server2. 4. You can automate login, by creating a credential file (e.g. auth.txt) in /etc/openvpn containing first line your username, second line your password. In your providers .ovpn (or renamed .conf) find "auth-user-pass" and add a " auth.txt" (auth-user-pass --> auth-user-pass auth.txt). Ensure that auth.txt is executable. (chmod 755 auth.txt). 5. After configuring, do a reboot All the times I configured my vpn it worked fine this way. To ensure to have the connection to vpn provider instead to your ISP use "curl ipinfo.io". The output should point to server2's ip address. If the output points to your own ip address, then you have a routing problem. I'm pretty sure there is a proper nm way to solve such a problem. On cli you might try altering iptables: iptables -F iptables -t nat -F iptables -X iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE iptables -A FORWARD -i tun0 -o <network interface, e.g. eth0> -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i <network interface, e.g. eth0> -o tun0 -j ACCEPT (example: iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT) Hope, this will fix your problems.

Thx for explaining a newbie, what is causing the bug. I suppose in the next release, you'll drop the armbian desktop support for server images (by removing the menu entry in armbian-config). When this bug is finally fixed, you'll turn it on again. Meanwhile you provide two desktop images, that's plenty of work for such small team and more than enough for a workaround! You really do a great job! I think, that this bug a general problem and will occur on every board, not only on my BPi M1. armbian-config is great, enduser-friendly utiliy which helps beginners / noobs / newbies to do their first steps in a new OS, gathering experience, ending up with a well working device. Even an experienced admin saves a lot of time / command lines at the cli, using armbian-config. Somehow it seems to me, that I'm the only one who uses armbian-config, otherwise this bug would be reported before.

Tested new image (21.08.01 Buster / 5.10.60) WITH preinstalled xfce desktop. Works without any problems. So, I will use this one, if any desktop needed. The problem in the server image, discribed above, still exits (broken lightdm)

@Myron Is your BPi Pro reachable throu ssh? Does it boot? If you able to log in (ssh), you might append: extraargs=drm_kms_helper.edid_firmware=HDMI-A-1:edid/1920x1080.bin video=HDMI-A-1:1920x1080@60 to /boot/armbianEnv,txt. I wouldn't use 8V power supply, when 5V are recommened.

Hi everbody, last week I bought a TV-Box X96mini 2 GB / 16 GB. After reading the FAQ (thx @SteeMan), it was easy to set up this little box with the image provided by balbes150. (thx @balbes150) Most of the hardware is working fine, with the meson-gxl-s095x-p212.dtb, which is found on /boot/dtb/amlogic. There is a problem with the lirc support, but using triggerhappy will do the job. Thx @Alexey Woronov, https://forum.armbian.com/topic/11161-lirc-on-armbian-buster/?tab=comments#comment-83995 Another little problem is audio. Basically sound works, but volume from the audio jack is much too low. Only when I'm turning the volume to the max, I'm able to hear something. No sound probs using the HDMI output, this works fine. Even after successfully setting up the box, couple of questions remain. About image and uboot If you check /boot/dtb/* there are .dtb-files for other arm-based boards. Does this means, that the installation image (5.9.0) supports all the listed devices? Is this the one and only installation image for tv-boxes? Where do I get the u-boot files for the other soc-types (Allwinner, Rockchip) from? About dtb and dts Are dtb-files kernel-specific? I know, that every kernel bring their own set of dtb-files, but what is changing on a dtb-file between the releases? Is there a method decompiling dtb-files? Is a dts-file kernel-specific? Does it make sense having a dtb-file extracted from android stock rom (android 9 / Kernel 4.19) to use with provided 5.9.-based image? Besides having a server for pyload and a "VPN-Accesspoint" while running a openvpn client to my VPN provider, I also have an useable desktop (browsing and office is fine, multimedia not) which is accessable via RDP. I tried also an alternate setup: using this tv-box as a tv-box under Linux and kodi. The results were sobering me. Playing a local video file (USB, 1080p) with 5 fps is no fun, playing a internet live stream (720p) with 5 fpm is much more like listening to an audiocast, than watching TV. With the cpu frequency left at 1.2 Ghz, system load was over 90% on all cores when kodi was running, bringing up cpu's temperature up to 70°C. Unuseable. Taking this as an experience, I will go on using armbian server image on sd card, having in addition a rescue / backup system for android mods on emmc. To be honnest: no matter, if stock or custom (Android TV9) rom, this box doesn't fullfill my requirements. Even with a limited screenresolution(1080p), video playback is "wacky", sometimes there are "blackouts", when starting a program or altering settings in menu. When these "blackouts" lasting more than 5 seconds, my TV loses the "HDMI-handshake" to the box and falls back to it's own menu. So, my last question will be: Does someone has an android tv-box (built-in bluetooth would be great) with well-working 4k support, which is although "armbian-able"? Or, which might be better: Which full supported board does meet my requirements (min. 1080p resolution, proper video and sound playback, BT and WLAN) WITHOUT having active cooling? Thx for your time, reading and answering my newbie questions.

I know, using an old Banana Pi M1 for desktop doesn't make sense at all. I would prefer having help or/and advice clearing the problems I've encountered, instead a discussion why I'm testing a desktop environment on a BPi M1. Tested with Armbian 21.08.01 Buster / 5.10.60 After the initial boot nano or / and armbian-config doesn't work. A reboot solves this issue. After the second boot I changed verbosity to 7 and console to serial. All other changes where made throu armbian-config. Changing Pi's name works, but changing console's layout doesn't. Never mind, that is a minor problem, which can easily solved by hand. So I did "firmware upgrade" and rebooted my pi. dmesg: apt list lightdm lightdm/oldstable 1.26.0-4 armhf I proceed installing armbian desktop throu armbian-config. To ensure, that the installation will have all their dependencies installed, I quit armbian-config and reboot my pi. The armbianmonitor -u from this boot: http:// http://ix.io/3yvT This dmesg: Console-Output: systemctl status lightdm.service ● lightdm.service - Light Display Manager Loaded: loaded (/lib/systemd/system/lightdm.service; indirect; vendor preset: Active: failed (Result: exit-code) since Sat 2021-09-11 01:45:59 CEST; 10min Docs: man:lightdm(1) Process: 593 ExecStartPre=/bin/sh -c [ "$(cat /etc/X11/default-display-manager Sep 11 01:45:59 deskpi systemd[1]: lightdm.service: Service RestartSec=100ms exp Sep 11 01:45:59 deskpi systemd[1]: lightdm.service: Scheduled restart job, resta Sep 11 01:45:59 deskpi systemd[1]: Stopped Light Display Manager. Sep 11 01:45:59 deskpi systemd[1]: lightdm.service: Start request repeated too q Sep 11 01:45:59 deskpi systemd[1]: lightdm.service: Failed with result 'exit-cod Sep 11 01:45:59 deskpi systemd[1]: Failed to start Light Display Manager. Sep 11 01:45:59 deskpi systemd[1]: lightdm.service: Triggering OnFailure= depend journalctl -xe -- Support: https://www.debian.org/support -- -- A start job for unit user@0.service has finished successfully. -- -- The job identifier is 810. Sep 11 01:46:32 deskpi systemd[1]: Started Session 2 of user root. -- Subject: A start job for unit session-2.scope has finished successfully -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit session-2.scope has finished successfully. -- -- The job identifier is 871. Sep 11 01:46:32 deskpi login[835]: ROOT LOGIN on '/dev/ttyS0' Sep 11 01:46:37 deskpi systemd[1]: systemd-hostnamed.service: Succeeded. -- Subject: Unit succeeded -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- The unit systemd-hostnamed.service has successfully entered the 'dead' state. Sep 11 01:55:01 deskpi CRON[1345]: pam_unix(cron:session): session opened for us Sep 11 01:55:01 deskpi CRON[1346]: (root) CMD (command -v debian-sa1 > /dev/null Sep 11 01:55:01 deskpi CRON[1345]: pam_unix(cron:session): session closed for us On this point, I was couple of times before. I tried un- / re- install lightdm, which leaded me to missing kernel links. Installing an other display manager after installing armbian desktop via armbian-config will althrough bring errors and missing links for system.d. But at least armbian desktop does start. As a workaround having a desktop environment without having broken symblinks (but with a broken atomic namespace, whatever that means) I installed LXDE with LXDM. But this won't fix the problem with built-in lightdm. Thank you for your time reading my problems, i'll be deeply grateful for every hint fixing the broken lightdm.

Downloaded new image Armbian_21.08.1_Bananapi_buster_current_5.10.60.img today, flashed it to sdcard and started with a Unifying reciever plugged-in. Everything was fine, kernel starts without any troubles. Thanks for providing a new installation image!

As newbie, not knowing what I'm talking about, reviewing your pastebin I saw these 4 lines: [ 1476.203] (II) LoadModule: "fbdev" [ 1476.204] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 1476.205] (II) Module fbdev: vendor="X.Org Foundation" [ 1476.205] compiled for 1.20.8, module version = 0.5.0 all the other modules are compiled for 1.20.13

@Igor Thanks you for the information. So, how it looks like: I am newbie, thinking that the first plugged-in device has to be wlan0. But now I got it: wlx<MACADRESS> is valid network name. Recompiling was useless. Thank you for your help!

@guidolThank you once again for reading and answering. Since the problem "receiver" booting problem, I have 3 different sdcards in use (all 5.10.43), 2 Buster trying setting something up like an "VPN Access Point" and 1 focal for testing desktop environments and XRDP. With your kindly provided output of your lsusb and dmesg I started today the "focal" sdcard. Nothing else is installed on focal, just plain OS, no openvpn and no further experiments. Here is the output of my "focal" with plugged-in Edimax. root@deskpi:/# lsusb Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 003: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS] Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@deskpi:/# iwconfig lo no wireless extensions. eth0 no wireless extensions. wlx74da387ed9f9 IEEE 802.11 ESSID:off/any Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Encryption key:off Power Management:off Here is dmesg output: On this point in "Buster" image, I decided to compile wlan driver, following the given advice in the HOW-TO. Even the example driver is the one I need.... I hope this answers your question, WHY I recompiled the driver. I'm a newbie, but not such a newbie, that "wlx74da387ed9f9" could be a valid network name.

First of all: yes, I'd read phelums "Compiling RTL8189es driver" thread. If where was a solution for his thread, I didn't get it. I'm using a BPi M1, installed downloaded image (Armbian_21.05.1_Bananapi_buster_current_5.10.34.img) switched 5.10.43, updated "Firmware" and boot loader. uname -a Linux bananapi 5.10.43-sunxi #21.05.6 SMP Mon Jun 21 15:07:45 UTC 2021 armv7l GNU/Linux First I installed and configured openvpn, the next step would be wifi, so plugged in my wireless adapter: root@bananapi:~# lsusb Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 003: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS] Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub noticed having a RTL8188CUS, so the I should be fine with RTL8192C driver. Then I unplugged the device and followed the instructions given in https://docs.armbian.com/User-Guide_Advanced-Features/ build console output dmesg out: root@bananapi:~/rtl8192cu-fixes# iwconfig lo no wireless extensions. eth0 no wireless extensions. tun0 no wireless extensions. wlx74da387ed9f9 IEEE 802.11 ESSID:off/any Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Encryption key:off Power Management:off At this point, as a newbie, I have to give up and ask the community what I've done wrong and how to fix the mess. I attach the original Linux driver source, found the driver cd, which came along with the adapter. rtl8188C_8192C_usb_linux_v4.0.2_9000.20130911.tar.gz

Before it's forgotten: I have to praise the work which is done in "armbian-config". Great job! Hours of upgrading / downgrading kernel and environment without having one error! That's what I call stable.

@guidol I don't understand your last question. BPi-M1 doesn't have eMMC or am I wrong? Flash is, what will be found on sdcard. And on sdcard is the image provided by armbian.com on the page for banana pi m1. At the moment this is: Armbian_21.05.1_Bananapi_buster_current_5.10.34.img (or focal). But with your statement that the plugged-in receiver doesn't cause an endless boot loop, on 5.12 or 5.13, I decided to upgrade to 5.12.12. This worked as you described, after updating firmware and bootloader the problem was fixed. After rolling back to 5.10.34 without updating bootloader the first work-around was done. It only took a couple of hours playing around with armbian-config (System/Other&Firmware/Reboot) and balenaetcher on PC-side, and I found an acceptable workaround (and perhaps a solution). On first run you have to start without the receiver, do you first login remotely via ssh or uart-console if you have one. First step is to run armbian-config to System/Others and select 5.10.43 . After the restart do "Firmware upgrade" (apt update && apt upgrade) and update bootloader. That's it! I have 5.10.43 running and problem is gone. The easiest and perhaps user friendliest way to solve this issue, would be providing 5.10.43 based install images for BPi-M1.

My expierence in ubuntu and openvpn client is, that after installing the client is completly unconfigured, even the service isn't enabled. Also every line in /etc/default/openvpn are comments. The photo above shows a lot configured connections <Amsterdam to Zurich>.conf placed in /etc/openvpn (after installation this directory contains usally only the "update-resolve-conf" and the sub-directories server and client, both empty), and also in /etc/default/openvpn "AUTOSTART=all" instead the default "#AUTOSTART=all". With "AUTOSTART=none" in /etc/default/openvpn you turned off autostart completly. Guess you choose your prefered connection later on in your graphical desktop environment. Do you use a credential file for your connections or are you prompted for your username and password?

I have no idea how or what docker specific is to do. This worked fine for a cli-based installation: If VPN provider provides .ovpn files, get them, and put them in /etc/openvpn. 1. Create a file (eg. auth.txt) in /etc/openvpn, 1st line containing your username (with an ENTER), 2nd line containig your password (without ENTER). 2. Choose one server's .ovpn and copy it to config.conf in /etc/openvpn. 3. Edit config.conf, find auth-user-pass. Append " auth.txt", and save the modified config.conf. 4. edit /etc/default/openvpn. Change "#AUTOSTART=all" to "AUTOSTART=config" After this, enable and restart openvpn: 5. systemctl enable openvpn@config.service 6. systemctl daemon-reload That's all, you might wanna use a "curl ipinfo.io" to verify your new VPN-IP. Last time I setted up openvpn this way, I recieved such an error message at login after reboot: "Unable to read database "/var/lib/vnstat/tun0" No such file or directory Merge "eth0+tun0" failed" VPN worked, even without vnstat. But you can simply correct by: vnstat --create -i tun0 and a reboot.