There are many questions similar to mine and none with a coherent applicable answer.
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.
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.
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.
- 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.
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.