I did run in a funny issue...
I tried to change the identification of the destination device of mirror_SD away from /dev/sdx to something more reliable, as it may not be sure that the sd-card reader that holds the destination SD-Card always receives the same sdx name... Obvious the Linux standard issue with drives mounted on USB.. Yes it maily does, if I only have one device attached it will work. If I keep my devices on the same port it also should keep consistent for every reboot, but it may fail already. If I for whatever reason reconfigured to boot from USB and have a SD-Card there and a target SD-Card in a second reader it becomes definitely strange, cause the system will boot from the one it finds first and view the other SD-Card as the backup... Ok in this case most probably it has booted from the device it identified as SDA and will name the other one SDB most probably... And maybe in this last case the solution I want to suggest here even will fail and using sda and sdb as the names to identify the targets most probably is the best praxis...
But let's go back to I boot from the internal card and want to copy it to the backupcard in a reader and I may have other drives attached iot have more space for persistence or whatever. In this case if it misidentifies the SD-Slot it may copy the internal SD Card to my nvme drive in a USB adaptor or whatever even worse in case of "raw" it will create a bootable image on the external NVME and use the backup sd as the storage place....
To prevent this, I came to the idea to not present /dev/sdx as the destination to the service but instead something more reliable.. /dev/disk/by-partuuid/something is not very helpful as we intentionally modify the IDs in the rawcopy to prevent boot confusion and have a fully bootable SD-Card afterwards... But I came to /dev/disk/by-id/ where I can identify my SD-Card Reader by it's name serial and the slot number the card is mounted to in it... Perfect identification... But if I pass this device to mirror_SD in "raw" mode it will work erfectly but in "sync" mode
if [[ -n "$INTERACTIVE" ]]; then
select_blkdev "^-sd" "select partition" "Select the partition to copy the internal SD card data to"
# shellcheck disable=SC2154
dest="/dev/$retval"
else
dest="${dest}2"
fi
this will fail, as the name of the second partition then is -part2 and not 2
If we would use a NVME for example as the destination it would have to add p2 for partition 2...
So i suggest to add a identification what kind of drive was passed as a device to identify the correct way to get the name of the second partition... like:
if [[ "$dest" == "/dev/nvme"* ]]; then
dest="${dest}p2"
elif [[ "$dest" == "/dev/disk/by-id/"* ]]; then
dest="${dest}-part2"
else
dest="${dest}2"
fi
istead of the simple dest="${dest}2
A more sophisticed solution would be to ask in the very beginning, when dest is set, to test if the destination presented is a real device like /dev/sdx or if it is a link that links on some device and the deref the link to the device... This may would be even more elegant :-)
this would look like this after the local defintions:
dest=$(readlink -f "$dest")
# 2. Sicherheits-Check: Ist das Ergebnis ein Block-Device?
if [[ ! -b "$dest" ]]; then
echo "FEHLER: $dest ist kein gültiges Block-Gerät!"
return 1
fi
# 3. Jetzt die Partitions-Logik (da dest nun immer /dev/sdX oder /dev/nvmeX ist)
if [[ "$dest" == /dev/sd[a-z]* ]]; then
# Klassisch: sda, sdb, sdc... -> sda2, sdb2
dest="${dest}2"
else
# Modern/Virtuell: nvme0n1, mmcblk0, loop0 -> nvme0n1p2
dest="${dest}p2"
fi
testing for being a block device we may can leave away.. If someone passes something that is not a blockdevice it will crash anyways or do stupidities (or something that is wanted by the user...
I did run in a funny issue...
I tried to change the identification of the destination device of mirror_SD away from /dev/sdx to something more reliable, as it may not be sure that the sd-card reader that holds the destination SD-Card always receives the same sdx name... Obvious the Linux standard issue with drives mounted on USB.. Yes it maily does, if I only have one device attached it will work. If I keep my devices on the same port it also should keep consistent for every reboot, but it may fail already. If I for whatever reason reconfigured to boot from USB and have a SD-Card there and a target SD-Card in a second reader it becomes definitely strange, cause the system will boot from the one it finds first and view the other SD-Card as the backup... Ok in this case most probably it has booted from the device it identified as SDA and will name the other one SDB most probably... And maybe in this last case the solution I want to suggest here even will fail and using sda and sdb as the names to identify the targets most probably is the best praxis...
But let's go back to I boot from the internal card and want to copy it to the backupcard in a reader and I may have other drives attached iot have more space for persistence or whatever. In this case if it misidentifies the SD-Slot it may copy the internal SD Card to my nvme drive in a USB adaptor or whatever even worse in case of "raw" it will create a bootable image on the external NVME and use the backup sd as the storage place....
To prevent this, I came to the idea to not present /dev/sdx as the destination to the service but instead something more reliable.. /dev/disk/by-partuuid/something is not very helpful as we intentionally modify the IDs in the rawcopy to prevent boot confusion and have a fully bootable SD-Card afterwards... But I came to /dev/disk/by-id/ where I can identify my SD-Card Reader by it's name serial and the slot number the card is mounted to in it... Perfect identification... But if I pass this device to mirror_SD in "raw" mode it will work erfectly but in "sync" mode
this will fail, as the name of the second partition then is -part2 and not 2
If we would use a NVME for example as the destination it would have to add p2 for partition 2...
So i suggest to add a identification what kind of drive was passed as a device to identify the correct way to get the name of the second partition... like:
istead of the simple
dest="${dest}2A more sophisticed solution would be to ask in the very beginning, when dest is set, to test if the destination presented is a real device like /dev/sdx or if it is a link that links on some device and the deref the link to the device... This may would be even more elegant :-)
this would look like this after the local defintions:
testing for being a block device we may can leave away.. If someone passes something that is not a blockdevice it will crash anyways or do stupidities (or something that is wanted by the user...