Skip to content

identifying the correct device for mirror_SD() in "diff" mode #2132

@MarkusThur

Description

@MarkusThur

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...

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions