Sd-card corruption?

Touché
That’s true, but I did not try it on any other hardware.
On my RPi it works flawlessly - so that’s good :wink:

One more (possibly stupid) question.
If the SD-card is corrupt, does this mean the card itself is ready for trash or just the data?

When I setup the system from scratch I wonder if formatting would re-animate SD-card after corruption.

Well it means you have hit a (eventually intermittent) HW problem. Reformatting might or might not spot that as a bad sector and might or might not exclude it from future use.

Bottom line is, you can’t be sure. I would not reuse that card in a Pi, but you can still make use of it in less write intensive applications like say a camera.

99% of the time it is only the data that is corrupt and flashing a new/backup image will work fine. I have personally worn out multiple USB sticks, but I was working full time doing beta testing for an embedded system and hammered them big time in ways they were not designed for. Of course it may have been from another fault as they were low quality no name brands. Never seen issues with brand name industrial grade flash.

Flash the SD and if it works then great, if not try flashing another SD card with the same image and if that one works then you know the other needs to be trashed after first checking that the image is not larger than the space on the SD card. Two ‘identical’ cards even same brand, size and model can have slightly different amounts of space so using a linux program like gparted / parted to reduce the partitions down helps to create smaller images and helps when you want to write the image to another card. Take an image before playing with parted if new to it :slight_smile: By reducing the partition size your backup images also take up less HDD space to store them.

I run an Odroid U3 for three years now with an emmc. And now my emmc is broken. At the moment I run it temporary with an sd card and it is much slower than before. :frowning:
But now I will switch to an Odroid HC1 - a cheap ARM computer with a SATA connector. I hope this helps to prevent corrupt cards.

Another hint is to move your swapfile to USB or NAS. Swapping (or paging, to be more precise) happens all the time and goes to /var/swap in default Raspian. Configure a new location in /etc/dphys-swapfile.
Use dphys-swapfile swapon to activate and swapon -s to validate the outcome.

Damn it - I feared that someone would say somthing like this :wink:
Thanks for the confirmation.

Hmmm… might be an option as well.
I will check out which suggestion will work for me best. :slight_smile:

All,

to get of frequently appearing issues with openhab (cron not working properly, persistence hangups) I decided to eliminate sd-card corruption issues (maybe causing the issues above?!)

To do so I just purchased an element14 desktop housing for the pi including a ssd:
https://www.element14.com/community/docs/DOC-83477/l/desktop-computer-kit-with-expansion-board-that-can-turn-a-raspberry-pi-into-a-real-desktop-pc

and installed openhabian 1.3 from scratch.

Just a short (maybe stupid) question:

@ThomDietrich and others
If I did a backup using openhabian-config on my NAS and assuming that one or the other file might be corrupt already - can I import the corruption back into my brand new setup?

Does this mean, I need to configure everything again?

Everything in conf can be verified by simply opening the file with a text editor, or even using less on the command line on the Pi itself and scan through them for anything that looks out of place. Even better would be to use VSCode or ESH Designer.

You can do the same for the contents of the /var/lib/openhab2/jsondb files. I don’t know if there is an online JSON checker but I would be surprised if there isn’t.

I believe those are the vital files. If those are all OK then you only need make settings and install bindings again to start from scratch which isn’t that big of an effort. I have to do the same pretty much every time I update my Docker image and it rarely takes more than a few minutes.

Thanks, Rich,

I will check the files you mentioned manually.
I am really keen on seeing my system run for months without any issues with the new ssd approach…

I’m not running Raspian, but I would never enable swap on RPi. Do you really need it in an OH environment?
I would have every partition read-only except one, if really needed (database log e.g.). And I would make the RPI backed up by a simple battery solution at least.

I don’t even enable swap on my desktops (the last 15 years). Guess I’m a bit damaged… :smile:

Sorry I have to confirm that :wink:
Yes you can get along without swap (well, paging actually) if you know your workload very well. But that does apply to just very few people and use cases, and certainly it would be bad advice to the average user.
That’s particularly true on a RPi with 1GB RAM and OH process eating ~600MB, not counting OS and helper apps.

1 Like

Well, 1GB should be plenty, not saying it will work for everyone. But it is very easy to test, over a few days; either it works or it doesn’t. If it does, media wear will be reduced for sure. You might even get some better performance.

I agree that media wear will be reduced, that’s why I do it, too . But unlike you I needn’t be afraid of running out of (virtual) memory. But then again I have a NAS.

We’re discussing if and how to include that in openHABian.
Now NO swap for a somewhat unknown extent of use and an unknown level of user knowledge - nope, that’s too risky a thing.
For users to not own a NAS, I’d suggest to add a USB stick and to put swap (and logs and persistence db) there.

1 Like

I actually do not run OH on a RPi, but on my main server, which runs on a UPS, but at work we produce a lot of embedded linux products running off uSD, which is why I suggested this as a solution in this thread.

I haven’t heard of any filesystem issues since we started to ship them out a couple of years ago. We do, however shut down the machine and sync fs using onboard caps on devices that are writing to the (uSD) disks. We also take care to test uSD carefully every time we change the uSD make/type/models.

Not suggesting anything for openHABian.

The best option is to have a swap partition configured but set vm.swappiness very low so it’s not used unless absolutely necessary. Setting vm.swappiness to zero means it’s only used if the OS would otherwise crash.

1 Like

Good idea.
Btw, that behavior changed a little. vm.swappiness = 0 now means NO swapping at all.
What we want can be achieved by setting vm.swappiness = 1 now.
I feel openHAB startup is a little faster now, too. Haven’t done any measurements, but that’s somewhat reasonable to believe in.

Ah. Well, in fact mine is set to 1, I thought it meant that when I set it up I felt a very tiny little urge of swapping :smile:

If you want to fix the SD card, formatting is a good idea. If you want to recover a corrupt SD card, you can only do it with a data recovery tool.