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? On Aug 2, 2014, at 9:01 PM, Matt Pinner <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
