Jump to content

Optimize Orange Pi PC for power cut


Fazor

Recommended Posts

Hello, I leave in a place where we occasionally get really heavy storms or the power gets cut for some reason. This most often does not happen more than five minutes, but there has been longer cases. Now, this poses an obvious problem with my headless server (Orange Pi PC btw). I went on a week trip last month, to discover the development board I needed was completely down. I called a friend and the power had indeed been cut off in my neighbourhood, but my server would no longer respond over SSH. I hard reset the server by power cable and tried restarting sshd (after getting home a week later), just to get warning that the action of the service was queued and afterwards warning like these unable to enter anything directly to the server anymore, It has network connection and all, but sshd just died and won't accept connections for some reason.

 

Now while I'm not sure how this broke, I just want to know if it's possible or prone for it to die like this after a power cut-off, and if I can optimize it to completely restore itself if that happens. For now I have everything I need in a safe chroot environment (where nothing has been touched since the shut-off as everything can only be started manually), so I plan to reinstall the OS to fix potential issues which might have broken this installation. Could it had been related to how the data is set to commit each 600 secs, or maybe I broke it already myself before the power outage? Either way these kind of power outages has happened already a lot with my Raspberry Pi, and it has encountered no issues. So I was wondering if I could somehow optimize armbian to be prepeared for power cut-offs? I am pretty new to armbian, so at most I only installed the base OS, updated it to newest definitions and kept what I would run in a stretch chroot.

 

Any opinion/help is accepted with great pleasure, I can provide any logs if you would like.

Already talked a bit in sunxi-linux IRC about how I could have hooked up a UPS-like device by using a 20k mAh power bank possibly, but it would from what I can see not be a viable solution unless I get a very expensive UPS.

Link to comment
Share on other sites

First, check if your hardware is still OK by loading a fresh Armbian installation from a new SD card.

 

Second, to trade off reliability over performance, it's a good idea to use "sync" instead of "data=writeback,commit=600" options for mounting rootfs - this should help preventing filesystem corruption in case of unclean shutdown. Also you will need to remove "journal_data_writeback" from default rootfs mounting options with tune2fs.

 

Third, for UPS, define "very expensive". There are 12v UPS devices like this, combined with lead-acid battery and 12v-5v step-down converter it will give you enough uptime to survive even long power losses.

 

Another thing - it may be a good idea to enable HW watchdog, but I didn't test how well does it work (if it even works at all) in legacy kernel for H3.

Link to comment
Share on other sites

It is not for the OPi, but none the less it might be an interesting concept for your problem.

 

piCore Player

After booting everything is running from RAM so there is no writing to the SDcard and therefore no risk of corruption of your card - just pull the power if you need to.

Link to comment
Share on other sites

"Now while I'm not sure how this broke, I just want to know if it's possible or prone for it to die like this after a power cut-off, and if I can optimize it to completely restore itself if that happens."

 

If you want to optimize and/or secure your server, you first have to know why it broked. If the problem is sshd, first try starting it manually. In case of problem, you have to gain access to the system, check disk integrity, verify date setup, check logs ... I dont think that you can find a solution out of the box with zero configuration and knowledge to handle special needs on headless/unattended/remote systems. The ultimate maintenance solution for a remote server is in all cases to have remote access to the serial console.

 

If your needs do not justify costly solutions, you must at least make backup of your data and perform tests of cold start, start after power failure (your system can enter an interactive restore session) ... My experience with an RPI is that I lost half of my files after a power failure : the culprit was the SD card and and mechanical contacts wich is not a good solution for high availabality in case of vibrations ! So you have also to think of the kind of harware you are using ...

Link to comment
Share on other sites

Already talked a bit in sunxi-linux IRC about how I could have hooked up a UPS-like device by using a 20k mAh power bank possibly, but it would from what I can see not be a viable solution unless I get a very expensive UPS.

 

Just keep it simple. You do not need an "expensive UPS" or large power bank to keep a simple tinkerboard ( no insult intended, tinkering IS engineering ) running.for a couple hours without any charger power.

 

A "power bank" is just batteries combined with charging/discharging circuitry. Charging/discharging are mutually exclusive unless you pay extra for "passthrough charging". Just use two regular power banks and hook them together on the battery side ( + to + / - to - ). You can now charge the double-pack power bank through one circuit and draw power from the other. Unplug charger and it still runs for a couple hours, replug and reload the batteries.

 

Viability of this approach depends largely on connected peripherals as current is limited by max.charging/discharging capability of the power bank circuitry. Powering disks ( peak >1A draw ) is not reconmmended, but OPI ONE/LITE with wifi and USB storage have been running fine for weeks with random plugging/unplugging of power supply. Presently I'm successfully using VERY cheap power banks and run them in parallel when needing more juice.

 

The fancy luxury version of this poor man's UPS would sense charging power via GPIO pin and use some program logic to gracefully shut down the board after extended power-out (some hours).

Link to comment
Share on other sites

First, check if your hardware is still OK by loading a fresh Armbian installation from a new SD card.

 

Second, to trade off reliability over performance, it's a good idea to use "sync" instead of "data=writeback,commit=600" options for mounting rootfs - this should help preventing filesystem corruption in case of unclean shutdown. Also you will need to remove "journal_data_writeback" from default rootfs mounting options with tune2fs.

 

Third, for UPS, define "very expensive". There are 12v UPS devices like this, combined with lead-acid battery and 12v-5v step-down converter it will give you enough uptime to survive even long power losses.

 

Thanks for those tips, I will try using the mount options when I do my tests (forcibly drag out power and up again) to make sure my system can survive power cuts properly. I did re-install armbian just now right before writing this reply and to my surprise everything works perfectly again. The UPS is something I will look into in case I do need it. I don't have that many power cuts, and there is this issue where my internet would take much longer time to come back up then the electricity.

 

 

 

If you want to optimize and/or secure your server, you first have to know why it broked. If the problem is sshd, first try starting it manually. In case of problem, you have to gain access to the system, check disk integrity, verify date setup, check logs ... I dont think that you can find a solution out of the box with zero configuration and knowledge to handle special needs on headless/unattended/remote systems. The ultimate maintenance solution for a remote server is in all cases to have remote access to the serial console.

 

If your needs do not justify costly solutions, you must at least make backup of your data and perform tests of cold start, start after power failure (your system can enter an interactive restore session) ... My experience with an RPI is that I lost half of my files after a power failure : the culprit was the SD card and and mechanical contacts wich is not a good solution for high availabality in case of vibrations ! So you have also to think of the kind of harware you are using ...

I did attempt to fix it. The logs were of no use, as they ended the time my board got its power cut. As I said I tried restarting sshd manually, but it wouldn't even start, the task was just queued before the kernel crashed. After I pushed my seemingly not so big changes, the box wouldn't even give me a HDMI output, so I just considered the errors to be off bounds for my knowledge and proceeded to reinstall.

Having access to console is indeed good, I have a COM cable where I can probably access the serial console if necessary, but since I put my device inside a case for easy moving it's not that easy to attach the pins, but if it was truly necessary I guess I could plug it in and have the USB end on some other safe device like my router which boots using RAM.

 

As for the sdcard, I just ran fsck and said there were no errors, more I can't tell if it was corrupted, but I'd assume it was in some way due to the problems I'm having (and it potentially ran fsck itself as per defined in fstab? However, there's nothing in the logs about it. Since I had no logs at all could be it wasn't saved for some reason, and it repaired it before so I couldn't see any fs errors. But I believe the media has to be unmounted for it to be possible unless it does post-booting using tmpfs, excuse my lack in GNU/Linux knowledge it's a hobby after all). It could have been a smart move to get a x64/x86, but I am still sure a small device like this should be able to handle what I need without having to go for something bigger. There is also the fact that Intel is no longer planning to release new Atom-series CPUs which would make me have to go for a bigger CPU in the future.

 

Just keep it simple. You do not need an "expensive UPS" or large power bank to keep a simple tinkerboard ( no insult intended, tinkering IS engineering ) running.for a couple hours without any charger power.

 

A "power bank" is just batteries combined with charging/discharging circuitry. Charging/discharging are mutually exclusive unless you pay extra for "passthrough charging". Just use two regular power banks and hook them together on the battery side ( + to + / - to - ). You can now charge the double-pack power bank through one circuit and draw power from the other. Unplug charger and it still runs for a couple hours, replug and reload the batteries.

 

Viability of this approach depends largely on connected peripherals as current is limited by max.charging/discharging capability of the power bank circuitry. Powering disks ( peak >1A draw ) is not reconmmended, but OPI ONE/LITE with wifi and USB storage have been running fine for weeks with random plugging/unplugging of power supply. Presently I'm successfully using VERY cheap power banks and run them in parallel when needing more juice.

 

The fancy luxury version of this poor man's UPS would sense charging power via GPIO pin and use some program logic to gracefully shut down the board after extended power-out (some hours).

 

This sounds very interesting, I didn't think of that. But wouldn't you potentially be charging the battery cells inside to death if it continously draws power and charges it back up again? As you said it only has circuitry for charging/discharging, so as per my understanding it would not be able to directly passthrough the current- But it might be too little to make a difference. I did some tests and I believe some lithium cells on heavy use ended up degrading to 75% of it's original capacity during a period of one and a half year, so if the device does not draw that much energy it should be able to last for a while although it will get less and less hours after some time?

Link to comment
Share on other sites

But wouldn't you potentially be charging the battery cells inside to death if it continously draws power and charges it back up again? As you said it only has circuitry for charging/discharging, so as per my understanding it would not be able to directly passthrough the current- But it might be too little to make a difference. I did some tests and I believe some lithium cells on heavy use ended up degrading to 75% of it's original capacity during a period of one and a half year, so if the device does not draw that much energy it should be able to last for a while although it will get less and less hours after some time?

 

 

All batteries degenerate. "Passthrough" is somewhat misleading, "battery buffering" would be a better description of what really happens. Surprisingly enough, the method outlined actually works and that's all I care about. Good luck.

Link to comment
Share on other sites

I did attempt to fix it. The logs were of no use, as they ended the time my board got its power cut. As I said I tried restarting sshd manually, but it wouldn't even start, the task was just queued before the kernel crashed. After I pushed my seemingly not so big changes, the box wouldn't even give me a HDMI output, so I just considered the errors to be off bounds for my knowledge and proceeded to reinstall.

 

"The logs were of no use, as they ended the time my board got its power cut."

Not very much surprising.

 

"As I said I tried restarting sshd manually, but it wouldn't even start, the task was just queued before the kernel crashed."

I dont understand. In case of boot problem, you have or you dont have access to the system. The boot scripts can be stuck, and in that case you need to have boot options, interrupt (ctrl-C) enable or acces the boot media by inserting/connecting elsewhere or boot the system on other media. If you can try to restart sshd manually, that means you have access to the system and you could simply type : /usr/sbin/sshd and see what happens. If your kernel crash then you have a big problem and you may drop the SD card and reinstall.

 

"As for the sdcard, I just ran fsck and said there were no errors, more I can't tell if it was corrupted, but I'd assume it was in some way due to the problems I'm having (and it potentially ran fsck itself as per defined in fstab? However, there's nothing in the logs about it."

 

A full fs check and repair cannot be done on a read/write fs, and the system generally reboot after that (I dont know if some distributions try to backup tmpfs). So I think you cannot have logs unless you use a terminal emulator on the serial console (and record session). And when the fs is gravely damaged, you can lost half of your files and find them with numbers instead of names in a lost+found directory.

 

"There is also the fact that Intel is no longer planning to release new Atom-series CPUs which would make me have to go for a bigger CPU in the future."

Well I possess myself a ZOTAC/ATOM system. It is a good platform, the CPU can support passive cooling but you need a ventilation of the case. It needs much more poser that arm procs and I find the bios take to much time to check and init the system. There is no reason we could not get the same reliability with arm cards, but if you browse the forum, you will see a huge number of problems caused by bad or insufficient or bad power supply (or thin wires or bad contacts). When doing moderate usage of those systems on card, the most important power is claimed at boot time, when initializing USB or display or disks or network.

 

If you make boot tests, you should use serial console, test boot with and without unplugging, check the clock after boot, and test with or without network connectivity. In case of power failure your network connection can be restored after the system boot. If you restore your clock by NTP, it needs network and it can refuse to update clock (configuration option) if it returned to jan, 1 1970. (I had a lot of problems with that). And if you use a DHCP server provided by your still booting ISP box and hotplug/auto interfaces, a lot of services will be delayed or fail.

Link to comment
Share on other sites

If about "UPS" I was planning to make my own with control lines (reporting for "on battery", "on ac" status) and simple "c" daemon (similar to upsd) for powering off the device after defined period of time. Additionally for delay circuit for powering on after power was restored and some defined time elapsed (it total it would be quite complicated circuit).

 

Then I made my "UPS power bank" with tp4056 charger, 2 18650 cells (in parraler), step up with MT3608 module and switching circuit as mentioned here (with slight optimization): http://ficara.altervista.org/?p=2736

 

Then after tests it appered that my "UPS" can handle up to 7-8 hrs of keeping server up & running (of course not under heavy load), with average consumption of 0.4 A. IN such a case I resigned from controlling module and leave simple function.

 

Module is working under full charge (4.2v). I am aware that in normal condition it will decrease lifetime of cells, but it is no problem to replace it (eg. after 3 years) :).

Link to comment
Share on other sites

If something happens (physical damage, difference in chemistry) to one of the cells to change its internal resistance to different than the other, the TP4056 chip can end up overcharging one of the cells in the pair (since its reading information from the combination of the cells), and its not unknown for a lithium cell to react rather violently when this happens.

 

One TP4056 per cell if you want to play it safe. At the very least charge at no more than 1C of a single cell of the pair.

Link to comment
Share on other sites

If something happens (physical damage, difference in chemistry) to one of the cells to change its internal resistance to different than the other, the TP4056 chip can end up overcharging one of the cells in the pair (since its reading information from the combination of the cells), and its not unknown for a lithium cell to react rather violently when this happens.

 

One TP4056 per cell if you want to play it safe. At the very least charge at no more than 1C of a single cell of the pair.

AFAIK some 18650 cells have internal protection circuitry and some don't. While it's still not good to connect multiple cells in parallel for charging, at least "smart" ones would be a better choice in this scenario.

Link to comment
Share on other sites

If something happens (physical damage, difference in chemistry) to one of the cells to change its internal resistance to different than the other, the TP4056 chip can end up overcharging one of the cells in the pair (since its reading information from the combination of the cells), and its not unknown for a lithium cell to react rather violently when this happens.

 

One TP4056 per cell if you want to play it safe. At the very least charge at no more than 1C of a single cell of the pair.

 

1. I have written "in parallel". So, it is 1S2P (or 2P1S) configuration.

2. DW01 protection exists (one of function is overcharge protection).

3. Currently (again: in parallel) it is charging to 1A / 4500 mAh (2 x Sony US18650V3 2250mAh), so it is under 0.25C. Even, if because of some reason 1 cell wil stop consuming any current (infinite resistance), then the other will be charged below 0.5C.

Link to comment
Share on other sites

AFAIK some 18650 cells have internal protection circuitry and some don't. While it's still not good to connect multiple cells in parallel for charging, at least "smart" ones would be a better choice in this scenario.

 

Parallel for charging is not good? I guess in series in bad idea unless you are using designated 2S (or more "S") BMS.

Link to comment
Share on other sites

I am confused - in 1S configuration there is no way to balance anything... It must be at least 2S configuration. I wanted to clarify your statement that "charging in parallel is not good", because in my opinion you made a mistake (which I corrected by saying that probably you meant "in series"). But as I said my config is 1S I still got no argument that this is bad idea.

Link to comment
Share on other sites

I am confused - in 1S configuration there is no way to balance anything... It must be at least 2S configuration. I wanted to clarify your statement that "charging in parallel is not good", because in my opinion you made a mistake (which I corrected by saying that probably you meant "in series"). But as I said my config is 1S I still got no argument that this is bad idea.

Yes, I must correct myself - there is no real need and no good way to "balance" 1S configuration, but you still have to consider different characteristics of cells, so single channel charger will not operate in the recommended way for multiple cells - "charge termination" phase won't be triggered if one cell is fully charged and other is not. If this is a premade battery pack, cells would be identical and properly balanced to start with, compared to manually assembled packs.

 

References: [1], [2], [3].

Edited by zador.blood.stained
Link to comment
Share on other sites

Wow...way off on a tangent on that Li Ion battery thing...

http://batteryuniversity.com/learn/article/serial_and_parallel_battery_configurations

 

How is the partitioning scheme on armbian...the entire drive set up as ext4?

 

I believe on raspbian, they create a 100~mb partition of fat32 that keeps the boot kernel...if for some reason the power konks out and the ext4 partition is corrupted, the board can still boot from the fat32 partition, runs a script to scan the ext4 drive, then reboot

as it stands, if power dies on a normal armbian install, it corrupts the boot partition (the whole card) and it will no longer load..happened to me 3x times...each time I wiped the entire sd card...re-imaged from a linux machine with the dd command, and it boots again...but cut the power after system up and running...dead card

Link to comment
Share on other sites

How is the partitioning scheme on armbian...the entire drive set up as ext4?

Yes, this is default configuration for prebuilt images for Allwinner-based boards. It's possible to create manually and use another partition configuration, including separate fat32 /boot partition.

 

I believe on raspbian, they create a 100~mb partition of fat32 that keeps the boot kernel...if for some reason the power konks out and the ext4 partition is corrupted, the board can still boot from the fat32 partition, runs a script to scan the ext4 drive, then reboot

as it stands, if power dies on a normal armbian install, it corrupts the boot partition (the whole card) and it will no longer load..happened to me 3x times...each time I wiped the entire sd card...re-imaged from a linux machine with the dd command, and it boots again...but cut the power after system up and running...dead card

This is based on SoC bootloader limitation, it requires fat32 partition to load firmware (and kernel with default configuration, though I believe it's possible to load u-boot instead and use kernel on "main" ext4 partition.

 

Default Armbian settings are shifted towards performance, you can try using different mount options (i.e. "commit=5,sync") and disabling journal_data_writeback to improve reliability in case of power loss.

Link to comment
Share on other sites

improve reliability vs having a kernel on a smaller fat32 partition that isn't susceptible to corruption because it's used to boot then rarely written to, with a script to run the scanning tools in the case of a corruption. 

 

cool cool...but practically useless when the entire partition is corrupted...and it can't even get to the boot kernel

 

I have had a RPi B running for about 3 years now (put TOR relay and other smaller server functions on it)...power failures galore and all that...but it keeps rebooting...OPiPC running armbian...has failed about 3x times now when I have to reset power due to loosing remote capabilities after changing something with networking (attempting to run it headless as a printrun interface to my new 3D printer)

 

http://ideaheap.com/2013/07/stopping-sd-card-corruption-on-a-raspberry-pi/

 

I guess where I am aiming at is creating a RO boot partition, where the kernel is placed...so a tiny partition to boot is used...then the rest of the OS runs on the EXT4, if power is cut...it can at least boot...then scan and fix the corrupt drive, reboot and profit $ :)

 

not to poke the awesome developers at armbian...but the sunxi mimicks the raspbian way to compile the kernel...before I overwrote the SD card because I found armbian now supported the H3 chipset

https://linux-sunxi.org/H3_Manual_build_howto#Building_u-boot

 

You guys are the geniuses...I just saw the difference and noticed rasbian and sunxi seem to reboot...armbian...corrupts the SD card

Link to comment
Share on other sites

The 9$ computer C.H.I.P can be battery powered and have charge/discharge controls. You can use the C.H.I.P as a bypass power to the Orange Pi an can be used to send a power down when the battery is running out of power by the GPIO or by a Wi-Fi message.

Link to comment
Share on other sites

I had a copy of the orangepipc.org OrangePI-PC_Ubuntu_Vivid_Mate.img and installed it

 

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=342

 

Would like to run the script that fixes the overheat problem

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=785&fromuid=29411

 

Either way...keep up the awesome work guys!

Link to comment
Share on other sites

Would like to run the script that fixes the overheat problem

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=785&fromuid=29411

Either way...keep up the awesome work guys!

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/

Link to comment
Share on other sites

Just keep it simple. Instead of "optimizing for power cut" just do not cut power. This is done with battery buffering and has been proven to work with OPI ONE/LITE using stock Armbian as per stock Armbian documentations. All the circuitry needed is already included in a pair of the cheapest of power banks you can possibly buy. Add two quality 18650 batteries ( Samsung, Panasonic, Sanyo ... no UltracrapFirecrackers ), solder battery terminals ( +/+ -/- ) of power banks together and you are set. Will it drain the batteries faster than in theoretical lab conditions without any use cases ? You bet it will. Will it keep running when power is cut ? Sure !  Will it dampen quirks of PSU ? Yes - a great added benefit !  

Link to comment
Share on other sites

Simple is having a partition scheme with the read only "boot" locked, then when power cuts, the system 99% of the time recovers...

 

I do appreciate the suggestion of a backup power supply (it makes sense), but those too fail, and it seems just one blip of the power and the armbian build just doesn't survive...

 

Sent from my 9006W using Tapatalk

Link to comment
Share on other sites

it seems just one blip of the power and the armbian build just doesn't survive...

 

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 :)

Link to comment
Share on other sites

Yes, I can confirm that I (until now) never had a corrupted FS on armbian - whereas I faced a number with raspbian.

 

Dont forget one thing : in case of crash, a lot of cards dont do a full reset if anything with external power remain connected. And then what happens is unpredictable.

 

Dont forget also that if you badly flash the SD card, the boot fail, and the FS is damaged because it **never** was sane ! So always eject/reinsert the card and mount the partition before trying to boot ...

 

You can of course make a separate partition for /boot (quiet easy), but you should also mount /usr, /lib, /bin, /sbin, /etc readonly (needs some links in /etc) - and entirely custom your system for failsafe boot and forget about upgrades on debian based systems ... Eventually, you will find that you need a hardware (serial) console ! And it then makes power reset even more problematic.

 

As for battery protection ... my systems are useless or even inaccessible if there is no network. So I need a global solution (and my Internet box needs 12V/1A !).

 

For me, the more stupid and difficult to handle remain the reset problems and the mechanical contacts reliability of SD cards - and armbian cannot handle that.

Link to comment
Share on other sites

when power cuts, the system 99% of the time recovers... 

 

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.

Link to comment
Share on other sites

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 :)

Roger that, I will re-image armbian again w/ journaling and give it a go.

 

Worse comes to worse, I'll get one of those portable power modules with the 18650 in it, plug power into it, then feed the power out to the OPPC...just have to ensure the unit has separate charge and boost circuitry, or I'll just build me one from thingiverse http://www.thingiverse.com/thing:362179

 

 

Sent from my 9006W using Tapatalk

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines