Moved rootfs to external SSD - System works - Home assistant fails

[sdomotica]

RPI3B
Last Dietpi
The system works fine after rootfs moved to SSD, but the homeassistant mnt folder is missing.
I tried to reinstall HA. sudo dietpi-software reinstall 157
and this is the error

Downloading Python-3.8.0.tar.xz...
-> https://www.python.org/ftp/python/3.8.0/Python-3.8.0.tar.xz
error: failed to download Python-3.8.0.tar.xz

BUILD FAILED (Raspbian GNU/Linux 9 using python-build 20180424)

pyenv: version `3.8.0' not installed
WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.
Defaulting to user installation because normal site-packages is not writeable
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Requirement already up-to-date: pip in ./.local/lib/python3.5/site-packages (20.1.1)
Requirement already up-to-date: wheel in ./.local/lib/python3.5/site-packages (0.34.2)
WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.
Defaulting to user installation because normal site-packages is not writeable
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Collecting homeassistant
^CERROR: Operation cancelled by user

Bye
Sandro

[MichaIng]

Many thanks for your report.

Can you please check whether /mnt/dietpi_userdata exists as symlink to the actual dietpi_userdata location? I remember there was an issue that this was not transferred with the rootfs. If it is missing, re-create it:

ln -s /mnt/<yourUserdataMountpoint>/dietpi_userdata /mnt/dietpi_userdata

[Joulinar]

Hi,

I guess this is the issue

Downloading Python-3.8.0.tar.xz...
-> https://www.python.org/ftp/python/3.8.0/Python-3.8.0.tar.xz
error: failed to download Python-3.8.0.tar.xz

@MichaIng
Pls correct me if I'm wrong but if your transfer RootFS, the external device will be mounted as / Means the old /mnt/dietpi_userdata directory is not available because it would be located on the original SD card RootFS partition that is not mounted anymore. And yes this point is still open to copy /mnt/dietpi_userdata correctly 😜

[sdomotica]

I have access, and Node-red data are in /mnt/ I think as @Joulinar told is the installation script that couldn't access to this or point to /

Bye
Sandro

[Joulinar]

hmm there is as well an error message above on your picture. Let's check which device you have on your system

lsblk -o name,label,size,ro,type,mountpoint,partuuid,uuid

[MichaIng]

@Joulinar

Pls correct me if I'm wrong but if your transfer RootFS, the external device will be mounted as / Means the old /mnt/dietpi_userdata directory is not available because it would be located on the original SD card RootFS partition that is not mounted anymore. And yes this point is still open to copy /mnt/dietpi_userdata correctly 😜

Nope, the external target drive is mounted to a temporary mount point to transfer data. /etc/fstab (and /boot/cmdline.txt or /boot/boot.ini) is edited to mount the new RootFS partition to / on reboot. So the old partitions are perfectly accessible until reboot. I think for now I'll add manual creation of /mnt/dietpi_userdata symlink or directory until I find more time for a clean rework.

[sdomotica]

@Joulinar @MichaIng please wait a while. I think that the problem is mine curl Openssl error.
Let me solve before it
Bye
Sandro

[sdomotica]

Hi guys, sorry for keep your time in this mine issue.
The error regarding curl and Openssl don't permit to the script to download pyrhon
-> https://www.python.org/ftp/python/3.8.0/Python-3.8.0.tar.xz
and consegently to install pyvenn.

The only issue is that after the moving all the data in /mnt/dietpi_userdata/homeassistant are losed but, just reinstall home assistant in the new situation and all it's ok.
Bye
Sandr

[Joulinar]

pls can you copy output of lsblk -o name,label,size,ro,type,mountpoint,partuuid,uuid
I would like to see what is on the old partition. Maybe thinks are not copied correctly

[sdomotica]

pi@sdomotica:~$ lsblk -o name,label,size,ro,type,mountpoint,partuuid,uuid
NAME        LABEL   SIZE RO TYPE MOUNTPOINT PARTUUID                             UUID
sdb               119.2G  0 disk
└─sdb1            119.2G  0 part /          cf2f71b9-9861-4b6d-be88-4b02d7322b26 7f899e6b-4bd3-412e-805d-47ce6148d16d
mmcblk0             7.6G  0 disk
├─mmcblk0p1        41.8M  0 part /boot      c65b01ee-01                          7868-D0E0
└─mmcblk0p2         7.5G  0 part            c65b01ee-02                          10970d7a-98db-4f60-9059-729014adbb6c

[Joulinar]

can you go to drive manager and mount mmcblk0p2 to a temp place like /mnt/temp

[sdomotica]

pi@sdomotica:~$ lsblk -o name,label,size,ro,type,mountpoint,partuuid,uuid
NAME        LABEL   SIZE RO TYPE MOUNTPOINT PARTUUID                             UUID
sdb               119.2G  0 disk
└─sdb1            119.2G  0 part /          cf2f71b9-9861-4b6d-be88-4b02d7322b26 7f899e6b-4bd3-412e-805d-47ce6148d16d
mmcblk0             7.6G  0 disk
├─mmcblk0p1        41.8M  0 part /boot      c65b01ee-01                          7868-D0E0
└─mmcblk0p2         7.5G  0 part /mnt/temp  c65b01ee-02                          10970d7a-98db-4f60-9059-729014adbb6c

[sdomotica]

now I can see old data of dietp_userdata

[Joulinar]

yeah, might be not copied correctly. Do you see the old homeassistant folder with all the data in it. Or is it empty as well?

@MichaIng
Probably still this behaviour? Klick Forum

[sdomotica]

the mounted partition has all the files

[MichaIng]

Okay I finally implemented the long-term solution: a9d2ea3
This assures that all content in /mnt, including symlinks and the mountpoint directories (without content) are copied to the target drive, excluding the content of mounts of course. This is a much better solution, which excludes ALL mounts content instead of only the ones we know and hardcode inside. Also it assures that mountpoint directories are copied with the permissions they have on the parent file system instead of the permissions which are given by the mount options. rsync actually has the option "-x" to prevent crossing file systems automatically, but it copies mountpoint dir meta data (persmissions) according to the mount instead of how they are set on the parent fs. This is actually unexpected 🤔 ...

So basically with this one has a 100% 1:1 copy for the underlying root file system data and meta data.

Many thanks for reminding me about this quite important topic guys 👍.

Changelog: 4efb301