1

console looks like this

My headless Pi 2 (running stock raspbian) sometimes crashes out of the blue. It happened again today, and I had a monitor attached so I was able to get a photo of its final words. I just don't know what to make of them, to be honest. I see some call stacks that seem filesystem related, so I figured a fsck might shed some light, but that doesn't report anything unusual, besides

There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
  65:01/00

What can I do, other than replace all the SSD Card and/or USB stick? And why would a broken drive bring down the entire system?

Improve this question
4
  • "why would a broken drive bring down the entire system?" -> Because the entire system is stored on a physical medium. If the drive doesn't contain the root fs, I/O failures can still cause serious problems because of uninterruptible sleep states. If it does contain all or some part of the root fs, then it can easily bring the system down (grinding it to a halt). This is true even if the issue is just some corruption of non-vital things, because the whole device may end up hung for arbitrary intervals.
    – goldilocks ♦
    Mar 19, 2021 at 19:04
  • That said, I'm not sure that is the issue, although there may be parallel symptoms.
    – goldilocks ♦
    Mar 19, 2021 at 19:05
  • Another suspect for random crashes is always faulty RAM. I never used one, but I'm certain there's some memory test program that also works on the PI.
    – PMF
    Mar 19, 2021 at 19:14
  • 1
    the output in the screenshot mentions vfat, and the root fs isn't on a vfat partition. /boot is, and so is the USB stick that's mounted. I guess I'll start by removing the USB stick and see if I keep getting crashes. could be a long process of elimination.
    – Enno
    Mar 19, 2021 at 22:43

2 Answers 2

Reset to default
2

This looks like the end of a kernel panic message. It's hard to say what caused it without seeing the full message, and even preceding messages, say, 10 seconds before the crash. The fact that one of the CPUs was inside fat_write_begin when the crash happened doesn't mean the crash had anything to do with the filesystem. It's impossible to determine from your screenshot which CPU actually crashed.

You should be able to collect a full log using a UART connected to a terminal on another computer. That computer would have to be working when the crash happens.

Improve this answer
2
  • Thanks. This is the sort of answer I was looking for, but I don't have any experience with that sort of debugging, and I don't have an adapter for it, so I'm going to wait with that for now.
    – Enno
    Mar 21, 2021 at 18:18
  • @Enno Yeah, it's not exactly easy to set up, and even with such a log there's no guarantee that you find out the root cause, or will be able to fix it. In practice, people often keep changing the HW/SW configuration until there are no more crashes.
    – Dmitry Grigoryev
    Mar 22, 2021 at 9:32
0

Yes, remove all additional hardware first. If that doesn't help, try cloning the contents of your SD card to a new SD card. If the error no longer occurs, then it was due to a broken SD card. Otherwise, you could reinstall the operating system (possibly make a backup of the existing OS first). If all this does not help, then your Pi seems to die soon. Maybe you have a second RPi that you can use to see if the error moves with it. Note, however, to change only one thing at a time to be able to reliably determine afterwards where exactly the error was.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.