botfap

UK Server deployed. Details PM'd

@Igor  Ok Instead of integrating into our CDN which could be a pain without an infrastructure plan, I will keep it simple and provision for 12 months a UK server with 100GB sys / 500GB data storage & 2TB / month data allowance (can be upped if needed). Ill stick a load balancer / cache on the front of it for the public access mechanism and security and it can host as many repos / domains as you like.
 
Do you have a preference for OS / services or dont care? Ubuntu 16.04 is our normal platform but I can provide licences for RHEL7 or Windows Srv 2016 if needed
I presume you will want SSL enabled http repos. If you or whoever helps you wants to pull my personal email from the forum registration or PM on the forum with any specifics you need I can deploy and reply with access details etc and setup a plan to clone the primary repo and test. I will also give you the public ip(s) of the load balancer so that the *.uk.armbian dns records can be setup.

Problem is that there are at least 4 different RasPi PSU's that I have seen and not a single one of them is suitable for powering the tinkerboard which draws upto 3 x more current under load than any of the Pi models. The 2.5A Pi PSU we tested (comes with the Pi3 Kit) would only actually deliver ~1.4A reliably and when it gets hot it gets very unreliable. Thats why I asked  for the numbers off the PSU. The most power hungry PI model (3B) uses 30-40% of the total current than the tinkerboard at max load (see attached chart). Even if you connect the Pi PSU through the GPIO pins there still isnt enough current from any Pi branded PSU I have seen to power the tinkerboard reliably. As a general rule, RasPi accessories (like the boards) are made to very low standards and budgets and should be avoided.
 
If you can provide details for me to replicate your software, ramdisk, swap and workload I can have a look at reproducing the problem and finding a solution or at least a cause. The fact you have swap on SD make me shudder!
 
 

Problem is that there are at least 4 different RasPi PSU's that I have seen and not a single one of them is suitable for powering the tinkerboard which draws upto 3 x more current under load than any of the Pi models. The 2.5A Pi PSU we tested (comes with the Pi3 Kit) would only actually deliver ~1.4A reliably and when it gets hot it gets very unreliable. Thats why I asked  for the numbers off the PSU. The most power hungry PI model (3B) uses 30-40% of the total current than the tinkerboard at max load (see attached chart). Even if you connect the Pi PSU through the GPIO pins there still isnt enough current from any Pi branded PSU I have seen to power the tinkerboard reliably. As a general rule, RasPi accessories (like the boards) are made to very low standards and budgets and should be avoided.
 
If you can provide details for me to replicate your software, ramdisk, swap and workload I can have a look at reproducing the problem and finding a solution or at least a cause. The fact you have swap on SD make me shudder!
 
 

@TonyMac32 thanks!
 
Steps to use the ds3231 as system clock:
 
1) Add "echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new-device" to /etc/rc.local (if needed and above "exit 0")
2) In /lib/udev/hwclock-set comment out the following:
if [ -e /run/systemd/system ] ; then exit 0 fi if [ -e /run/udev/hwclock-set ]; then exit 0 fi then change the HCTOSYS_DEVICE=rtc0 to be HCTOSYS_DEVICE=rtc1
3)In /lib/udev/rules.d/50-udev-default.rules change the SUBSYSTEM=="rtc" line to:
SUBSYSTEM=="rtc", KERNEL=="rtc1", SYMLINK+="rtc", OPTIONS+="link_priority=-100" 4) In your hwclock udev rule make sure you have (/lib/udev/rules.d/85-hwclock.rules):
KERNEL=="rtc1", RUN+="/lib/udev/hwclock-set $root/$name"  

Extra sanity check, did you connect the RTC Ground to pin4 on the tinker?
 
Also you dont have the rtc-ds1307 kernel module loaded. If you reboot clean and "modprobe rtc-ds1307" does /dev/rtc1 appear without the "echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new-device"?
 
If yes to both then the next steps for setup are easy.

I havent tried Armbian yet but I had the same problem when I created a buildroot based firmware using eudev.
 
I added a new udev rule:
SUBSYSTEM=="drm", ACTION=="change", RUN+="/usr/local/bin/hdmi-toggle" in a new file (hdmi.rules) in /etc/udev/rules.d
 
Then save the bash script below to /usr/local/bin/ which will be triggered by the udev rule and toggle the display
#!/usr/bin/env bash USER="$(who | grep :0\) | cut -f 1 -d ' ')" export XAUTHORITY=/home/$USER/.Xauthority export DISPLAY=:0 ########### Settings ########### # Use 'xrandr' to find these DP="DP-1" VGA="VGA-1" HDMI="HDMI-1" INTERNAL_DISPLAY="LVDS-1" # Check /sys/class/drm for the exact location DP_STATUS="$(cat /sys/class/drm/card0-DP-1/status)" VGA_STATUS="$(cat /sys/class/drm/card0-VGA-1/status)" HDMI_STATUS="$(cat /sys/class/drm/card0-HDMI-A-1/status)" # Do no change! EXTERNAL_DISPLAY="" # Check to see if the external display is connected if [ "${DP_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$DP fi if [ "${VGA_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$VGA fi if [ "${HDMI_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$HDMI fi # The external display is connected if [ "$EXTERNAL_DISPLAY" != "" ]; then # Set the display settings xrandr xrandr --output HDMI-1 --auto else # Restore to single display xrandr --output HDMI-1 --off fi exit 0  

I havent tried Armbian yet but I had the same problem when I created a buildroot based firmware using eudev.
 
I added a new udev rule:
SUBSYSTEM=="drm", ACTION=="change", RUN+="/usr/local/bin/hdmi-toggle" in a new file (hdmi.rules) in /etc/udev/rules.d
 
Then save the bash script below to /usr/local/bin/ which will be triggered by the udev rule and toggle the display
#!/usr/bin/env bash USER="$(who | grep :0\) | cut -f 1 -d ' ')" export XAUTHORITY=/home/$USER/.Xauthority export DISPLAY=:0 ########### Settings ########### # Use 'xrandr' to find these DP="DP-1" VGA="VGA-1" HDMI="HDMI-1" INTERNAL_DISPLAY="LVDS-1" # Check /sys/class/drm for the exact location DP_STATUS="$(cat /sys/class/drm/card0-DP-1/status)" VGA_STATUS="$(cat /sys/class/drm/card0-VGA-1/status)" HDMI_STATUS="$(cat /sys/class/drm/card0-HDMI-A-1/status)" # Do no change! EXTERNAL_DISPLAY="" # Check to see if the external display is connected if [ "${DP_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$DP fi if [ "${VGA_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$VGA fi if [ "${HDMI_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$HDMI fi # The external display is connected if [ "$EXTERNAL_DISPLAY" != "" ]; then # Set the display settings xrandr xrandr --output HDMI-1 --auto else # Restore to single display xrandr --output HDMI-1 --off fi exit 0