sooperior

Hi All,
Just wanted to share a good story using armbian. I have used in the past 1-wire probes for temperature, and the process included decompiling, editing and recompiling dtb for my Banana Pi M1, which was not easy at all. Every firmware update deleted by changes and had to redo de recompilation.
 
With latest kernels and armbian version, the process is now extremely easy, just edit:
/boot/armbianEnv.txt
 
Adding this lines:
overlays=w1-gpio
param_w1_pin=PI3             # desired pin(7th pin (GCLK) or number 4 on first column where number 1 is +3V)
param_w1_pin_int_pullup=1     # internal pullup-resistor: 1=on, 0=off
 
I just struggled a little bit to find the GPIO code (decompiled dtb and checked possible candidates).
 
Information about temperature is here:
cat /sys/bus/w1/devices/XX-YYYYYYY[this is your probe serial, if you have more they will be in /sys/bus/w1/devices/] /w1_slave
 
You have plenty of information here, but don't need to do all they explain, just my edition has been enough:
http://linux-sunxi.org/1-Wire
 
 
 

My acknowledge to these guys too, and also to zador.blood.stained. The involvement and support I have seen in this project is lot better than most commercial initiatives. I donated because they really deserve it, and that's the real way to say thanks and keep up the good work.

My acknowledge to these guys too, and also to zador.blood.stained. The involvement and support I have seen in this project is lot better than most commercial initiatives. I donated because they really deserve it, and that's the real way to say thanks and keep up the good work.

Hi,
 
unattended-upgrade is active by default. So updates (except kernel) are installed automatically. Have a look at /var/log/apt/history.log* for the installation history.
 
Bye,
wahlm
 
From my a20lime2 jessie headless server:
 
Start-Date: 2016-12-14  06:31:10
Commandline: /usr/bin/unattended-upgrade
Upgrade: apt:armhf (1.0.9.8.3, 1.0.9.8.4), libapt-pkg4.12:armhf (1.0.9.8.3, 1.0.9.8.4), apt-utils:armhf (1.0.9.8.3, 1.0.9.8.4), libapt-inst1.5:armhf (1.0.9.8.3, 1.0.9.8.4), apt-transport-https:armhf (1.0.9.8.3, 1.0.9.8.4)
End-Date: 2016-12-14  06:31:25

Start-Date: 2016-12-24  06:38:47
Commandline: /usr/bin/unattended-upgrade
Upgrade: libxml2:armhf (2.9.1+dfsg1-5+deb8u3, 2.9.1+dfsg1-5+deb8u4)
End-Date: 2016-12-24  06:38:49
 

I know it is just shouting in the desert but nowbody should buy a board and then ask a third party for support.
Instead we all should write the seller and say: You know what? Your product looks great but I will not buy a single one neither advice anyone to buy until third parties (sunxi, armbian...) say yes, this board has released all required docs to support it.
 
Or if you have purchased one return it back: You sell it as open source. I have found your sources are missing. Here it is and give me my money back

I know it is just shouting in the desert but nowbody should buy a board and then ask a third party for support.
Instead we all should write the seller and say: You know what? Your product looks great but I will not buy a single one neither advice anyone to buy until third parties (sunxi, armbian...) say yes, this board has released all required docs to support it.
 
Or if you have purchased one return it back: You sell it as open source. I have found your sources are missing. Here it is and give me my money back

I suggest you use the search function in the forum for an answer. Before opening a new topic

Hi
I have a suggestion to modify update-mot.d script 30-sysinfo.
It reports battery chargin or not depending on percentage (if <100% then is charging):
 
# Battery info for Allwinner # kernel 4.4+ axp_dir="/sys/power/axp_pmu" if [[ -e "$axp_dir" ]]; then         status_battery_connected=$(cat $axp_dir/battery/connected)         if [[ "$status_battery_connected" == "1" ]]; then                 status_battery_charging=$(cat $axp_dir/charger/charging)                 status_ac_connect=$(cat $axp_dir/ac/connected)                 battery_percent=$(cat $axp_dir/battery/capacity)                 # dispay charging / percentage if [[ "$status_ac_connect" == "1" && "$battery_percent" -lt "100" ]]; then status_battery_text=" charging"                 elif [[ "$status_ac_connect" == "1" && "$battery_percent" -eq "100" ]]; then status_battery_text=" charged"                 else status_battery_text=" discharging"                 fi         fi fi     However, at least on banana pi M1 (A20) it can be below 100% and not charging, Seems that the PMU doesn't charge just for 1-2%. So we can just use driver info to check if it is really charging, like this:   # Battery info for Allwinner kernel 4.4+ axp_dir="/sys/power/axp_pmu" if [[ -e "$axp_dir" ]]; then         status_battery_connected=$(cat $axp_dir/battery/connected)         if [[ "$status_battery_connected" == "1" ]]; then                 status_battery_charging=$(cat $axp_dir/charger/charging)                 status_ac_connect=$(cat $axp_dir/ac/connected)                 battery_percent=$(cat $axp_dir/battery/capacity)                 # dispay charging / percentage if [[ "$status_ac_connect" == "1" && "$status_battery_charging" == "1" ]]; then status_battery_text=" charging"                 elif [[ "$status_ac_connect" == "1" && "$status_battery_charging" == "0" ]]; then status_battery_text=" charged"                 else status_battery_text=" discharging"                 fi         fi fi   Hope someone else finds it useful  

Just FYI: Orange Pi Plus 2E is now available for $35 and shipping costs remain the same (pretty low compared to some competitors): 
 
http://aliexpress.com/store/product/Orange-Pi-Plus-2-E-H3-Quad-Core-1-6GHZ-2GB-RAM-4K-Open-source-development/1553371_32665196281.html
 
Please remember that this board was designed based on community requests (dropping the slow GL830 USB-to-SATA bridge and the internal USB hub and exposing all 4 USB ports physically to the outside) and should make up for a really nice server with 2 GB DRAM, Gbit Ethernet and 4 USB ports (3 real hosts ports and one Micro OTG).
 
So now we have the following H3 boards with Gigabit Ethernet:
 
Banana Pi M2+ for $33 (1 GB RAM, 8 GB eMMC, no USB hub / no shared bandwidth, only 2 USB host ports useable) OPi Plus 2E for $35 (2 GB RAM, 16 GB eMMC, no USB hub / no shared bandwidth, 3 USB host ports useable) OPi Plus for $39 (1 GB RAM, 8 GB eMMC, GL830 slow USB-to-SATA, internal USB hub / shared bandwidth) OPi Plus 2 for $49 (2 GB RAM, 16 GB eMMC, GL830 slow USB-to-SATA, internal USB hub / shared bandwidth)   SinoVoip said to release also a cost down version of M2+ without eMMC and WiFi that might be then the cheapest GbE equipped board. But since there you only get 1 GB DRAM (which might be totally ok for most use cases -- please compare with http://www.linuxatemyram.com if in doubt) and they don't use a programmable voltage regulator and always feed the SoC with 1.3V VDD_CPUX core voltage IMO spending a few bucks more to get OPi Plus 2E with twice the RAM/eMMC size, 1 more USB port, more performance and also lesser temperature/consumption is the better idea.   BTW: WiFi capabilities not mentioned intentionally since in my opinion those cheap SDIO 2.4 GHz implementations are all not worth a look (or time/efforts to get the crappy drivers running)

And Gentoo, OpenSuSE, CentOS, Fedora and maybe a few hundred other Linux distro variants that might run on armhf/arm64 hardware. What's this whole thread about?
 
BTW: Armbian is different. It's not just another boring Linux distro (since then you could also use the plain Debian or Ubuntu stuff) but it's an automated build system capable to use Debian/Ubuntu and the images created in the end are the result of developing this build system over the years combined with a lot of knowledge regarding 'how to do it right'.
 
You won't have fun with this small ARM boards if not every detail here and there matches perfectly. And that's what Igor started with and what the Armbian team still tried to provide.
 
Basically three parts are involved: bootloader stuff (currently that's proprietary SoC specific bootloader stuff + u-boot, later we might have to deal with UEFI on aarch64), the kernel and the rootfs containing a Linux distro. The last part is the most irrelevant/boring one, the two former are way more important. As an example: sometimes kernel stuff won't work if hardware isn't initialized correctly already by u-boot and so on. That's what Armbian is about: Doing things right. And the distro used is close to irrelevant (the Armbian build system currently also allows to replace the whole OS distro in the last step with some other armhf/arm64 Linux rootfs -- somewhat weird but it works and would in many cases provide superiour results compared to 'original ARM Linux images')

Hi,
I'm afraid this might not be the best place. Armbian, or rather the devices it runs on, requires some technical knowledge/linux background.
If I were you I recommend using something like Debian, Ubuntu or Linux Mint (Mint is easy and similar to windows 7/Vista) in a standard PC. You can find plenty of tutorials on how to install / use them and most of the time you'll be working with a graphical interface.
 
You are more than welcome to use armbian (after you have learned a bit of linux) but as a starting point... Honestly, I don't recommend it. Armbian is based on debian (also Ubuntu and Mint), so you can start by learning Debian or its derivatives and then give armbian a try.
 
PS: You know that armbian can only run on soc devices, not in a standard PC, don't you?

EDIT: This is NOT about a (hidden) backdoor but just a local privileges escalation that affects one single 3.4 kernel variant for 2 Allwinner SoCs. In case you came here through lurid headlines please read this comment here first and help stop spreading further BS like "all Allwinner devices contain a hidden backdoor" -- the code has been found since Allwinner could be convinced to open their Github repos in the past so everyone is able to audit their Android kernel source!
 
 
 
It has been brought to our attention two days ago on 2016-04-30 in linux-sunxi IRC that Allwinner's 3.4 legacy kernel for H3/A83T/H8 contains a nasty local privileges escalation. Any process running with any UID can become root easily by simply doing this:
echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug Combined with networked services that might allow access to /proc this means that this is also a network enabled root exploit. As usual we fixed such an issue within a few hours, on May 1st new Armbian 5.10 images were rolled out and in the meantime the fix is also in Armbian's apt repo so please upgrade now (apt-get update/upgrade or start with a fresh OS image) if you're affected! If you're already running Armbian 5.10 then this vulnerability is already fixed.
 
This security flaw is currently present in every OS image for H3, A83T or H8 devices that rely on Kernel 3.4: this applies to all OS images available for Orange Pis (except Armbian 5.10 available since May 1st), any for FriendlyARM's NanoPi M1, SinoVoip's M2+ and M3, Cuebietech's Cubietruck + and Linksprite's pcDuino8 Uno
 
We informed all vendors where possible also two days ago (FriendlyARM and SinoVoip took notice, the others still ignore the issue) FriendlyARM: https://github.com/friendlyarm/h3_lichee/issues/1 SinoVoip M3: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/10 SinoVoip M2+: https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/issues/1 Cubietruck +: https://github.com/cubieboard/Cubietruck_Plus-kernel-source/issues/2 LinkSprite pcDuino8 Uno: https://github.com/pcduino/pcduino8-uno-kernel/issues/3 Users of any of the available OS images for H3 based Orange Pis are somewhat lost since none of the OS images or kernels used for these are maintained any longer. Loboris disappeared (so the opened issue is more like a reference) and Xunlong themselves do not maintain their software at all (not even possible to open an issue there).   In case some readers here do also have accounts at Orange Pi forums, please spread the word and inform the users that their OS images are exploitable unless they already use Armbian 5.10. Same applies to Banana Pi forums, please spread the word there also that all M3 and their M2+ OS images are affected (I deleted my account there since talking to @sinovoip is like talking to a wall and just makes me sick, but it might be worth the efforts to try to warn their users)

Now with the patch which included in armbian 5.10 sunxi_ss seems to work correctly.

Sorry, I forgot attachments

Ecryptfs was disabled in kernel config - it will be available in new kernel release.
 
Also I would recommend blacklisting sun4i_ss to prevent data corruption until issue is resolved.