Running Home Assistant OS, I have a use case where I’d like to have the /data partition split across two separate drives. Specifically an NVMe drive (which also contains HassOS partitions) and an SSD (or large HDD). I’d like to keep most of my add-ons on the NVMe but would like to use the second drive for add-ons such as InfluxDB and motioneye for instance. As such, I’d rather not use datactl to move everything to the 2nd drive. My intent is to mount the 2nd drive to /mnt/data/supervisor/share/data2 for instance such that the volume will be visible to Docker containers. I’d like to stick with HassOS rather than migrating to Debian and HASupervised and this is the one roadblock I haven’t found a way around yet.
My suggestion / request:
The overlay partition stores a bit of OS specific configurations that are read-write and isolated (+ persistent) during OS updates. ex: timesyncd, hostname, authorized_keys modules and udev rules. From what I understand, adding a etc-fstab.mount config file in /user/lib/systemd/system as part of buildroot a user could modify fstab in the overlay partition similar to the above examples. Short of that, my only other options are to unsquash the root image, edit fstab and re-squash, or fork the operating-system repo and add the mount file. Seems fairly low risk to me, fstab would remain default (/empty) unless an experienced user adds their own within the overlay partition.
As an aside, there are a number of other threads looking for similar functionality or trying other round-about means of adding persistent mount points at the OS layer.