2

There are many questions similar to mine and none with a coherent applicable answer.

Setup
Raspberry Pi OS Buster; up to date. Raspberry Pi 4B. Red LED has a steady glow: current is stable.
Both ADATA SD-card and a 3.0-compatible Kingston USB stick in 2.0 port were used as boot mediums. Both failed after a single power cut.
When the power got cut, activity on the Pi was minimal. No updates. No editing. Only an open browser with two tabs in it.

The issue
Consistent & complete inability to boot after the power is cut.
I am not describing an issue where people want for Pi to auto-reboot after power is lost. This is an issue where it just will not boot the OS at all, after a power outtage. All power outtages described were from pulling out the cord out of the Pi/out of the wall socket.
While trying to boot green LED shows varying activity, flashing at different intervals with varying speeds.

Research
Researching this issue had produced a number of both decent & inappropriate solutions. Ranging from adding UPSes & batteries to reflashing the boot medium.

Neither of them are helpful. Reflashing works. But I want to repair it. Not reinstall it like some Windows system after another failed auto-update.

Among the more promising solutions were running fsck against the partitions on the problematic boot medium & manually copying over the boot partition from the official image, replacing the problematic boot medium's one.

Tried solutions

  • The first thing I have done is a manual fsck from my Linux box. The rootfs indeed had an error. However, after it was fixed Pi still fails to boot from the stick. And it was also failing to boot the previous installation from SD card, also after a successful fsck. Partitions mount just fine. Everything appears accessible. I see no signs of any data corruption.
  • After this I copied over original boot partition from the same Pi OS image using dd. I also copied over the first 8096 sectors of the image. These sectors are the "empty" space preceding boot partition, including MBR & partition table. The only partition I didn't copy over from the original image is the rootfs. I updated partition table with cfdisk to reflect the real size of my rootfs, versus the smaller size from the image. As a result - all partitions mount. Neither of them have errors. All data appears readable. PARTUUIDs are the same as of the original partitions. Sizes and offsets are the same as they were when I first burned Pi OS image to this stick.

So my question is - why the heck is this not working? Everything looks normal. That'd be enough to kickstart any Arch or Debian system. How is this not enough for Raspberry Pi OS(buster, full)?

There were reports of success when using NOOBS vs raw Raspbian installations.

https://www.raspberrypi.org/forums/viewtopic.php?p=1197519#p1197519

must have unplugged it at least 20 times so far with the installation via NOOBS, and still no problems, and yet the direct Raspbian couldn't survive 1 power cut, so it seems NOOBS does more than just simply installing the easy way...

All of this makes me think that it has got something to do with the initial boot sequence. Hence the difference between NOOBS & regular Linuxes being able to repair themselves. Unlike Raspberry Pi OS.

However. How do I fix it?! I don't want to do a clean install every time I trip over my extension cord! How do I repair it!? What are the steps? Why is it not enough to simply write the original /boot and even the original MBR onto the stick? Where is the problem?? Which one of the components is failing this miserably?

Please, help me get to the bottom of this.

Improve this question
6
  • WRT overwriting the possibly corrupted MBR with "the original one" or whatever: #1 It's actually only the first 512 bytes, the other 8191 sectors in that block aren't used (this is just a convention WRT SD card images/formatting), but #2 You don't need to do that anyway, esp if you are going to run cfdisk and correct it -- just run cfdisk and create it.
    – goldilocks ♦
    May 30, 2021 at 14:56
  • Beyond that, you have a problem most people do not have, which makes it hard to diagnose. I've had Pis for ~9 years, and of course there have been plenty of power failures and pulling-the-plug without proper shutdown for whatever reason, but there have only been a couple of times one would not reboot (WRT fsck, note that this is run if an fs is unclean at boot anyway, you don't have to do it manually etc). This is what most of the other regulars here will also say. Point being, either you have a dud device or awful luck....or something.
    – goldilocks ♦
    May 30, 2021 at 15:01
  • There are at least a couple more people facing this exact same issue with a 100% reproducibility. The entire forum thread that I linked in my question is dedicated to this specific issue. However, they only come up with workarounds, rather than addressing the issue directly. But, alas, your point still holds true. Thank you
    – MickeyDickey
    May 30, 2021 at 15:53
  • 1
    You are wrong. There is an established (and recommended) procedure - restore from your backup (or reinstall). You are unlucky but most of the "solutions" do not work because some code is damaged. NOTE it is extremely unlikely the boot sector is damaged so replacing it won't help. It doesn't even need to be mounted. The root FS is damaged.
    – Milliways
    May 30, 2021 at 23:09
  • 1
    I concur with goldilocks - I currently have 8 pi's in service - and have had pi's since the original (is it really 9 years?!) - I've had multiple power failures, I've even yanked the power myself on the odd occasion when I was too lazy to shutdown before working on a particular pi - not once has this resulted in an unbootable pi - either you have a dud pi, or there's something you've forgotten to mention, though I can't see what that would be
    – Jaromanda X
    May 30, 2021 at 23:37

1 Answer 1

Reset to default
1

DO NOT do this. It is similar to cutting power with additional risk.

I found a mildly satisfactory workaround.

While this doesn't help recover after a power failure, it does help you keep your Raspbian install operational in case you have to cut the power to your Raspberry Pi. For example, if your system crashed or you have lost ability to provide input to it.

Simply remove the boot medium, and then cut the power supply to your Raspberry. This will make it so that you can later on boot from the same medium, without having to reinstall/restore from a backup.

For those of you who were active in the comments - thank you all.

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.