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 --matt On Tue, Jul 29, 2014 at 1:19 PM, Brandon I <brandon.ir...@gmail.com> wrote: > Don't forget, read only mount! Flash has limited writes and is can easily > be corrupted/damaged from power failure. > > On Tuesday, July 29, 2014 9:02:52 AM UTC-7, Ben Gamari wrote: > >> Matt Pinner <mpi...@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 >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
