Not a problem - I too wanted a PoE device, but the supply issues around CM & RPi increased the risk so went with a kit.
The RPi foundation have a sensible policy of releasing some stock to hobbyists, but keeping business users solvent with priority access to a constant trickle of devices. I suspect this is also why the Pico 2040 was created - easier to get made, and might reduce demand for full RPi4.
FYI - after a “move datadisk”, it looks like all user data for the HASS container is indeed now on the SSD (SSD /dev/nvme0n1p1 = hassos-data fs label):
$ mount |grep nvme
/dev/nvme0n1p1 on /data type ext4 (rw,relatime,commit=30)
/dev/nvme0n1p1 on /config type ext4 (rw,relatime,commit=30)
/dev/nvme0n1p1 on /addons type ext4 (rw,relatime,commit=30)
/dev/nvme0n1p1 on /backup type ext4 (rw,relatime,commit=30)
/dev/nvme0n1p1 on /ssl type ext4 (rw,relatime,commit=30)
/dev/nvme0n1p1 on /share type ext4 (rw,relatime,commit=30)
/dev/nvme0n1p1 on /media type ext4 (rw,relatime,commit=30)
/dev/nvme0n1p1 on /etc/asound.conf type ext4 (ro,relatime,commit=30)
/dev/nvme0n1p1 on /run/audio type ext4 (ro,relatime,commit=30)
/dev/nvme0n1p1 on /etc/hosts type ext4 (rw,relatime,commit=30)
/dev/nvme0n1p1 on /etc/resolv.conf type ext4 (rw,relatime,commit=30)
/dev/nvme0n1p1 on /etc/hostname type ext4 (rw,relatime,commit=30)
/dev/nvme0n1p1 on /etc/pulse/client.conf type ext4 (ro,relatime,commit=30)
Everything else is on the CM4 eMMC as before (it’s Move datadisk, not move everything). This is harder to capture without a root shell on the supervisor, but there’s still ~9 mounts from /dev/mmcblk0:
- hassos-boot
- hassos-kernel0
- hassos-system0
- hassos-kernel1
- hassos-system1
- hassos-bootstate
- hassos-overlay
- hassos-data-old (the OLD eMMC data partition, now on SSD)
- hassos-data-external
Should have guessed that HASSOS has two kernel and system partitions - roll-back from failed updates?
And even with Z-Wave, Zigbee, MQTT, ESPhome, etc the 2Gb RAM on the CM4 isn’t stressed. Perhaps my previous hardware of a 8Gb RPi4 was overkill! 