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. On Sat, Aug 2, 2014 at 9:46 PM, Daniel Pickford <[email protected]> wrote: > 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.
