Re: [beagleboard] long term BBB based art installation
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 dpickf...@gmail.com 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 mpin...@gmail.com 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 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
Re: [beagleboard] long term BBB based art installation
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 mpin...@gmail.com 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 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
Re: [beagleboard] long term BBB based art installation
Matt Pinner mpin...@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 pgplRSOSWILVB.pgp Description: PGP signature
Re: [beagleboard] long term BBB based art installation
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 javascript: 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.
Re: [beagleboard] long term BBB based art installation
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 On Mon, Jul 28, 2014 at 2:28 PM, Matt Pinner mpin...@gmail.com wrote: 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 -- 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. -- 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.
