tl;dr To get a USB flash drive to boot, I needed to use diskpart to make the boot volume “active.”
To do this, under Windows 10, I launched a Cygwin shell with administrator privileges. (CMD would probably work too.) Then started DISKPART.
In diskpart, I used “list disk” to find the disk. “select disk X” where X is the disk number.
“list partition” to find the boot paritition. “select partition X” where X is the partition number.
“active” to make it bootable.
“detail partition” shows whether the command worked or not.
This is after I tried a lot of different things. Among them, I booted the current version of Raspberry Pi OS (on a microSD) and used raspi-config to check the boot order and eeprom of the PI 4 (both were fine).
It’s surprising to me that Etcher did not set the Active flag… but the problem existed in the Raspberry Pi OS Lite image that I used too.
This is all a workaround because I have destroyed too many microSD cards using the openhabian image (probably would happen under Raspian as well). When a write happens to microSD card, if power is interrupted, the card goes into a locked mode that is basically unrecoverable. No other modern operating system has the problem - sure, if you interrupt power, whatever is in your cache should be toast. But your system shouldn’t become unworkable.
I’m currently trying with a USB Flash stick, but I really don’t know if this is more resilient to the write problem. I have a USB SSD waiting in the wings in case this happens again, but I’d prefer not to dedicate it to this problem.
Also the PI4 runs hot. And it’s USB runs hot. That’s not great.
This is definitely not a general openHABian or Raspbian issue or else we would have heard of that.
You’re the first to claim this that I know of (and yes, I’ve been writing to and burning images to SD on the order of gazillions, including many intentional and unintentional power cuts while doing so).
Possibly the issue is with your hardware ?
Are you sure it somehow breaks the SD card and it’s not just corrupting the file system. Any “modern operating system” will have this problem because the root of the problem is how SD cards physically work. I won’t go into all the details but the tl;dr is when a write occurs, that file and all the other parts of files that exist in that same sector gets copied to the new sector. If you pull the power, you’ll lose not only the file being written, but everything else in that sector which could be part of the OH kernel, file tables, or anything really. This is how SD cards physically work. It’s not something the OS can control.
It’s not because thumb drives work the exact same way as SD cards.
If you are unwilling or unable to invest in an UPS for your Raspi, you’ll need to move to an SSD or HDD for your primary storage. No computer running off of an SD card or USB Flash drive can handle sudden power losses unless it’s set up not to write to the SD card very often if at all (read only file system). And you are in luck as openHABian moves a lot of writes to a RAM disk through the ZRAM config though this is not a full proof solution. Other parts of the OS write to the SD card too and if any write is taking place when power is lost your whole file system can become corrupted.
But note this does not destroy or break your SD card. It only destroys the data on the SD card. You can reflash it with a backup or a fresh openHABian or Raspian and continue on as before.
Add to your explanation that the controller in an SD card looks for mistakes in its EPROM. When a mistake is found, it sets a bit that makes the whole card read-only. Normal means of making it read-write again won’t work. There is a workaround I found once, years ago, that could make it writeable again, but the problem was the card just failed again a little later.
Yup, I’m aware thumb drives basically work the same. I’ve just never had the problem before with a thumb drive… and had it at least half a dozen times with microSD.
The ZRAM concept is interesting… but I was running it when I lost my most recent microSD…
@mstormi , your ability to point me at the article you wrote describing your response to the question directly contradicts your statement that this is not “a general openHABian or Raspbian issue” … but I do find that everyone starts sounding a little defensive when they talk about this issue. Not sure why. Suffice to say, thank you for the guide. I will definitely be adding a UPS to my system.
No I don’t see why. Sure it affects every RPi but you said it’s an OS issue specific to openHABian and eventually Raspbian, indicating it’s buggy behavior and could probably be fixed somehow if just someone jumped the barrel - and Rich and I responded it’s not that (OS) but ultimately a hardware issue.