tldr: can i run a BBB for three years?
I’m about to fly a BBB (w the latest debian) high into the rafters at a space in Denver.
It will control 1440 leds over SPI from pixel data sent over UDP via OPC.
This is all very exciting for me and things have been running fairly smoothly and the community support and blogs have been enormously helpful.
Now i’m kind of freaking out bc this thing should ideally run as stably as any light fixture and i’m not sure a good way to really test that kind of thing.
the sub one-minute boot up time seems acceptible enough, so the client can always reboot it, but then what does that do the filesystem?
i’ve started looking into logrotate to keep the disk cleared, but there is still the question how many read/write cycles will the eMMC accept before drama happens?
I plan to have a private network running so i should be able to login to the BBB for some kind of maintenance and troubleshooting. do i run a long (100ft) serial cable? and usb cable as well?
im tempted to put it online so i can check from afar, but i feel that invites all kinds of new room for disaster and abuse.
i realize these are more debian/sys-admin/collo questions than BBB specific, but i thought there might be some specific examples of people doing this type of thing or suggestions from this group for what to check and lookout for.
thanks for your consideration, questions, and suggestions!
-matt
USB and Serial are both more (cable) length limited than ethernet. If you have it on a private network I’d just use ssh.
Here’s the approach we use access over the Internet rather than on a private LAN:
- BBB periodically sends a message (json, https) to a web server, asking if the server has any commands for it (it does this anyway as part of our application)
- servers responds with ‘no command’ or a command message. One possible command message is ‘initiate ssh’
- the ‘initiate ssh’ message includes a temporarily generated user id, password, and port number
- BBB initiates a reverse ssh for that user on the server
- you connect to the server and ssh to the other end of the reverse ssh tunnel
- when done, BBB shuts down the tunnel, server removes the temporary user.
Nothing is fool proof, but with the user id being pretty ephemeral, risk is reduced.
Matt Pinner <mpinner@gmail.com> writes:
tldr: can i run a BBB for three years?
Sure!
I'm about to fly a BBB (w the latest debian) high into the rafters at a
space in Denver.
Awesome!
It will control 1440 leds over SPI from pixel data sent over UDP via OPC.
What is OPC? Presumably this isn't OLE for Process Control?
This is all very exciting for me and things have been running fairly
smoothly and the community support and blogs have been enormously helpful.
Now i'm kind of freaking out bc this thing should ideally run as stably as
any light fixture and i'm not sure a good way to really test that kind of
thing.
Indeed it's not easy to test for stability. I've found the BBB hardware
to be rock solid but YMMV. The obvious place to start would be just to
let the board sit running your code for as long as you can.
the sub one-minute boot up time seems acceptible enough, so the client can
always reboot it, but then what does that do the filesystem?
i've started looking into logrotate to keep the disk cleared, but there is
still the question how many read/write cycles will the eMMC accept before
drama happens?
If at all possible I would try to keep the root file system mounted as
read-only. It can be difficult to predict the rate of disk writes
(e.g. logging rate) on a running system and I wouldn't want to risk it
just for log files. This is especially true if you may have flaky power
(SD cards have been known to die when power is removed at the wrong
point in a write operation). My first instinct would be to play it safe
and put /var on a tmpfs.
I plan to have a private network running so i should be able to login to
the BBB for some kind of maintenance and troubleshooting. do i run a long
(100ft) serial cable? and usb cable as well?
It certainly wouldn't hurt to have something like this in place,
especially at first.
im tempted to put it online so i can check from afar, but i feel that
invites all kinds of new room for disaster and abuse.
If you firewall all but port 22 and configure sshd securely (either
a particularly strong password or exclusively key-based authentication)
I'd say the risk is pretty low.
Let us know how it goes and don't hesitate to ask more questions!
Cheers,
- Ben
Don’t forget, read only mount! Flash has limited writes and is can easily be corrupted/damaged from power failure.
have you considered environmental factors where it will be installed?
what extremes of temperature and humidity will it see? also make sure
you're running from onboard eMMC as doing so eliminates yet another
connector issue. basicly keep the board cool and dry and it ought run
for a good long time. also let us know where this is going so we can
come see your great art!
Eric
tldr: im using 2x beagle bone in a long term install and hope to enable anyone to update the configurations.
Thanks for all the great advice thus far. i’m starting to feel confident about a few things.
ok, im not sure im ready for the read-only mount.i like using the eMMC. are there advantages wrt stability. i aim to keep the debian as close to stock as possible. im considering upgrading to the 4gb bbb’s in an effort to avoid disk issues and get the stock os.
i quite like being able to mount the beagle eMMc /boot/uboot as a removeable drive on my mac. exposing this usb drive can potentially enable a complete noob to update configurations. i put im having all scripts source /boot/uboot/env.sh by default to enable some global values. when i move and edit files on /boot/uboot/ when mounted as a drive on my mac, occasionally, the file will become unexecutable as bash script and become interrupted as binary? know what causing that?
i’ve roughly put my latest configuration in https://github.com/mpinner/Active
Matty,
Sounds like a fun project! My issues with the BBBs historically have all been power related and SD card related. I can’t say I’ve ran one for longer that a few months without rebuilding it, but it’s the first few months that generally present the hardware problems.
In regards to a long term BBB install, the duty cycle on the SD card is of significant concern (if you have a high quality power supply). I’m seeing uSD cards start to fail with <10K’s of block rewrites on “professional” grade microsd’s right now. There are MLC/SLC industrial cards out there, but they are pretty expensive. The idea of throwing any logs or writes onto a ramdisk is solid. I don’t have experience with the long term reliability of the onboard eMMC (in general I find the r/w speeds a little slow and I like keeping a default bootable image around in case sd card starts dying (see previous paragraph…)) but if you can get rid of every last block rewrite regardless of what flash storage type, it’ll be worth it.
If you concerned about boot times, check out systemd, super easy to get working on the current debian stable. I spend more time waiting for USB peripherals to boot up than the OS services nowadays. https://wiki.debian.org/systemd. You just have to pass the systemd kernel parameter in uEnv.txt. If it’s autobootable by OSX you are likely running fat32 on the /boot volume. It’s not that robust of a filesystem, and is a little long in the tooth. You might want to switch to ext2+. Because of the aforementioned flash duty cycle issues, I try to leave the boot volume alone and effectively read only.
The file being interpreted as a binary is a nasty one - it actually sounds like the file could be getting corrupted. I’d use the file command on the scripts you are having problems with, it basically checks to see if you have any non-null bytes. How do you fix it? Delete the file and copy a new one?
You can do read only with stock debian using this approach: http://ecloud.org/index.php?title=Debian_on_read-only_media
This is very important for long term installs with flash media. If you do need to write, use a usb flash disk that the customer can get to and replace when needed, because it will eventually fail.
Matt,
I can not talk for BBB as I never tested that long.
I have a geothermal monitoring system running on a mini2440 for about 4 years now.
It collects data from a PIC, format it, displays it using Qt program, saves it on flash drive and every night send the data of the day via email.
The only failure was the SDCard mounted R/W.
So now the system is mounted RO, logs are circulars on ram tmpfs and data is stored on usb stick.
I can reach the system anytime, well if internet is not gone there, it’s about 3000kms from here.
The systems connects to my local server using VPN. You’d need a static IP or a dynamic dns if you want to use that way.
Thats the only way I had, because they do not want to open ports ( nor did know how to do ) where the system is installed.
I must say that the system is stable, runing a bit hot sometimes because of improper venting, but show goes on 
That said, if you boot on sdcard, be sure to buy a really good one. Industrial rated if possible. I saw the difference on many embedded systems I built. Industrial grade is not just a word on the product.
Regards,
Cedric.