I was hoping that this would be the answer. Just checked on the 1119 issue and there are some with the freeze issue having the same 8g version as you.
Database file should not have such a problem. In most cases YES you will get errors about it afer you restore and then you can just delete it and restart your HA. It shouldn’t be that a snapshot won’t restore or that you’d have to go into such lengths of uncompressing a snapshot and recompressing without the .db file.
If system isn’t coming back after you restore you’d have to check what the supervisor and core logs are saying.
The hardware revision on the 8GB was primarily addressing changes so that all 8GB can be used on the board.
There was also a slight board revision 1.1 vs 1.2 for 2/4GB boards to address an issue with USB-C compatibility as well.
Not sure if such chages would have ay different effect on usb booting though 
You are correct that 1.2 fixed the USB-C power supply issue. JPSY has 1.4. Not sure if there was any changes that could have effected the impedance of the USB C ports, which in turn could effect timing.
Have you used checked the memory usages?
I’m seeing in my install a huge amount being used by HA (in this setup, only with 4Gb).
I narrowed it down with using the Service profiler.start_log_objects to the set_location service…
But maybe something else is happening?
VM so far stable and it has allocated the same amount of 4GB RAM. It may be anything resident, sure the geoloc trackers also calculate/save something all the time but VM on my desktop apparently doesn’t have any troubles. I will go for better hw. Nuc or vm on synology nas. There is a great thread comparing rpi/odroid/nuc
Okay, then an other issue.
RPI is now my only option since I’m traveling and not able/willing to buy other hardware.
Without this grazy memory usages (like 600MB in a couple of hours) it is fine.
I only have a couple of sensors and will add a few relais…
This mem usage is completely normal for HA and a more or less virgin system. This is the reason why systems with more add-ons easily start to lag on RPi 3s with 1GB of mem. It is also normal that the mem usage slowly ramps up after reboot and takes some hours to reach a stable level.
My extensively configured HA allocates approx 2GB when grooved in.
Okay, makes sense when indeed a lot of devices are connected. For me I just see a connection between 1 service homeassistent.set_location and this amount of memory.
At the first line I start the node-RED with the service. Within a couple of hours there is almost a GB used for only this service. (have to mention it gets updated every minute).
Second line is node-RED flow deactivated and HA (in docker) restarted.
Then it gets stable.
Yes, but memory account ramps up also with add-ons. You have Node RED installed, which is definitely not lightweight. Have you checked you HA Logbook for many entity changes coming in? Anyway, I don’t think this is the place to discuss HA’s memory consumption. It has nothing to do with setting up RPi 4B and SSD boot.
On you configuration. What firmware version on the StarTech controller? I believe ending in 02 is the latest. Also are you using the top or bottom usb3 port?
Still trying to see what is different.
Thanks
@Jpsy,
Used the latest firmware on the StarTech 3.1 controller and tried the OS 5.12 again. Locked in 4 hours. No errors in any of the logs. Still have yet to see a failure on 5.4.
This IS a veritable conundrum. I read through your issue report where Agners tried to provide a debugging version. A pity that he did not succeed. I hope that this strange behavior will finally reveal it’s hidden logic and it all will lead to a better OS.
His debug version would not boot off of the SSD. I wish I was the only one, but it looks like more and more people are opening GitHub issues. Most of the people there have use Home Assistant for a while and understand what they are doing. It does not look like the inexperienced “operator error”. It looks like there is an issue somewhere with the OS. As you are aware there were major changes to the OS for the Pi after 5.4. I hope the answer isn’t they will stop supporting Home Assistant on the RPI4.
I also tried the method that is “support” and installed on an SD and move all but the boot to the SSD. This failed also after 3 to 4 hours. No difference than just using the SSD.
Thanks for trying! If I see something useful, I will post it here so you can attach it to your directions.
Bill
Does it even make a difference if you run the full system from SD only? If this fails too it would rule SSD out of the equation completely.
I was running successfully with the Sd up to version 5.8 (32 bit). I went to 64 bit when I went to SSD. I was told by @agners that the new versions of the OS supported 32 bit booting of the ssd. I have tried several and could never get this to work. I tried the recommended supported split version (sd boot/ ssd for everything else) and this failed after several hours with the 64 bit OS. My next test will be trying the split again with the 32 bit version of the os. I was hoping to try the 32 bit ssd first as once you go to ssd it is hard to go back to sd.
So in theory this could be a problem with 64 bit and possibly it is not related to SSD. Maybe you could take the time and try 64 SD only to see if it stalls too. This would considerably narrow down the possible sources of the problem.
That was one of the first questions I asked in Nov (which never got answered). I thought that as your 8G version worked where my 4G didn’t and my 32bit SD worked that the 64 bit could be the issue. Remembering how when windows first went from 32 bit to 64 and how some programs had issues, this could be a similar issue with how memory addressing was done. I believe that using the split version SD /SSD tests the pi with 64 bit (which failed), but I am not certain?
Each test with the SD is slow to setup. The split version takes about an hour (boot, restore, move). The SD setup is a little faster as there is no partition move. The test takes around 3 hours to a few days (when it freezes) so I would like to have some feedback from the developers on what to try and what to capture that will help resolve the issue.
I believe that there are enough people with this issue to do a controlled experiment to figure out a solution. We just need what to test that would help the developers determine the root cause so it can be corrected.
I am already for several days running HA in VM, it’s super fast, super reliable and hasn’t freezed yet. I put fresh HA on the RPi to control my projector only, which I control using HACS remote control (control slave HAss with master HA) and it works like a charm. My freezing is definitely related to expanding HA regardless of booting from SD or SSD, or running 32/64bit version. It’s the capability of RPi to handle continuous tasks.