I am developing a background service that runs on Raspberry Pi OS based on Buster, Bullseye and Bookworm in both 32-bit and 64-bit variants. I test this application on several Raspberry Pi 4 with varying amount of RAM (1 GB, 2GB, 4GB and 8 GB) and varying base distributions to ensure compatibility with the target systems.
Open source, private, or for profit/sale?
I have a problem on some of my test platforms in that a configuration definition change causes the application to crash the RPi 4. The upgraded application crashes when reading the configuration using the older definition. This crash happens so quickly that I dont have time to log on to the RPi 4 with ssh to either stop the background service or disable it. I didn't expect this change to crash the application. I usually disables the automatic start of the background service if I think it may crash so that thr target platformn only crashes once instead of repeatedly.
Is the application crashing or the entire system?
If it's just the application you should still be able to login via other methods: serial, ssh, by switching to a different VT, ... Assuming you have enabled them that is.
Sounds to me like you need some additional logging in your background service. I can't advise on doing that as you've not told as anything about the program language in use and how you're starting it. Though I find it difficult to see how one background service could crash the entire OS. Unless you're doing something questionable that is.
Is there a way to either edit the Micro SD cards ext4 partition on a Windows PC outside of the test platform or start Raspberry Pi OS without starting the enabled background services on the test platform.
Several:
- Install third party software that can read ext2/ext4 partitions.
- As already mentioned, WSL2 with the correct incantations
- A correctly configured VM running Linux (you'll need to give it raw access to the card reader)
- Boot the PC with a live Linux CD/DVD/USb
I really don't look forward to overwriting the Micro CD card with a fresh install and then having to perform all of the tedious development setup steps again. Fortunately for me was now changed source code checked out to the crashing device.
You don't have a backup then?
Best practice would be to take a back once "all of the tedious development setup steps" are done and before and after any major changes/updates. It's also a good idea to keep important data (like the source code) on a different physical device to the OS - recover from a totally broken OS is much easier that way.
Statistics: Posted by thagrol — Thu Dec 26, 2024 12:07 am