WarHawk_AVG

Pishrink
 
simple script...just take the .img file...tell it to shrink the .img and voila...compressed down
sudo pishrink.sh [-s] imagefile.img [newimagefile.img]  

Different location now: https://github.com/armbian/build/blob/master/packages/bsp/h3consumption
 
 
It's possible to decompile/manipulate/recompile DT files but at least I do not plan on porting the tool to mainline. With mainline you better go with DT overlays and the stuff many people are interested in (limit count of CPU cores and networking options) is done in /etc/rc.local anyway. And some stuff like changing DRAM clock speed simply doesn't work with mainline at all.

Yes, it looks the same but in nice blue color!

I dont think you have to check the card, because most likely its caused by log2ram whcih is used ba armbian.
I also got "no space" in /var/log with my Pihole, because log2ram was set to 50MB in /etc/default/log2ram (50MB Ram-Disk)
 
@Igor is working with some other developers on a ZRAM option to replace this.
 
By now I have extended (on systems with >= 5122MB of Ram) the log2ram size to 150-250MB (depending on the System Ram).
Now my Pihole is working fine without getting "out of space"
root@bpi-a20(192.168.6.3):~# more /etc/default/log2ram # configuration values for the log2ram service # # enable the log2ram service? ENABLED=true # # size of the tmpfs mount SIZE=250M # # use rsync instead of cp -r # requires rsync installed, may provide better performance # due to copying only new and changed files USE_RSYNC=true #  
 

Symptoms:
Board does not boot Armbian from inserted SD card, but may boot other distributions (based on old/legacy u-boot).
Following or similar output can be grabbed from the serial console:
U-Boot SPL 2017.01-armbian (Feb 02 2017 - 03:04:04) DRAM: 2048 MiB Trying to boot from MMC1MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The key message here is "MMC: no card present"
 
Most likely cause:
Malfunctioning microSD slot card detect switch.
It can be verified either visually (with a magnifying glass) or electronically (with a multimeter) - at least in the slots used on Orange Pi boards and on Pine64 the pin near the switch should be shorted to the ground (i.e. SD slot casing) when card is inserted.
 
Illustration (example) of a working switch:

 
Verification (with a multimeter):
Probe 1 - slot pin near the switch (may be different for different slot types, but at least true for Oranges and Pine64)
Probe 2 - microSD slot casing or other parts connected to GND (not shown on the photo)
No card - circuit is open
Card inserted - circuit is shorted
 
Photos - card is not inseted on the left and is fully inserted on the right:
Orange Pi
 
Pine64 (switch is more visible)
 
Can it be fixed?
Yes if the switch is not broken completely, by carefully adjusting (bending) the stationary contact (left on the pictures and photos, it usually is a part of the SD slot casing) i.e using a needle so it touches the moving contact (mostly hidden inside the slot on the photos) when card is inserted and not touching it when it is not inserted.

Does this tool always verify burning results?
 
 
Does this tool always verify burning results?
 
 
Does this tool always verify burning results?
 
We had an awful lot of absolutely unnecessary support requests 2 years ago with users failing to burn images correctly (since SD cards were broken or card readers or whatever). When starting to only recommend Etcher this amount of absolutely unnecessary support requests declined drastically.
 
A burning tool that does no verify is a nightmare from a support point of view since unfortunately the average user doesn't get it that a lot of stuff can go wrong when burning SD cards. This problem is the whole reason why resin.io folks developed Etcher in the first place.
 
Recommending any burning tool that does NOT a verify the result by default is a really bad idea.

for Windows I do like the USB Image Tool (USB-IT) from
https://www.alexpage.de/usb-image-tool/
 
because it will startup much faster than the BIG etcher - and USB-IT is working fine for me since more than 2 years
 

You should purchase some ...
Personally, I've about 8 of them, some CH34x, some FTDI, some CP2102, some PL2303. So, when I need one, I don't have to unplugged one elsewhere !
They are cheap, between $1 and $2 ...

I've picked up a couple USB meters: https://www.amazon.com/gp/product/B01D9Y6ZFW/
 
And a chassis supply: https://www.amazon.com/gp/product/B018TDT20I/
 
I'll verify the meters with a Fluke I have access to (I'm a simple son of a farmer, I can't afford toys that nice) and will be setting up a multi-board bench feed.  There is actually good reason for my choice of power supply:
I got tired of having 6+ wall adapters lying about and no wall sockets left.  I have everything I need to make a proper power distribution block with the chassis supply. The USB powerstrips do not offer the flexibility of the MEANWELL, it can be adjusted from 4.5 to 5.5 Volts and has some acceptable regulation It is cheap. If I decide using it is a waste of time I can use it a permanent solution elsewhere. I plan on doing voltage dropout testing and power monitoring.  And having less of a mess, maybe...

Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
Basics:
It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

Illustration 1: AWG print on cable
Example:
If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
*this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
 
Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

Figure 2: Voltage drop of a copper cable at various thiknesses
If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
 
Case Study:
Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

Illustration 2: Setup vor measurement
FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
Table 1: Specification of the tested chargers

Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
Table 2: Tested micro USB cables

Results:
After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

Figure 3: Voltage drop at delivered current of all chargers
Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

Figure 4: Voltage without load, with load and on output and @powerbank
.
Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
Conclusion:
What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

Illustration 3: Recommended powersource
 
 

Just download a stock image, burn it and live happily ever after
 
 
Wrong use case. We are trying to make good things better
 
 
You could also light a match, put some Ketchup on your forehead and go swimming. This will not solve any problems either but is a lot of fun

-

How could you missed this ?
 
http://forum.armbian.com/index.php/topic/1580-nanopi-neo/
http://www.armbian.com/nanopi-neo

This is my final solution to this issue.   I hope it works consistently for everyone.
 
This applies to Armbian Jessie 5.15 Desktop.  No idea at this point about other versions.
 
After many trials, I find that wicd is broken.  Some confirmation can be found here: http://forum.armbian.com/index.php/topic/1775-wicd-gets-erroneous-bad-password/?p=14708
 
So abandoning wicd, I uncheck all "Automatcially connect to this network".
 
I turned to this post as a guide: http://askubuntu.com/questions/406166/how-can-i-configure-my-headless-server-to-connect-to-a-wireless-network-automati/406167#406167to use /etc/network/interfaces to do my connecting instead of wicd doing the connecting.
 
/etc/wpa_supplicant.conf
ap_scan=1 ctrl_interface=/var/run/wpa_supplicant network={ ssid="xxxxxx" scan_ssid=1 psk="yyyyyyy" } added to /etc/network/interfaces
auto wlan0 iface wlan0 inet dhcp pre-up sudo wpa_supplicant -B -iwlan0 -c/etc/wpa_supplicant.conf -Dnl80211 post-down sudo killall -q wpa_supplicant [The following may not apply to everyone.  It might have been needed in my case because I began experimenting by plugging in a wifi dongle when I was having trouble with the built in wifi.  But if you have issues described below, it may help]
 
I was able to connect to my wifi ONCE, after rebooting it would not connect.  I couldn't see why, until I did an ifconfig -a, and I saw that instead of wlan0, it was wlan1...  I then just changed things to wlan1, and it worked ONCE.   So why is it changing?
 
It came down to the contents of /etc/udev/rules.d/70-persistent-net.rules, which records the mac address of the wlan interface and assigns device ids accordingly.
 
According to this post: http://forum.armbian.com/index.php/topic/1738-opi-lite-mac-address/the realtek driver generates a random mac address under certain conditions. 
The contents of /etc/modeprobe.d/8189fs.conf in my setup had a mac address in it that would indeed cause a new random mac to be generated.
 
So I changed it to one of the random macs that it generated.   I'd suggest that you use 00:e0:4c:xx:yy:zz where you randomly make up 3 hex bytes for xx:yy:zz  However if you don't come to my house, nor have multiple orange pi's on your network, you can just copy the line.
 
/etc/modeprobe.d/8189fs.conf
options 8189fs rtw_initmac=00:e0:4c:88:b2:2c I then removed all the wlan* entries from /etc/udev/rules.d/70-persistent-net.rules
 
That last step may not be needed if you've never plugged in any wifi dongles to the usb port.
 
 
I'm just happy it works now, and is consistent.
 
I'm convinced that my previous attempts at various command line and network script fixes found here and elsewhere where hindered by wicd running and trying to connect (since I had "Automatically Connect" set).  Once I determined that wicd was in the way, I was able to get things working.
 
/K

I don't have access to my OPi lite right now, but I think there are the commands you should execute:
Create a conf file with encrypted credentials. You should execute the following: wpa_passphrase "ssid" "wirelesskey" > wpa_supplicant.conf Start wpa_supplicant supplying the previously created conf file: sudo wpa_supplicant -D nl80211 -i wlan0 -c wpa_supplicant.conf I think this should be it.

sudo dhclient wlan0
 
That will get you an IP address...

Hi,
 
Just joined to say thanks to all to those that are involved in the development of Armbian. I recently bought an Orange Pi PC after reading the internet full of people bitching about non-booting devices, HDMI issues, overheating and general crapness.
 
Decided to buy a Orange Pi PC nonetheless, found an old crap micro SD card, burnt Armbian (the internet has made it clear to not bother with the crap on the official Orange Pi website!) onto it and the thing booted without any issues! Typing this message from it as we speak in Iceweasel!
 
The thing only cost me 9 quid, so decided to donate what I would have wasted in cash on a Raspberry Pi 3 (which is anything but the 25 dollar SBC it seems to be advertised) as a donation to Igor and co.
 
I just run the Orange Pi PC out of the plastic static bag it came in LOL!
 
Once again, great work.

I'm using webmin, there is module "Linux firewall", where you can nicely configure everything about IPTABLES using mouse. Try it!

You will probably find it easier to use ufw which sets iptables for you, looks simpler than shorewall

Headers are present on the system, don't download anything especially not some generic.
cd /usr/src/linux-headers-3.4.110-sun8i/ make scripts # this you will skip in the future when we fix the building process cd git clone https://github.com/pvaret/rtl8192cu-fixes cd rtl8192cu-fixes make ARCH=arm # when done insmod 8192cu.ko # dmesg usbcore: registered new interface driver rtl8192cu

Thank you for your time Igor! I figured it out (noob). Desktop is a little out of the border on the hdmi screen. Using sudo h3disp -m 5. Desktop looks pretty cool!
 
Sent from my SAMSUNG-SM-G900A using Tapatalk