Considerations for a long-running Raspberry Pi
dzombak.com
dzombak.com
And you can get them dirt cheap nowadays, has proper casing and cooling etc https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
I have one right next to me, i5-8500T, 32GB RAM, 2x SSDs and currently 5W at idle with powertop auto-tune https://wiki.archlinux.org/title/powertop
Good you could add a serial comnection to a microcontroller etc, but then the solution won't be as elegant.
- if you ask whether the way of using GPIOs on a Raspi is elegant, I would say, yeah quite. Python and gpiozero are a good elegant way to go that route
- if you ask whether it is elegant to use GPIO on a Raspi in principle, I can't answer your question because that depends on what you use it for. There are extremely elegant ways and there are ugly hacks that shouldn't exist.
That being said if you quickly need analog input you can just add an ADC to the gpio and you have it. That is more elegant than having to add an usb peripheral.
There are thousands of them coming off lease for sale here in Australia.
8500T or 8700T chips are fantastic. They can officially run Windows 11 and have have hardware transcoding built In, so are great for a Plex server!
I’ve upgraded one of mine with 2x 2GB SSD and 64GB RAM.
Never any issues and it runs 247.
Where would I find one and what do they go for?
As a Plex server, do you know if they can handle hardware transcoding?
Thanks!
And in all these years, I had maybe one microSD going read-only on me. Cloned that to a fresh one, did an fsck and the Pi was up and running again. That’s it. No other issues despite various sudden power losses etc.
I don’t understand where these rumours about bad reliability of SD cards in Pis come from.
I've always used noatime for filesystem, journald set to ram logging, etc. Usually everything seems fine until a reboot triggers a fsck. Most were ext 3/4 filesystems.
You're always dependent on someone building a bespoke Linux image for your particular device into perpetuity, which rarely happens.
Most of those boards can run mainline Linux, but certain features and integrations only exist in external forks that weren't put into vanilla Linux.
The end result is either that you're still dependent on someone maintaining bespoke Linux kernel forks in perpetuity, or you ship relatively up-to-date kernels that lack features, drivers, etc that only exist in the forks.
Also of note, it's x86, which has me interested as a field-portable ham radio computer. Most software runs on rpi (my current setup), but x86 is universally supported by stuff. Just need to figure out the monitor situation.... maybe vnc from an ipad? :)
There are plenty of decent portable monitors out there. I ended up with an MSI one, but I think any laptop brand can make a monitor (I also had some no-name one which had a nicer resolution but ended up breaking pretty quickly).
Anyway, I eventually concluded that I was wasting time re-inventing the laptop. It was nice to be able to put the unnecessary extra stuff, like the monitor and battery away, when using it in desktop mode (saving desk space). And the ability to pick a proper keyboard is nice.
But buying part-by-part has some downsides. You pay extra because this is all niche stuff, it doesn’t slip as nicely into a backpack (otoh if I only needed to bring the NUC somewhere, it could fit in my cargo shorts or bike under-saddle bag which was neat). And random integration things—you need to bring all the right cables, the battery probably doesn’t talk to your OS so you have to check it manually.
I also did SSH and VNC from an iPad, it works fine, you’ll probably want a keyboard and end up with something like a laptop, but extra latency and your SSH/VNC client will waste some pixels. I also did SSH and VNC from my iPhone, got a little stand and everything. That combo actually got interested questions in a coffee shop, so nerdy niche computing mission accomplished, haha!
So, I hate to ask the boring question because it was a really fun project and I got years of use out of it, but: Why not a laptop?
My current setup is VNC from ipad to the rpi for ham radio stuff. It works well enough, with the ipad being keyboard & screen in a small space. And lets me take an ipad with me for other uses. But the rpi4 is so darn slow at a full desktop experience, especially when then feeding it over a network connection.
The CPU is enough for my needs, currently running Proxmox with OPNsense. And x86 was a major draw for me over the RPi.
Most, incl. the Lenovo above, seem to support at best 1x M.2 + 1x SATA.
The best choice I have found is using a N100DC-ITX mainboard with a generic ITX case, and those are huge.
I am looking to replace my Raspi / USB SSDs combination.
One option would be to use a riser and a PCI card that supports multiple M2 drives
The number of posts on this site that people want to turn into “show & tell” is very high.
Just make a Show HN post about whatever you want to show off and let the voters decide the fate of the post.
Would love to make a small all-flash NAS, but the only one I know about does not have it: https://www.asustor.com/en/product?p_id=80
$650 QNAP TS435XeU 1U NAS supports 4GB-32GB ECC SODIMM, 4xSATA, 2xNVME, based on Marvell/Armada CN9130 Arm SoC. Debian for Arm64 can be installed via serial console.
Some 4x4 Ryzen Embedded V1000 mini PCs support ECC SODIMM, e.g. https://www.sapphiretech.com/en/commercial/fs-fp5#Specificat..., possibly ASRock.
You can go to 96 GB.
With displays: https://www.solid-run.com/industrial-computers/bedrock-r7000...
There are ways to make Pi's more reliable, but it usually requires a lot of extra parts.
The ARM SoC do not have an IME though... ;)
RPi 4 boots from GPU/VPU running closed firmware (incl. Microsoft ThreadX RTOS), which retains full control over the OS application processor, https://www.fsf.org/resources/hw/single-board-computers
Boards based on the Broadcom VideoCore 4 family, such as the Raspberry Pi, require non-free software to startup, although signature checks are not enforced. A free proof-of-concept replacement firmware has been developed, but it is not in a usable state, and development has halted.
By default, the GPU requires a blob running in this same startup firmware. However, Broadcom also supplies an "experimental" free software stack, which could run without blobs, if the startup firmware were free.The RISCV also offers something unique over Pi ARM chips, but little economic incentive to stop the shenanigans. ;)
> a lot of corners were cut to save time leading to what I believe is poor ARMv7+ Cortex IP integration (GIC, TrustZone, etc). So I stopped working on it. If those things were not the case (GIC working, "TZPCs" working, security working as intended, instead of NS forced to high on bridge, at least in my understanding) I would still work on it ...
ARM isn't a second class citizen on this platform, it's a third class citizen since BCM2709 (again this is an opinion) ... the features I wanted to tinker with the most are absent by design (cutting corners) and I'm not willing to resort to SW emulation of them through clever uses of the VPU.
Hopefully RPi 5 silicon offers a better foundation for open firmware.
I'd be cool to do a comparison new Lenovo mini vs used M1 Mac mini - should be the same price.
As well as my intel apps. Was pretty smooth and the speed and power efficiency gains are obvious. My mac book air draws about 5w total while the DAW is cool as a cucumber.
2x DDR4 SO-DIMM RAM (notebook) slots. No ECC though (at least on this model)
And you can have 2 storage drives. One 2.5" and one M2.NVME
Can even add HDMI, serial ports etc.
First advice must be to mount FS in read only mode, mount /var in memory and forward al logs to one nide, which may be not RPi but something with proper UPS and nut running. Power loss becomes absolutely bening if your FSes RO or temporary.
It is overkill if you have one RPi but author claims that he uses multiple RPis all around a house.
Also, good idea to have A/B system partitions and upgrade system with full partition rewrite and changing active one. Thus way your system will have one good system partition in any case, even if new version has fatal bugs, and recovery become trivial.
I'm using several small/single board PCs im different roles in such way for 20+ years with great success.
https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
Be careful to check inside your docker containers also. It can end up different.
Here is a good article btw, with someone advocating for moving to tmpfs https://ubuntu.com/blog/data-driven-analysis-tmp-on-tmpfs
In fact, I didn't notice the change until now.
Copying through /tmp is a frequently used method for transferring files between users on a multi-user computer.
It is said that the Linux kernel will include soon an improved version of tmpfs, which will allow user extended attributes, within certain limitations.
When this will happen, one of the most annoying misfeatures of tmpfs that has persisted for much too many years will finally be gone away.
Logs to log server, if system needs non-volatile writable storage — NFS or second storage device, depending on requirements.
Of course, it is too much hassle for single such system (but I started to use it from very beginning out of curiosity) but uf you have many single-task small devices it is very convenient.
What’s your upgrade process like? How do you make the new disk image? Do you log into each device to upgrade it, or do you have automation?
I'm using FreeBSD, and here is script for preparing such installations named NanoBSD. To be honest, it is nothing special — build system with provided config (to strip it down, for example full FreeBSD installation includes toolchain and it is waste of space on «embedded» systems), mount file as loop device, create FS, install system to this FS by standard system means, add needed packages.
I'm building system once, make several images (as each device needs its own set of packages, of course), login to each device via ssh and run simple sh script which detects current active partition (by simply looking at output of mount command — from whic root is mounted) and then «dd if=/net/images/$hostname.img of=/dev/da0p$otherpart bs=128k», set this updated partition as «bootonce» in bootmanager and reboots. Last startup script in boot sequence check availability of network and liveleness of sshd, and if these simple checks are Ok, set this partition as alwaysboot (it is all UEFI features, mostly). If something goes wrong — one power cycle and device will boot from previous partition.
I don't have enough devices to automate «login and call script» part :-)
How then do you update the system or install new software?
sudo mount -o remount,rw .....Of course, devices don't build their own systems.
Are there any solutions available for this?
Incidentally, that early commercial product was a home security product with a very small amount of home automation. I released this into open source with a new name in 2021 and now runs on the Jetson series SBCs (https://github.com/hcfman/sbts-install). Except then including high end YOLO models as triggers.
Because it was intended to be a standalone product it supported https with a GUI wrapper around all of the certificate operations. This still exists in my open source version, making it easy to use self signed certificates for intra-device rest calls.
But I've kept and expanded upon the multi-partition memory overlayFS approach and the installation of this system first asks you to install the sbts-base system, which installs the multi-partition memory overlayFS so that other's can use this as their own base systems.
It's worth looking into for the cost savings on initial purchase and ongoing power draw.
The projects that I've been able to accomplish on a microcontroller have been more reliable (over decades) than my Pi-based projects, and I don't have to worry as much about them being part of some botnet because I forgot to change the default ssh configuration (wasn't it `pi:raspberry`?).
Beyond micropython, the no_std rust support for ESP32C3 is getting better every month. For people doing little home automation projects because they are fun, the additional constraints can make things a lot of fun and very rewarding.
But yes, for those that are already handy with Linux, a Pi is generally going to be much easier, though IME will be at least 10x as expensive, and the additional setup to get it in the same ballpark for reliability (SSD booting vs network booting vs ro-rootfs, watchdog setup, etc) and the increased power usage (esp for a Pi5) should at least be small part of the decision making.
Can I run my password manager server on an ESP32? No
PiHole? No. Unifi controller? No
I think people making this comment are envisioning people use Pis as garage door controllers etc., but reflexively suggesting ESP32s as Pi replacements isn't helpful.
They only asked that people consider it; no need to get snooty because it doesn't work for you, despite being very obviously inappropriate for your use case
>I use Raspberry Pis around my home as everything from low-power FM transmitters to UPS energy monitors.
Why yes a ESP32 can do that, and you get to play with a another cheap stack.
How about Blinking leds or a Display, or led strip... WLED and artwix have you covered!
A project like ESPresense is evolved from a PIzero project.
Let's not forget that some of the pi's appeal is that it has those GPIO headers!
You can run a web server though. Now I’m curious if I can push enough data to stream audio. I know the chip can handle 48k stereo samples, presumably I could stream that much over wifi. I may have to play with that this week. The bigger problem is attaching storage, many ESP32 SoCs don’t have USB peripherals, and many SDcard implementations can’t do much better than Audio throughput (SD has some insane lisencing costs for small dev shops), so I’m not sure the best solution for large amounts of data.
No, honestly I am impressed at the performance with which my RaspPi 4 is running a PhotoPrism instance with about 120.000 photos. This might also be thanks to the application software, but still quite a feat.
Can I run my password manager server on an RPI? No -- do you want to loose all your data because the SD card failed?
PiHole? Unifi controller? Maybe
I bet me writing this comment used more while keeping my laptop alive.
I love ESP32s, built a long running device for my car, where the power draw is important because I don't want to deplete car battery. It uses almost no power. However if it was running connected to a power grid, I'd not care about the electricity cost.
Or if I'm using something like Circuit python I'll just connect the web console.
Absolutely love it and to my surprise it's super stable. Something about WiFi power states often messed up my projects in the long run, but no issue with micro python architecture so far.
Admittedly, reverse engineering a single digit 7-segment LED display wasn’t the best use of my time, but by crikey it was fun.
The other ones have touchscreens and speaker attached, I use them to listen to internet radio, watch cartoons and control relays.
Your cheaper solution doesn't allow for any of this to happen.
It's not a hack, it's best practice! Just like important servers in a data center should have some kind of out of band connectivity (IPMI, remote controllable RPDU outlets, etc), Important servers in remote difficult to reach locations should have some kind of watchdog script. The script should of course be tuned to the specific use case, considering the impact of a reboot vs downtime until reboot. At the very least it could log adverse events for later investigation.
A simple bash watchdog script was the very first thing I did when I deployed a remote RPI. Not just for wi-fi issues but for any of the dozens of things that could break and be fixed with a reboot.
If init can't be relied on to manage services, what guarantees do you have for the system to provide them?
Sure, one could reinvent this in scripts, but we've moved past this. I mention systemd a lot, but that's not to cast favor - there are alternatives.
Most services don't make appropriate use of the environment they exist in. I assume they expect some site customization, ie: declaring your web server needs these mounts.
A commonly overlooked directive is 'PartOf='. You can tie restarts of one service/resource to another.
Heck, more simply, I think NetworkManager offers a way to customize the wifi/portal checking. You may not have to go completely heavy-handed
For the router, it just tries to connect to the appropriate SSID, and then tries to ping the router, and if either of those fails, it swaps to the other router. I have two identical routers with identical configs, with their power connected to the NO and NC contacts of an SPDT relay. If one fails, it just toggles the relay state to switch to the other.
If the router is up, the watchdog tries to load the cable modem's status page, and tries to ping any of three different IPs I've identified within my ISP's network which seem to be either the CMTS or closely associated hardware, and should indicate aliveness of the HFC plant -- I don't want to bother rebooting if the failure isn't something that a reboot could solve. Sadly I haven't figured out how to have two cable modems with the same MAC such that I could swap between them too, and the ISP won't let me have two modems on the same account, so my only resort if the CM fails is to reboot it and hope for the best.
This, plus a rack of batteries that'll keep the router and modem running for 30-plus hours in a utility outage, has kept me online nearly-continuously since May of 2020 when I built it. The code is an absolute horror-show (I'm much better with a soldering iron than an arduino), but in practice it's been rock solid.
Edit: raspberry pi’s have built-in hardware watchdog timers I believe. I know Arduino's do!
We’re still pretty happy with the Pi and the move to more open source APIs (Mesa/DRM/KMS/FFmpeg) is, now that they are finally in a state they feel usable, really promising. As our main use case is still digital signage, the raw processes power isn’t really that relevant as the expensive part (video decoding) is obviously accelerated and the backwards compatibility that’s possible with the Pi is awesome. We still have customers running Pi1B+ devices continuously for almost 10 years with the latest OS release we provide.
The Pi is fine for videos/images (less proper storage), but chokes on a lot of modern web assets.
Agreed on the web stuff. But I’d say the web sucks, not the Pi. :-)
You’re right that physical access is game over for content in general. This is more about extracting sensitive data (like credentials/tokens to 3rd party sites).
All backend communication is done using mTLS, where the private key never leaves the TPM (on x86).
Moreover, we’re encrypting all sensitive data we send to the device using the corresponding public key. Thus even if you rip the drive out of the device, you won’t have much luck.
And you need to look at longevity, there I suspect ARM will outlive X86 too.
For modularity ARM > X86 too, because they are cheaper to have many small of.
But for scalability (= business in the current economy) X86 > ARM.
Also all graphs should be per watt, that 2 -> 4 is more performant is not news, that it is more performant per watt is!
And if you did that you would see that Raspberry 5 is not getting as much per watt performance increase as it should.
We have peaked permanently for the eternity of mankind.
Let that sink in.
Last but not least, the ONLY hope for any progress (openness not performance) at this point is the JH7110, but they are lagging behind in 3D support.
Don't take this for a given. RPis are notoriously bad at idle power consumption. The x86 replacement I bought for my home server ended up having about half the idle power consumption of the RPi it was replacing.
https://docs.google.com/spreadsheets/u/1/d/1LHvT2fRp7I6Hf18L...
I feel like Raspberry pi has one leg up regarding gpio.
I have never tried to do gpio from windows (E.g. belink)
I am sure it is possible with usb adapters, but then you are dealing with changing come ports etc
Agree, I've also been running a number of PIs and when they broke, it was because of failing SD cards.
I found pibenchmark to be a good source of info --> https://pibenchmarks.com/
Definitely compare SD cards before buying.
> I guess it all boils down to good SD cards and stable power supplies.
I don't run a completely storage oblivious setup, I use f2fs, which has much better write patterns than ext4, and I disable stats collection in postgresql, which causes constant churn, but logging, and other stuff has negligible effects and I don't care doing anything special about it, and I leave it default OS configuration.
I have probably 4-5 uSD card failures over 60 year total runtime of my 15 SBCs that I run 24/7. So that's 1 failure per 12 years. Nothing that can't be dealt with using backups. (I didn't even need them that much, yet, because all uSD cards so far failed by turning read only, which for f2fs means you'll get the last consistent snapshot on the card, that you can just copy to a new card and continue. 10-15 minutes of recovery time.
All that complexity and limitations that people talk about seem way overkill for a home setup.
And I think other reason why I don't get many uSD card failures is because I run most cards in HS25 mode. Not in SDR104 or whatnot. 3-4x the frequency really causes the cards to heat up a LOT during activity. Can't be great for the flash chips. 2 of those failures were in SDR104 enabled hosts. Copying data to uSD card using SDR104 capable USB3.0 adapter really makes the card scarry hot in just a few seconds.
While I definitely agree that for a home setup it is overkill, in my dayjob I work on industrial embedded gadgets, sold 10-100k pcs/design, expected to run without reboot for years, sometimes for decades. And most of the weird issues end up usually on my desk for investigation. While I admit that this might not have been completely obvious, but when I referred to the sample size, I was referring to such numbers, taken from this experience.
I’ve switched to SSDs for most of them now. It’s too much of a dice roll otherwise
In ~2022 I started to get random errors, then found out the SD card was failing. I never took the time to fix it, it had lots of little things locally I don’t feel like doing again.
It’s just so tempting to quickly ssh into the machine to hack something around, then you forget about it b cause it ~works.
But a rpi4 can run containers, so that may also be an alternative.
Only reason why it fails is when the electricity goes out. A battery that could keep it running for 10 minutes would completely be enough.
I'd like to learn some tips on how to do that... do you mean something like https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode ?
Still upgraded to an SSD later because I wanted even more storage space (and SSD seemed to have better random IOPS than a thumb-drive), but I'd say go for it.
They both have SanDisk 2 GB cards in them. I vaguely remember naively thinking along the lines of "less space => less bit density => better reliability".
It mounts a ramdisk on /var and only occasionally copies the logs from ramdisk to SD card. That way I can still see all the logging without hammering the SD card quite some badly.
I basically mounted all logging and webpages on tmpfs, and the DB resides on the SD card being written to every 5 minutes.
Just understand that anything that is written to tmpfs will be lost if you have a reboot. It might make troubleshooting difficult if you need to preserve them for whatever reason.
It has seen many installs over the years but it's now a backup DNS server. Looking at the filesystem this one has been a PiHole since 2018, it has essentially ran 24/7 bar some reboots and me moving between places.
I don't write anything to the SD, it all goes to RAM at /dev/shm and the PiHole will simply have to redownload the lists the few times it goes down. It would download them anyway daily.
Exact same kodi-setup and sandisk cards, and has been happily running for years without problems. Disable all logs, media on smb/nfs, and off you go.
I just boot NetBSD kernel with embedded filesystem, e.g., INSTALL kernel or custom kernel. SDCard can be removed immediately after boot. Optionally chroot to attached storage. This runs for weeks, months or years. Have not experienced any of the issues cited by the blog author. Only issue I find is with the power connector when using a case; the connection can be brittle, e.g., if using a replacement cable. Perhaps this has improved on more recent Pis. (But I could say the same about most computers. The cables and connectors are usually fragile. It's always cheap stuff.) If power is interrupted because of movement, then the Pi reboots automatically.
a) Cable ethernet
b) SSD (via USB3.0 adapter on my RPI4)
c) Ubuntu Server LTS 22.04.
d) cheap UPS.
The Zeroes run Raspbian configured with the read-only filesystem option. I have found it necessary to uninstall `unattended-upgrades` because the overlayfs employed for read-only root caches disk writes in RAM and the update/upgrade process exhausts RAM. For the same reason I disable swap. It makes no sense to swap to RAM on a 512GB system.
Upgrades are tedious since they require disabling overlayfs, rebooting, upgrading, rebooting, and enabling overlayfs. I wrote Ansible playbooks to perform these tasks. (https://github.com/HankB/Ansible/tree/main/Pi)
I have a Pi 4B performing as a file server and running Debian (not Raspbian) It boots from an SD card so that the entire HDDs can be used for a ZFS pool. To reduce wear and tear on the SD card I have mounted `/var` to a ZFS filesystem. I should probably use `tmpfs` for `/tmp`.
I use a Pi CM4 to run HomeAssistant and that boots and runs from an NVME SSD where durability is less an issue.
As a minimal first step, install an NFS server (which can be X86, Pi, other) on your LAN and make sure you can mount it from the pi ("mount $SERVER:/some/dir /mnt/tmp"). Then copy the contents of a Pi SD card to the server, make it exportable (see '/etc/exports') then edit '/etc/fstab' on the Pi to mount the (now remote) copy of the SD card instead of the usual root. That should get you started - beyond that, with some of the Pi's you don't even need to have an SD card installed (however you'll then need to set up things like DHCP and TFTP on your server).
There's also a tutorial at https://www.raspberrypi.com/documentation/computers/remote-a...
They state the endurance on thousands of hours of FHD video, but what assumptions do they make in bitrate etc?
Can‘t they state total TB written or drive writes per day or something sensible?
Specifying endurance in "thousands of hours of FHD video" implies large sequential writes, or in other words the best-case for write amplification.
I used one of these Micron cards in my RPi4, it has high write endurance and also an A2 performance rating so it can support the IOPS needs of a boot drive. https://www.mouser.com/new/micron-technology/micron-i400-mic...
But I also think that gokrazy's simplicity and design helps it be just a solid, reliable foundation to build on top of.
[0]: https://gokrazy.org/
I've been running an RPi3 on dietpi on an SD card as my secondary PiHole instance on it for at least a year with no issues.
I got there from having SD cards (nearly[2]) always be the failure point. Everything else has been pretty reliable when used within tolerances.
[1] It does "boot" from the SD card but that acts kind of like a third stage bootloader which loads and boots the "real" OS (FreeBSD) from the NAS device.
[2] I have had one fairly spectacular looking "melt down" of a no-name USB power supply wallwart PSU which, to appears to have also put something like 12V directly across the USB power pins (my best guess at what the secondary winding of the xformer in the wall wart was putting out on the 'low' side)
Also, creating a readonly root out of an existing disto is a bit of a pain, my preference is to use a distro (like TinyCore) that's already a readonly root.
People don't understand that 90% of the SD card problems are power related (only relevant if you don't use the official power supply) and 10% are simply because of poor SD card quality.
People haven't gotten the message that a charger has lower QC standards since an interruption of the charging process does not shut the device down. A bug that leads to a few milliseconds of power loss will pass QC, but also corrupt your SD card.
Problem could have been solved by adding a decent sized capacitor on the 5v supply rail.
I think if you take into account how often they're powered on you'd find cameras destroy flash memory cards comparably to Raspberry Pis.
> Problem could have been solved by adding a decent sized capacitor on the 5v supply rail.
Or you could just buy the Raspberry Pi branded power supply.
Similar power consumption but power and case/cooling/storage is included.
Depending on what you choose you get eMMC or SATA or M.2 SATA or M.2 NVMe for storage.
For anyone that is interested: https://www.parkytowers.me.uk/thin/
Buildroot was surprisingly easy to use. Use a menuconfig to pick what you need and a burnable image for your SD card comes out the other side. Think I only spent an hour on the whole project.
I think the tinkerboards are better than Pi’s especially the ones that come with 16gb of onboard flash storage. However you don’t get all the niceness of PiOS but have to use TinkerOS (which was less than barebones when it came out) or Armbian which is nice but not built specifically for the tinkerboard.
I have a few friends who complained about Pi’s corrupting SD cards and it also happened to my only long running Pi so there is something going on.
Other than that, I've been running 3 rpi at home for home automation they have been working with no issue. But it turns out that they are a bit underpowered to be used as a minetest server.
I never had a corrupted sd card on those. But I had an android nokia phone that corrupted like 3 sd cards before i gave up and stopped putting new ones.
https://github.com/hcfman/sbts-aru
https://hackaday.com/2023/12/30/localizing-fireworks-launche...
With one command it for all Pi’s for both Raspbian and bookworm it:
* Shrinks the file system (Gee, how does it do that with just one disk ? ;-) )
* Creates new partitions
* Installs a memory overlayFS
* Installs and configures the system as an audio recorder with micro second time accuracy
* updates /etc/rc to do a forced repair of the data and config portions, in case they were damaged. This avoids system hangs waiting for human interaction with fsck
For the partitioning scheme it creates a swap partition, not as a wow but as an enabler if you really need it to install some large software.
It creates a small config partition. The idea here is that you keep it read only and remount it read write if you need to change config then remount it read only again.
And finally a data partition, which in this projects case is where the audio files are written.
I maintain a version of an overlayFS boot for the Pi but it needs revisiting for bookworm. The easiest way to use do this is to install the sbts-aru and then just don’t use it. Then everything is done for you in one command. And that version works for all Pi’s.
I also do this for the Jetson SBCs. But I need to revisit this for the Orin series. I have it working here for myself and friends but need to update the installer. Note, due to kernel behavior changes with Orin the older Pi like overlayFS code will not work. But I solved this and will release it when I release the Orin release of sbts-install soon.
I’ve been using memory overlayFS like installs for years for long running Pi systems.
While one could argue that you should figure out the source of your device freezing in the first place;
Nothing is better than having to ask someone to power cycle your Raspberry Pi while you're away.
And use a wired network connection for anything important!
I used to build my machines and loved it. Some are still chugging along after over 10 years. They were worthwhile before the mini PCs reaching comparable capabilities at lower cost.
One thing I still cannot seem to find is a good site that compares various vendors in similar fashion as "PC builder" sites do of build components.
Any suggestions?
A few weeks back the first SD card to fail got so corrupted it failed to reboot!
My key learning is use oversized cards, because then the bitcycling will wear slower!
I'm going from 32GB to 256/512/1024!
That said "High Endurance" cards are a scam, they fail way quicker than regular cards!
All SD cards except SanDisk have latency problems. There is no competition.
If you can get SLC SD cards use them for workload instances = no db or file storage.
I'm guessing it's SLC/MLC.
Had a Transcend 32GB in 2016 die after a year.
The biggest issues with set-and-forget setups is software upgrade for security or other reasons, jumping major versions ends up breaking things. Compared to cloud which is (usually) regularly updated.
Only buy Sandisk I guess!
Yes with the new PCIe expansion in the latest RPi 5 you can have external SSD for example, but if you decided to use it for other purposes as well like extra Ethernet port expansion then you cannot use it for booting anymore.
Cost. It's always cost.
If the eMMC or SSD storage is not enough to hold a general purpose OS for all users, then only some users get the value. And if it is big enough, it's put the cost of the machine up above the point at which they feel happiest, when an SD card is perfectly fine for the majority of their target users.
Eben Upton is regularly on record talking about how the cost-per-component/users-per-component tradeoff will lead them to avoid adding a component, and has motivated removing some (composite video for example)
It's curious that there are people who need this, are aware of the compute module, and still complain about it. Is the the availability of the compute module that's a problem?
Been running pis (mostly 3b+) for eons with this solution and at this point i can say it's bulletproof.
The key is to minimize the sdcard wear and tear (it uses an overlay filesystem with squashfs as base and tmpfs as write top layer) and to keep zero stare on the device. You can build the image starting from normal raspbian. You can also update it over the network.
As far as usage in the wild the largest "deployment" (i know about) is at around 1000 pis.
https://raspberrypi.stackexchange.com/questions/124628/raspb...
It is quite possible for updates to not break a running system but make it so that it will break on the next reboot. E.g., a dynamic library gets updated in a way that breaks a server process. It doesn't affect the running server because it still has the old library loaded.
Next time you boot your server process doesn't start.
These kind of problems can be annoying to deal with, especially when your system has an uptime of years and for all you know whatever change broke it could have been in any one of dozens of updates you've applied over that time.
Probably one should have a canary system that is rebooted every day. In a home setup we usually don't hand either the spare machine or the spare time to deal with it, or both.
If there is an urgent update that you need to apply at a time when rebooting would be an issue apply the update and leave yourself a reminder that the system is running a configure that you don't know is bootable. When a reasonable time for a reboot comes around take it.
I take it a step further. I usually reboot before updates, too. Make sure I won't chase updates as an issue if something else broke.
This makes me sad. I don't doubt that there are scenarios in which having IPv6 connectivity makes things worse, but these days, the opposite is more common, so I don't think "disable IPv6 just in case" is a good blanket recommendation to make anymore.
"If disabling IPv6 fixes your issue consistently, consider disabling it" would achieve the same outcome, without potentially causing problems/inefficiencies down the road.
If there's a really really good reason, step 2 is to get rid of the SD card. Personally, none of mine even have an SD card inserted (ok, one does). I use network boot/NFS for everything. Some people attach other kinds of SSDs.
The one I lied about is a reverse telnet server that has been quietly doing its thing for 4 years without a hitch, apart from the time I had to replace the (PiJuice) backup battery because it was looking a little swole. But I should take the time to at least have a backup of the card ready to swap out when it fails.
Lots of people in this post have mentioned uses like that. I want to make outdoors ADS-B receiver, and Pi will fit in enclosure and be powered by PoE. I want to make GPS time server, and Pi has PPS input on header. I want to make portable ham radio box, and Pi can be powered by 12V DC.
Also nice, is you can make your data or other partitions be encrypted. I've done this before. On the Pi 5 you can use the standard encryption as there's hardware support. On earlier Pi's you can use the encryption used for android. This does means there's a manual step in the startup for you to enter your encryption password.
Yet I've been feeding ADSB-Exchange and FlightAware from a Pi Zero for years and never had SD card problems.
I really like Alpine Linux for the Pi, running in it's own read-only mode where changes must be committed to disk. But unfortunately, Pi-hole isn't compatible with Alpine (at least last time I checked)
EDIT: Also, make sure the power supply is sufficient. I was using a cheap adapter and had random errors and reboots.
I use a USB network card, and a high-quality SD card. Other than that, no other special configs (except for another spare SD card with a full system image clone).
Rock solid performance and uptime over 8 years.
USB micro is designed to snap at the connector, not the board. And the connectors will indeed snap.
I've been running RPi for years (including a VoIP server on a RPi 1!). The two tricks if you want a really long running Pi are: SD cards mounted read-only and ethernet.
FWIW I ve got a Pi running the unbound DNS resolver and it just works. It is not an art. There s a reason businesses are scooping up millions of Pi: they just work.
P.S: I ve got an army of NUCs too.
I've had an RPi4 running continually for close to a year and never had a single network connectivity issue between the RPi4 and my router, connected via a 30m cat5 cable in my 75m² condo.
The biggest problem is loss of wifi, after a few months one will lose wifi, but keep working - it’s constantly recording data so a reboot is not a good idea. I’d prefer a solution where I could just reset the wifi, but all attempts to script that reliably so far failed.
for context, my workload was bursty in nature and nowadays it is mostly idle. but i never had any issues with the SD card, and i only upgraded to a new one for getting more capacity all this time (only twice).
keeping the dust out and managing the temperatures would go most of the way. i have served files directly from the sd card but it is always better to mount an external drive for this, while providing enough power to the board to power usb devices. limiting debug logs for stable applications can also help avoid write cycles, but using sd card on a pi has been a similar workload to using one in older smartphones for storing media.
The eMMC has a known supply chain and is guaranteed for 1 million write cycles that are then wear leveled. The SD card could be coming from anywhere, or a counterfeit with who knows how many write cycles and wear leveling.
The CMs are built for industrial use and I've shipped a few products based on them, shipping thousands of units. They have had zero flash failures.
i don’t really get what to use a rpi for but i guess not important, it was just a nice series of articles
I also had an LG monitor that had so much feedback it would disable the WiFi interface completely. So I would check your monitor, if the pi is connected to one.
Everytime there's a RPI I cry about it.
Why is the author not considering using an SSD instead of an SD-Card here?
Mouser is your friend.
What are you talking about?
It is literally zero effort. Just set up crontab reboots in case of power outage. That's it.
I've had a pi running as a BLE gateway / security cam for over 4 years with zero intervention.