Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've been doing embedded Linux based systems for quite some time now.
I'm using Buildroot as opposed to Slackware. The point here is that Slackware would be overkill. With Buildroot I can get fully usable system that, depending on the target goal, can be between 4 to 40MB in size, kernel included. The size matters when it comes to installation time and very often the devices do not have enough flash storage for a full blown system. In addition, systems generated with Buildroot will keep most of the frequently changing files in the tmpfs, which prevents killing the NAND flash too quickly. And last, but not least, Buildroot gives me the fine-grained control over what goes into the final filesystem. As you can see, I have no big experience with Slackware ARM.
And now my question:
I think many of you is using SD/MMC and doing full Slackware installation on such a medium. I would like to ask you, what is the reliability of such setups? I mean, does it behave well running for extended period of times or do you experience some hiccups related to SD/MMC not being reliable and erroneous?
I'm personally really scared of SD/MMC and I try to avoid it as much as possible. The point is that, I have experienced some erroneous behaviors. It wasn't frequent, but still. What I observed was read errors, write errors and system hangups. The hangup happened to me recently on RPi B+, even though the system was running from ramfs. I credit this to the SD/MMC driver for RPi having some errors.
I would phrase it in the following way: give me your board running from SD/MMC and after shorter or longer time I'll hang it and it will hang due to the SD/MMC error
I don't remember where I read it, but somebody said that even the most expensive SD/MMC won't give much more reliability over a cheaper card. They are simply not reliable.
I have an RPI B that has been up one year six days 24X7 today in my garden shed with the exception of a couple power outages. It's connected to a DIY weather station circuit. Data from circuit plus data parsed from BOM webpage at nearby airport is stored in a round robin database and a csv file. Halfway through this period I also started parsing and collecting data for forex and spot prices. All this is served up on a web page available on our lan via wireless. Webpage contents include pre-formatted text that along with data and graphs (as images) is updated every 15 minutes. Much of the info is presented in fancybox popups. There is also a webcam providing video feed of back garden on demand.
I was concerned about the rewrites and power outages but so far the only problem I have had was from birds. Blackbirds nested in the shed near my setup and and while the parents didn't bother anything the fledgings must've been attracted by the LEDs and pecked at the circuit board before leaving home for good damaging my humidity sensor:<(
I don't know how long it would take me to put all that together with Buildroot but everything with the exception of four slackbuilds came with a Slackwarearm install less the gui stuff.
What reason would there be for me to lie. I don't have shares in Kingston or Sandisk. I have also had a cards go bad but I would put that down to my abuse. The setup I described is a prototype that, as I said, has been running headless for over a year year with access via ssh. I intend to build something more permanent (and bird proof) with a bananapipro and 2.5" hdd. That will go into a stevenson screen on a post instead of a shelf behind a window in a garden shed. I just haven't, had time.
I have absolutely no idea.
I saw it myself a bunch of times, that's why I stick with the expensive extreme pro. I think extreme are also ok, but I didn't test any since 2012.
Since the release of the Samsung EVO microSD cards I have used them, almost exclusively, on the rpi and rpi2. These cards have proven to be 100% stable and reliable, more so than any other SD or microSD card I have used on these devices. I believe the Samsung EVO microSD cards to be superior and that's why I use them and would recommend them to anyone and everyone. In all the time I have used these cards they have not given me one single problem.
I have approx. 5 rpi and rpi2 devices active at the moment, using Samsung EVO microSD cards in 4 of them. I use them for; running and testing (mainly Slackware ARM) Linux operating systems, KODI, SlackBuilding lots of packages, doing lots and lots of BASH scripting, running a web server, running a ntp server, and lately I've been doing a bit of Python development to interact with some website projects.
I cannot recall how many installations of Slackware ARM I have performed on the Samsung EVO microSD cards, but it will literally be 100s. Or the countless hours/days/weeks/months I have spent working with them.
If you are wanting the best microSD card then, in my experience, I cannot recommend the Samsung EVO highly enough.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.