rodolfo

Censorship is ALWAYS wrong. No matter how much you disagree with someone's opinion, the right to voice an opinion is crucial in any civilized discourse. In a weak and decadent world only "nice" people are tolerated, while the dedicated and ambitious ones who actually get things done and are ready to stand up for a cause are loathed.

@jean-philippe
 
Sorry to hear it took you so long to find Armbian. You'll find an entirely different culture here than what you might be used to. Armbian is centered around working software, not marketing hype. While you still might be struggling with HW/SW bought 2 years ago as the seller's website is a sadly abandoned construction site ( with the notable exception of the excellent OpenElec ) Armbian turns useless OPI bricks into well-performing little jewels with predictable behaviour. I'm strictly speaking as a user and my contribution to the project is some forum help, tutorials and documenting successfully solved use cases.
 
So why not download a current Armbian, spend some time in reading documentation and forum help ? You spent 2 years on '99% fully working stable' , why not invest some hours to experience a stable and tested solution ?
 
Welcome to Armbian !

@jean-philippe
 
Sorry to hear it took you so long to find Armbian. You'll find an entirely different culture here than what you might be used to. Armbian is centered around working software, not marketing hype. While you still might be struggling with HW/SW bought 2 years ago as the seller's website is a sadly abandoned construction site ( with the notable exception of the excellent OpenElec ) Armbian turns useless OPI bricks into well-performing little jewels with predictable behaviour. I'm strictly speaking as a user and my contribution to the project is some forum help, tutorials and documenting successfully solved use cases.
 
So why not download a current Armbian, spend some time in reading documentation and forum help ? You spent 2 years on '99% fully working stable' , why not invest some hours to experience a stable and tested solution ?
 
Welcome to Armbian !

@jean-philippe
 
Sorry to hear it took you so long to find Armbian. You'll find an entirely different culture here than what you might be used to. Armbian is centered around working software, not marketing hype. While you still might be struggling with HW/SW bought 2 years ago as the seller's website is a sadly abandoned construction site ( with the notable exception of the excellent OpenElec ) Armbian turns useless OPI bricks into well-performing little jewels with predictable behaviour. I'm strictly speaking as a user and my contribution to the project is some forum help, tutorials and documenting successfully solved use cases.
 
So why not download a current Armbian, spend some time in reading documentation and forum help ? You spent 2 years on '99% fully working stable' , why not invest some hours to experience a stable and tested solution ?
 
Welcome to Armbian !

Nah, I said that the whole 'issue' wasn't that much of an issue (especially when using a distro that is designed to be a single-user system where everything runs with UID==0 like DietPi). And that puzzled me -- why do DietPi users who use a distro that is designed to be 'root only' fear 'root exploits'? Was just for my personal understanding and to get stuff publicly documented as it is now.
 
I don't believe any discussion will help. We tried to support DietPi as much as possible over the last 6 months (and we're glad that we could help providing a lot of improvements for DietPi users) but now for me a red line has been crossed (twice). We tried several times to explain why and how Armbian's understanding of security differs from DietPi's (to no avail) and I got a bit angry with Igor since he accepted an absolutely useless PR. But as soon as someone starts censoring opinions it's over. Same with blaming Armbian being responsible for DietPi not fixing 'high priority' bugs in time: https://github.com/Fourdee/DietPi/issues/312#issuecomment-253204102
 
Sorry, if it's about preventing access to a sysfs node /proc/sunxi_debug/sunxi_debug then simply do it: chmod 000 /proc/sunxi_debug/sunxi_debug (and you're already done. If you lack the skills to build an OS image from scratch then provide a fix for your users and don't blame others providing you with a build system for your requirements you can't cope with due to your various special requirements)
 
Anyway: I don't support people deleting stuff I write (any more). Fortunately for DietPi users other Armbian devs handle this differently so DietPi users can still rely on a solid foundation for their distro of choice. The collection of links above is just necessary for the commit message when I'll remove the unsafe and absolutely useless code that has been submitted recently to Armbian in a few days (since there's no excuse to weaken default Armbian security)

BTW: Funny example how to deal with 'rootmydevice' on a distro where everything should happen as root anyway: 
 
- http://web.archive.org/web/20161011190545/https://github.com/Fourdee/DietPi/issues/329#issuecomment-253011573
- vs. https://github.com/Fourdee/DietPi/issues/329#issuecomment-218887283
- vs. https://github.com/Fourdee/DietPi/issues/312#issuecomment-253002887  
I wanted to understand why users who chose to use a distro that does not care that much about security did care about 'rootmydevice' (they are already logged in as root so why do they fear a root exploit?!). Doesn't work, distro maintainer constantly deletes my questions
 
This scares me a bit since censorship is not exactly the right way to address security concerns.

Corporation mission, vision & marketing chit chat is pure bullshit, spam, if this is more understandable. Nothing to take seriously into account.

It gets simpler if you use an SBC that has everything already on board that's needed. Next step is getting two C.H.I.P. for $9 each: https://irclog.whitequark.org/linux-sunxi/2016-09-22#17642124;
 
AXP PMICs are great since they measure all the time and can be fed with 3 different power sources at the same time (DC-IN, OTG and battery). This allows a lot of different modes to test through, the only open question is whether the device starts automagically when power is provided through DC-IN again (chg-in called with the C.H.I.P.). From other AXP209 equipped devices I know that they power on automagically when fed with DC-IN but require the press of a button when power is provided through OTG or battery connector only. I hope it's the same with C.H.I.P.
 
Edit: with a C.H.I.P. (or any other AXP209 equipped device with battery support that treats DC-IN and OTG differently) you could do some fancy stuff. 
Most simple mode that works always: Attach the solar panel to DC-IN and add a battery. AXP209 will compensate from voltage fluctuations on DC-IN by using the battery partially. If voltage on DC-IN gets too low or no power at all it will rely on the battery only while you're able to measure all the time battery's capacity and can initiate a clean shutdown when a certrain treshold is reached Different mode: get a dual port solar panel, connect one port to DC-IN (chg-in), the other to a powerbank and the powerbank to OTG. Now AXP209 will take power by default from DC-IN, will compensate voltage drops there by using the powerbank on OTG and since you can monitor this behaviour over time you get the idea when it gets too dark and can estimate how long it will take until the powerbank goes flat to initiate a clean shutdown More advanced mode: As N° 2 but add a LiPo battery to AXP209's battery connector. This would be the most safe and most expensive mode (and needs some testing since it might be that AXP209 in this mode ignores the powerbank connected to OTG port. If that's the case using solar panel + powerbank on DC-IN would be the better idea, of course combined with a 2nd battery under AXP209 control) BTW: the cheap Pine64 could also implement N° 1 (not sure whether AXP803 drivers need some attention, at least in pine64 forum a lot of weird stuff is written regarding batteries), but not sure about 2) and 3) since there the OTG port is exposed as normal Type A port normally used to provide vcc-5v to connected USB peripherals
 
Edit 2: 'Any AXP equipped device that is able to...' is not that much, especially if it should be affordable. The rather cheap 'LinkSprite pcDuino3 Nano Lite' (available for $15 in the US) provides neither a battery port nor powering through OTG (hardwired to DC-IN), the cheapest other A20 alternative (Banana Pi) is still pretty expensive, same applies to A10 boards so at the moment we're talking solely about the C.H.I.P. (which is a bargain given that it already comes with 4GB NAND and WiFi/BT) and Pine64.
 
Edit 3: One A10 device which can implement all 3 modes above seems to be sold out currently (can get it for 19,-€ here): https://www.amazon.com/dp/B00I0WUR2Q (performance identical as with C.H.I.P. but more connectors and in case a large disk would be needed Olimex' Lime has an own boost converter to provide power to a connected SATA disk so combining this with a cheap solar panel providing 5V would be enough)

Well ...
 
- you dont provide a usage manual for your script.
- raw archives need a full understanding of partitions and filesystems !
- when you copy and compress a fs, you loose some crucial information : the size of partition needed to restore it. You need to store that somehow because you will end up with archives which you dont know why you have done it, and that require long and tedious operation to restore or simply identify.
- it is always much more difficult to restore and manage archives than to make archives ...

"everyone uses the tools he used already last century"
 
Well tools are only part of the problems. In particular when people dont know if or why they need it. (And in that case tools tend to become the problem)

For battery-buffered operation ( charging from solar or AC-DC DC-DC chargers ) see http://forum.armbian.com/index.php/topic/1737-optimize-orange-pi-pc-for-power-cut/#entry13467
 
Battery buffers could be stacked in series to prolong runtime without charging or run in parallel to allow hot swapping of power supplies for added robustness.
 
 
 
Bingo. Use low voltage on battery side to let ATTINY trigger OPI shutdown via GPIO pin, let ATTINY cut power to OPI after sufficient delay and restart power when sufficient battery voltage is available again.

Looks fine.

AFAIK Wayland/Weston needs "true" GPU acceleration, on devices with Mali GPU this means you need special GLES/EGL libraries with Wayland support.
https://github.com/linux-sunxi/sunxi-mali/issues/10

We (most work was done by Zador) just spent months to rework desktop that now have more features and its properly packed that can be installed on the top of CLI and upgrade, hopefully, works fine. We are releasing it within one week.
 
Armbian tends to focus on base problems, server / iot functionality, since most of those boards have problems in the ground level and it's irrelevant if we add on it's rotten base an "smooth, high quality desktop". This is what some board manufacturers might do to impress their potential buyers.
 
We are happy with current level of smoothness and quality of the desktop but project is open and we will support any initiative from outside.

I've generally found SDcards less reliable than their USB counterparts and the physical handling of USB3 sticks is usually much smoother with PCs and notebooks. This is just a personal preference. For OPI ONE/LITE I put boot stuff on an old SDcard of any class/size and the rootfs on a USB3 stick.
 
A fast flash disk does of course nicely complement a fast SDcard if you need to add low power storage. As I already mentioned, OPI ONE and OPI LITE both with USB flash and wifi run from simple dual-18650 battery pack. HDD and SSD will meet some serious limits there.
 
You are of course perfectly right in pointing out the speed nonsense promoted in benchmark infomercials. An SBC will always be a carefully balanced matched system of storage, computing and I/O. It just happens that the small OPI H3 boards running with stock legacy Armbian show very pleasing balanced performance.

I dont care for functionalities that make software unusable. Browsers are designed for use on 3 GHz multicore processors, and so are also web pages with "experience improving" sniffing javascript abuses.
 
So I use a privoxy/polipo front-end to purge pages and I disbled local cache. (At least, you should use local filter extensions). Firefox DBs are another problem : I donnot want firefox were out my SD card or even use a costly SD card just for "improving my experience". I dont save work files in local but on an NFS server.
 
I approve at 110% tkaiser's advice on using eMMC. But in the meantime, I currently use an A20/bpi1 as desktop and deported home and firefox gigacache on NFS, which is a bottleneck (even with no document cache). The ideal solution would be to use a ram FS, but what would be the best solution ?

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

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

When properly powered, the system 100% of the time does not go down. Actually TESTED on stock Armbian with stock settings on a dozen boards. This also has been TESTED and works on all sorts of Raspis as well. I'd strongly advise you to rethink the approach in dealing with SBCs. The world is full of hearsay, FUD and endless repair technology for unproven untested theories. Armbian is for doers and by doing and sharing actual successes we grow.

Really please STOP spreading FUD like that!
If you care about FS corruption then read carefully through post #2 of this thread -- journaling will prevent FS corruption at the cost of a bit more writes so people fearing their SD card wearing out too early (for whatever reasons, most probably FUD or experiences with Raspberries again) should now buy a good and recent SD card showing high random IO values since this is already an indication that there's a good controller in the card able to do wear leveling the right way. SD card corrution at power loss is a Raspberry Pi phenomenon. This is not a known issue with any of the boards we support to my knowledge Nowhere in linux-sunx wiki an own /boot partition is recommended. Since it's not necessary. The reason Raspbian or any OS image for Raspberry Pis needs 1) an own /boot partition and 2) this has to be FAT32 is caused by Raspberries using SoCs where the ARM cores are no 1st class citizens. The SoC boots on the VideoCore IV which can only deal with FAT16/FAT32 and therefore all the proprietary stuff needed to boot up the VC4 needs to be on an own partition that has to be FAT32 (that's also the reason so many SBC users waste their time with 'SD formatter' since larger SD cards come preformatted with exFAT but old VC4 can't deal with that). Neither Linux nor the ARM cores are involved at this stage. Please be aware that I try to simulate FS corruption since weeks to no avail. When I did all the H3 consumption testing and the NanoPi NEO stuff I never did a clean shutdown. Always pulled the plug, inserted the card in the next H3 device and continued there. As expected sometimes latest changes were missing (since Armbian uses a commit interval of 600 seconds) but I didn't had a single FS corruption. Tried really hard but to no avail If people would start to realize that the Raspberry Pi is both different and somewhat special regarding two issues (weird booting and prone to SD card corruption) and especially if they would stop trying to adopt settings/behaviour that are necessary with RPi's Broadcom SoC but not on any of the SBC we support, a lot of time and efforts could be saved.
 
Again: if you want to make the installation on your SD card more immune against power losses then enable journaling (read Zador's explanation above!). Even better: avoid power losses. No need for FAT32, no need for a separate boot partition, no need to set anything read-only, not that much need to care at all.
 
The symptoms you described ('has failed about 3x times now') sound like you remotely changed network settings on a headless system, locking yourself out and being kept locked out after the reboot? You're telling 'entire partition is corrupted...and it can't even get to the boot kernel' which requires a serial console to diagnose but then the question arises how you've been able to lock yourself out before? This pretty much sounds like the usual 'something went wrong, let's assume it's that what I assume based on experiences with something else' (RPi/Raspbian in that case).
 
On a related note: Armbian contains already even improved thermal/dvfs settings. No need to follow outdated methods from an orphaned forum that might still exist

Bronco = TKaiser in this forum
 
Why not simply taking the original image with optimiziations included ?
 
And information which and how to use it. http://docs.armbian.com/User-Guide_Getting-Started/

Hotcloning Armbian SDcard ( tested on OPI ONE/LITE  )
 
You need a USB card reader and Linux. With a running Armbian you've got all the Linux you'll ever need. The aim is to copy the entire system on SDcard including bootstuff and our personal belongings, roots, cats, dogs etc... to a new SDcard. The new card must only hold the data content of the old card and can be of different size (smaller, larger). The new SDcard contains one big partition of maximum size and is bootable.
 
Setup
 
1. Download the script and rename it to armbian_hotclone.sh
 
2. Start your OPI ONE with the SDcard you want to copy and connect to it via ssh ( or putty ).
 
3. The script needs to be run on the board ( in my case OPI ONE ). Copy the script to your board and make it executable ( chmod +x )
 
4. Attach a USB card reader to the OPI ONE. Make sure there is NO OTHER USB storage attached.
 
Running the script
 
5. Insert the target SDcard into the card reader and check it has been detected ( lsblk )
 
6. Run the script as root ( sudo ) and depending on the card reader and SDcards wait 10-60 minutes
 
Test the new SDcard
 
7. Shutdown the OPI ONE.
 
8. Replace the SDcard in the slot with the new copy
 
9. Make sure the OPI ONE boots correctly before you put the SDcard into the cookie jar for desaster recovery and worse.
 
Notes on usage
 
The script is just a skeleton to showcase the basics. A break needs to be added to prevent it from running accidentally and eating up disks.
 
Warning : Do NOT run the script on your host
 
armbian_hotclone.sh.txt
 
Enjoy !

I think that a fan controller is a nice thing to play with. But when you use Armbian with H3 devices there's really no need for a fan, since a quality heatsink is enough (you don't even a heatsink if you are able to accept that throttling will happen earlier, you only loose performance but that's it -- your H3 is always save). Please read through post #2 here: http://forum.armbian.com/index.php/topic/1850-pi-fan-issues-on-orange-pi-pc/?p=14192
 
Apart from that I've looked a lot into how consumption with H3 boards can be minimized the last weeks. Less consumption is also less temperatures. To me it seems absurd to add components that waste additional energy to only lower cosmetically the temperatures of other components especially since they're made for high temperatures. H3 is not an animal or a human being that gets hurt by temperatures exceeding 40°C. It's a chip rated for up to 125°C

-
 

I added a script lurking around on my disk for some time to Armbian's repo to be hopefully included into future Armbian releases when testing looks good: https://github.com/igorpecovnik/lib/blob/master/scripts/h3consumption
 
Since it's just a script you can include it in your running Armbian installation simply by downloading it from Github -- try it this way please:
sudo -s wget -q -O /usr/local/bin/h3consumption "https://raw.githubusercontent.com/igorpecovnik/lib/master/scripts/h3consumption" chmod 755 /usr/local/bin/h3consumption h3consumption -H h3consumption -p The last 2 calls will show the verbose help text along with current settings. This might then look like this:
 
 
 
Mode of operation/test:
Please read through the description (-H output) first and check also the referenced links Use -p to get currently used settings Use the other switches to modify settings Do not use -p now but instead do a reboot first and then check again -p You might also have a look at /etc/rc.local and /etc/defaults/cpufrequtils to get an idea where the script does things for a better understanding Two examples (will go into details later in different thread😞
On an Orange Pi Plus 2E 'h3consumption -c 1 -m 1296 -d 408 -g off -e fast' reduces default idle consumption from 1650 mW by 780 mW to just 870 mW On an Orange Pi Lite 'h3consumption -D 132 -c1 -g off -u off' reduces default idle consumption from 1060 mW by 660 mW to just 400 mW (same low consumption running identical settings possible with NanoPi M1, Orange Pi One/PC/PC Plus and maybe the larger boards too when GBit Ethernet PHY can be completely disabled) Please note: the -D switch allows to use DRAM clockspeeds that are way below Allwinner's defaults and what's expected to work ok (since DDR3 shouldn't be clocked lower than 300 MHz and Allwinner used 408 MHz clockspeed as lower limit). While clockspeeds as low as 132 MHz seemed to work reliably in my tests and it should be ok to test these out when having in mind that this is an experimental feature you won't be able to go lower than 408 MHz anyway without a kernel patch (available in post #14 here) with all available official Armbian releases. So you've to either use the kernel .deb I provide in the other thread or wait for a new round of Armbian images (no idea how Igor's plans look like)