I bumped on the same situation.
I actually don’t remember what keys I pressed (like Ctrl + Alt + F2, Ctrl + F1 and so on) but after some of them I got a usual login promt. I entered ‘root’ as login and it authorized me without any password.
Then I run ls /dev/disk/by-label/ and saw ‘hassos-data-old’ disk here. But HA requires ‘hassos-data’ disk, so I renamed ‘hassos-data-old’ to ‘hassos-data’ with the following command:
So the move data disk feature did not work for you? Would you provide some details on how you ran into this situation? I think for exactly those cases they leave the data on the internal storage, probably completely untouched next to changing the label.
But this way you did me/us a real favor: it seems like you answered questions 1 and 2 of
So it’s really „just“ the label of the partition HA OS is using to mount the data disk… quite handy. I would have expected to use a UUID or something similar specific.
Anyway, wondering if it’s therefore possible (aiming at answering initial question 3) to copy the data partition from an external disk back to internal storage. Probably with some steps like
make sure target partition/storage (internal) is of same size or larger as the source (external)
copying over with some dd magic
rename the partition as shown in the previous post
restart HA OS
Does that make sense? Unfortunately I (still) don’t have a spare/testing system to answer this on my own.
“The situation” in my case was the same as in @Morphy last reply.
I successfully moved data disk to new virtual disk on my ProxMox env. Then I realize, that I can just increase the size of “old” data disk, so, actually, I don’t need a new one.
I do the same as @Morphy: detach “new data disk” and run machine. And got the same message said “waiting for hassos-data”. That’s what I meant.
I ask google how to Undo move data disk and it leads me to this page. So after I found the solution I decided to post it here, in case some one will search the same solution.
And IMO, yes, HA uses disk labels to resolve some of its disks (I saw at least three disks with labels prefixed “hassos”).
Anyway, wondering if it’s therefore possible (aiming at answering initial question 3) to copy the data partition from an external disk back to internal storage.
Still could not test this so far. But I saw there were some changes in the Supervisor regarding discovery of external disks in 2024.4 releases aiming at improving things.
Adding to this thread - I’m recent HA Green user, it worked fine for couple weeks. Yesterday I’ve connected 750GB storage to it and used “Move data disk”, it showed the correct name of the device… but it never booted back up. I connected the disk to my PC and I do see the ext4 partition called hassos-data, so I guess this part work. Disconnecting the disk and power cycling the HA green didn’t start it up properly (it responds to pings though).
Giving my two cents here.
I run HAOS on a RPi 4 with a 32GB SD card. Backups go to a NAS I have so don’t take space on the data disk, although after 2 years of running and a few dozens of devices accumulating data, I was running out of space, so I plugged in an external 500GB drive and moved the data disk. Unfortunately the additional disk wouldn’t allow me to get other USB devices to work (namely a Google Coral TPU, because of lack of power, no powered usb hub at hand). So I started to look at how I could roll it back and finding posts stating it’s not possible. Although I came up with a simple solution which worked perfectly for me:
got a bigger SD (Sandisk 256Gb)
flashed HAOS
done a full backup of my current HA
replaced the SD
removed the external drive
restored the backup on the new installation on the new SD
and everything worked seamlessly.
Now I have plenty of space on data disk, backups still on NAS, Coral perfectly working again.
I guess the same approach can be taken with virtualized environment.
In my case, I’m running a Dell Optiplex 3050 Micro with an internal 128G SATA SSD drive internally that was starting to run low on space because of backups. I put a pretty slow 5400 RPM USB drive on and moved the data disk. That was a mistake. My boot time is now forever … many minutes.
So, I’ve installed an internal M.2 PCIe SSD and will be moving the data disk to that.
One problem that I encountered is the network interface name changed upon boot after installing the M.2 stick. The original interface was enp1s0 but changed to enp2s0 so HA would not come up.
Some research show the internal NIC uses PCI. I suppose a way to fix this would be to hook a USB gigabit NIC to the box, but I didn’t want to complicate it, and it would have changed the interface name anyway.
From CLI I was able to use the network update command to add the original IP address (just the IPv4 address, not the GW, etc) that was on enp1s0 onto enp2s0 and issues core restart. HA then came up.
Once back into HA I was able to finish setting the gateway and DNS addresses, and confirmed my NC remote connection worked as well and the cloud type integrations.
I’m in this same situation. I have a spare older NVMe drive I could use, but I’d have to connect it via USB (for now) and was thinking the “Move Data Disk” button would:
Copy everything over including the OS and configs.
Update my bootloader of my Pi.
Tell me to remove the microSD card when it completes and restarts.
There’s no documentation for this feature in Home Assistant itself, so it’s very vague. All I want is to have more data tracked for longer.
My understanding is “Move Data Disk” WONT copy over a boot loader, but with the prospect of upgrades from CM4 to CM5 modules, a new install of HAOS 14 will ignore eMMC and install both OS and data on SSD to make upgrades easier (e.g. just move the SSD over).
The change in HA OS 14:
My Yellow has the OS images on eMMC, and user data (move data disk) on the NVMe SSD. This suggests I’ll need to backup, swap CM4 → CM5, reinstall a new HAOS to the SSD, then restore (means you can save £10 on a CM5 Lite with no eMMC).
And don’t use the CM4 bolts, and apparently the USB-2 ports can’t be used on a Yellow for a CM5, so you need to install via the USB-C serial console or perhaps using a NVMe carrier on another machine.
I ended up making a backup and putting that on an NVMe drive imaged with Home Assistant.
The trick was writing the USB bootloader to a microSD and running that first. I waited some time and took it out, then it booted from the NVMe drive over USB.
That image is available in the Raspberry Pi imager app.
That way you probably aren’t running hybrid mode but booting completely from your NVMe disk, right? That’s not what the move data disk feature is made for - and there are good reasons to not use a SSD as boot device, considering the issues for many board users on almost every HA OS update.
@rwelsh09 so how long did the progress actually take? What is the size of your original/source disk (storage used)?
Note the initial HA OS install process has changed to use ONLY a NVMe drive for ALL of the both the OS and HA if both exist - this is apparently to make upgrades from a CM4 to a CM5 just moving the drive across.
What are the reasons? Saying “there are good reasons” is why I used an NVMe SSD as my boot drive. I couldn’t see anything wrong with it. I have Windows on those same drives.
Reasons to go NVMe:
Make upgrading from a Raspberry Pi 4 to 5 much easier as @FloatingBoater noted.
Faster boot times. With the number of updates Home Assistant releases, it happens more often than you think.
More reliable storage. While my 32GB microSD card was designed for longevity even when it’s been written to a bunch in security cameras, it’s not gonna be as good as an NVMe drive many times its size that wasn’t used much.
The ability to store stats much longer. It’s only 1.5 weeks by default, but I’d like at least 3 months. That’d also make it easier to debug issues like “when was this device last online?”.
I don’t think you understood how the move data disk feature actually works. With the hybrid mode, your points 1 + 3 + 4 are irrelevant. And for 2, boot times are valid for HA OS only as HA Core is stored on the data disk, not the boot disk.
So please just read and understand what this topic is about. It is definitely not about a migration to a full SSD/NVMe setup.
And fingers crossed for your next OS upgrades - as mentioned, you might want to have a look at the GitHub issues for HA OS (but using an internal NVMe without a third party external case you might be good).
I‘m really curious to hear how things turned out for @rwelsh09 .
TL;DR:
I found an xhci_hcd error linked to an incompatible SSD enclosure, I switched to a better SATA to USB and retried. Initially encountering a supervisor error, a reboot resolved it, and the system was successfully up and running 14 minutes after starting the process.
Thanks for your replies. My original data disk was 27GB of my 32GB SD card.
After leaving the system for 5+ hours I finally decided it was time to pull the plug. I connected a monitor to my raspberry pi and rebooted it. The system was unable to start and I eventually had to restore from a backup. But(!) using the monitor showed several errors, the most relevant was an xhci_hcd error which lead me down a path to discovering that my decision to save a few dollars on an SSD enclosure was not worth it. Apparently this does not play nice with RP4. So, I bought this and tried again this morning. With the monitor still connected I initiated the data transfer, this time the HA text said about 10 minutes. I stayed close, watching the monitor, and in less than 10 minutes the system was starting, things were looking promising! There was one small hiccup, I saw something about a supervisor error on setup and couldn’t connect to the system (on port 8123), but I was able to connect to the HA observer (on port 4357, something new I learnt during all this) so I decided a reboot might work and pulled the plug.
Then, in a few minutes, now 14 minutes after starting the move data disk, my system was up and running!
