I installed my Home Assistant Yellow today with a Raspberry PI CM4 with 32 GB eMMC and a 128 GB M.2 SSD. The Home Assistant installer used the eMMC storage for installation and data but I wanted the M.2 SSD to be used. The Home Assistant hardware overview does not show the M.2 SSD at all
Is there a way to verify if the M.2 is initialised and formatted?
Furthermore could I move the Home Assistant OS and data to de M.2 SSD?
3 Likes
Have you tried Settings → Storage → top right … → Move Data disk?
The setting is a bit buried in the menu.
The SSD should also appear as a device in the system … menu, but you’d need to click through all the storage devices to find it.
1 Like
Yes, I did. I ordered a new NVMe m.2 disk to check if there is a hardware failure.
The press images show a 1TB Samsung 970EVOPlus M.2 SSD, which is seems to be overkill as an upgrade from a 32Gb eMMC!
The NabuCasa Yellow datasheet says Supports 2230/2242/2260/2280 modules, but that’s about all it says.
https://yellow.home-assistant.io/resources/
As you’ve tried already, Settings → System → Hardware → top right … → All Hardware should show an additional device as well as the eMMC (my eMMC shows up as mmcblk0 = /dev/disk/by-id/mmc-NNNNNN_0xXXXXXX). No idea what the M.2 SSD /dev/* entry will be though.
The best I can suggest is to get a cheap USB3 → M.2 caddy as a hardware test?
1 Like
A 1TB SSD is definitely overkill. What I was hoping for is that I could use the SDD for the OS and data but that seem not to be possible if there is eMMC storage on the CM4. My goal was to buy a CM4 without eMMC but due the RPI shortage I could get the one I have now.
1 Like
You guys who have received their Yellows–
I placed my order on July 10 and the estimated ship date has been bumped about 4-5 times. Last Tuesday, they sent out a general notification that “the remaining orders from this batch will ship through the rest of this week.” At that point, my estimated date was October 7. Then on the 7th it got bumped yet again to 10/14. Crowd Supply does not seem to reply to emails (as I’ve sent 3 with no response).
May I ask when your original order was placed and how recently you received it please? I don’t mind waiting but the lack of communication and constantly inaccurate ship dates is really troubling. I’d like to get a better understanding of a realistic timeframe from those who’ve received theirs. Thanks.
2 Likes
I placed my order september 2021.
1 Like
The NVMe m.2 is visible in the hardware overview, it’s called /dev/nvme0. I moved the datadisk to the NVMe as well. So far, the good news. However, after playing around and reinstalling Home Assistant there are some partitions left on the NVMe which prevents using the NVMe as datadisk again.
Is there a way to remove these partitions via the OS?
1 Like
I can see a way to remove partitions on the eMMC, but it would take a reinstall and a load of sys admin:
- Make a full backup
- Boot generic RPiOS from a USB drive
- Wipe the eMMC (something like
dd if=/dev/zero of=/dev/mmcblk0 bs=4096 4096) - Boot HASSOS from a USB drive (or put the SSD in a USB dock and use a PC)
- Reinstall to the SSD only, ignoring the eMMC
- (check the partition layout)
- Restore
I’d suggest a bug report, but the feature is called “Move datadisk” so it’ll get closed immediately. WTH candidate?
If eMMC is only used for boot, the write count is likely pretty low (effectively RO apart from ~monthly OS updates) and certainly a lot better constant stats database updates. Agree that getting ALL data off the eMMC would be better - and allow easier hardware upgrades later to a CM without storage (Wireless/8Gb/Lite CM4108000 would be my choice until a CM5!).
1 Like
I ordered a cheap NVMe > USB dongle so I connect the NVMe disk to my laptop and remove the partitions.
The choice using a NVMe disk is to move the writes away from the eMMC because I have concerns about its life with extensive writes.
Keep you posted about the results!
1 Like
Amazon just delivered a Samsumg SSD 980 NVMe M.2 with 250GB (as that was the smallest in stock).
250GB still seems overkill but, currently moving my datadisk from /dev/mmcblk0p8 to /dev/nvme0n1:
The /dev/* suggests the eMMC partition won’t be reused, and the whole NVMe SSD is used just for data.
As I once found a bug where a load of MP3 files prevented a HASSOS backup from restoring onto a RPI4, having Used Space 2% on the SSD is more about better longevity than creating another media server / NAS.
(For completeness, the backup fix was to untar the backup, remove the MP3 files from /media and re-tar. This made the backup file a lot smaller even on a 32GB uSD.)
2 Likes
I am patiently awaiting the arrival of my PoE Yellow. I really appreciate all of you documenting the process of using both eMMC + NVME drive, as that is my planned architecture as well.
Thank you, and keep the information coming. You’re going to help many users in the future!
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! 
1 Like
Via the NVMe > USB dongle I managed to removed the only partition. After moving the NVMe disk to my Yellow I was able to move the datadisk again.
I expected that after the move activity is completed a reboot would occur, after waiting for more than an hour I pulled the power plug and the yellow started.
The red and green led remain constantly on. The same experience occurs after updating the HAS OS update or a simple reboot from the GUI.
I’m still not convinced about the stability of the Yellow.
1 Like
Yeah - now you mention it, my Yellow (hass-data on SSD) still shows “Migrate datadisk” as an option!
Note, mine didn’t reboot after the successful datadisk move - rather an anticlimax, really.
That looks like a re-install from scratch, unless the “factory reset” button combo works. 
Without reading the RPi CM dev docs, I can’t be sure about boot order, but using dd if=/dev/zero to completely wipe the eMMC, installing the HASSOS image directly on the SD (via a USB dock), then booting from USB will probably work. The more unknown behaviour is where the HASSOS installer will choose to put the OS files - eMMC or SD?
The weird thing here is that unplugging the power will result in a normal boot, but a reboot from the OS will not.
Nevertheless, I will start from scratch again using Option 2: Reinstall Home Assistant OS using rpiboot en a clean NVMe disk.
Hi. I received my Yellow yesterday. I’m using a CM4 module, that already had HA OS installed. I had no luck trying to reset and install from a usb. The installation would fail, and I would try again, and again. Took me some hours 
. Then I ended up on this page on re-installing. I have a PiTray mini, that I used to load the Home Assistant OS Installer for Yellow directly to the eMMC with Raspberry Pi Imager, and lo and behold, the thing booted with the Yellow led flashing and all. Now you know. Good luck with yours!
And now everything is restored from backup and running.
I did a reinstall Option 2: Reinstall Home Assistant OS using rpiboot en a clean NVMe disk.
The installation went ok and I did not move the datadisk to the NVMe disk.
A reboot from the GUI still does not work, but after removing the NMVe from the device a reboot works fine. So this has something to do with the NVMe disk.
Is there anything special to do to make the USB ports work? I can’t get any USB stick (i.e. neither my Z-Wave stick nor a storage device) recognized by the kernel.
Solution: I had to edit config.txt on the HAOS boot partition to add dtoverlay=dwc2,dr_mode=host to the [pi4] section. Everything works fine now. Apparently, the CM4 disables its USB ports by default to conserve power.
Postscript: So of course I got the wrong image (i.e. the generic RPi4 one). Any way to flash the Yellow specific image from the command line or do I need to extract the NVME drive again?
I replaced the MVMe SSD with Samsung SSD980 and now all problems are gone even after moving the datadisk to the NVMe. The yellow still starts from the eMMC but that’s fine for me.