@Floppyrub Have you updated to dev-branch? You are free to run any task as a debug, initially to validate things are working as expected before things get too far and do any actual “data loss activities”.
The latest FOS code is the default pull in:
if it helps you to see how it functions please review the getHardDisk funciton starts at line 1501 of the Code link I provided you:
If it helps to see the funciton as a whole:
getHardDisk() {
hd=""
disks=""
# Get valid devices (filter out 0B disks) once, sort lexicographically for stable name order
local devs
devs=$(lsblk -dpno KNAME,SIZE -I 3,8,9,179,202,253,259 | awk '$2 != "0B" { print $1 }' | sort -u)
if [[ -n $fdrive ]]; then
local found_match=0
for spec in ${fdrive//,/ }; do
local spec_resolved spec_norm spec_normalized matched
spec_resolved=$(resolve_path "$spec")
spec_norm=$(normalize "$spec_resolved")
spec_normalized=$(normalize "$spec")
matched=0
for dev in $devs; do
local size uuid serial wwn
size=$(blockdev --getsize64 "$dev" | normalize)
uuid=$(blkid -s UUID -o value "$dev" 2>/dev/null | normalize)
read -r serial wwn <<< "$(lsblk -pdno SERIAL,WWN "$dev" 2>/dev/null | normalize)"
[[ -n $isdebug ]] && {
echo "Comparing spec='$spec' (resolved: '$spec_resolved') with dev=$dev"
echo " size=$size serial=$serial wwn=$wwn uuid=$uuid"
}
if [[ "x$spec_resolved" == "x$dev" || \
"x$spec_normalized" == "x$size" || \
"x$spec_normalized" == "x$wwn" || \
"x$spec_normalized" == "x$serial" || \
"x$spec_normalized" == "x$uuid" ]]; then
[[ -n $isdebug ]] && echo "Matched spec '$spec' to device '$dev' (size=$size, serial=$serial, wwn=$wwn, uuid=$uuid)"
matched=1
found_match=1
disks="$disks $dev"
# remove matched dev from the pool
devs=${devs// $dev/}
break
fi
done
[[ $matched -eq 0 ]] && echo "WARNING: Drive spec '$spec' does not match any available device." >&2
done
[[ $found_match -eq 0 ]] && handleError "Fatal: No valid drives found for 'Host Primary Disk'='$fdrive'."
disks=$(echo "$disks $devs" | xargs) # add unmatched devices for completeness
elif [[ -r ${imagePath}/d1.size && -r ${imagePath}/d2.size ]]; then
# Multi-disk image: keep stable name order
disks="$devs"
else
if [[ -n $largesize ]]; then
# Auto-select largest available drive
hd=$(
for d in $devs; do
echo "$(blockdev --getsize64 "$d") $d"
done | sort -k1,1nr -k2,2 | head -1 | cut -d' ' -f2
)
else
for d in $devs; do
hd="$d"
break
done
fi
[[ -z $hd ]] && handleError "Could not determine a suitable disk automatically."
disks="$hd"
fi
# Set primary hard disk
hd=$(awk '{print $1}' <<< "$disks")
}
Ultimately, the part I’m worried about is the sort -u as that will lexographically sort the drives regardless of how lsblk returns (which is the part I was stating earlier, there’s no true OS load method as PCI tends to load faster than serial -> parallel:
I have adjusted the code slightly and am rebuilding with that adjustment in the beginning of the function where we get all available drives:
devs=$(lsblk -dpno KNAME,SIZE -I 3,8,9,179,202,253,259 | awk '$2 != "0B" { print $1 }' | sort -u)
Instead of sort -u I’m going to try:
devs=$(lsblk -dpno KNAME,SIZE -I 3,8,9,179,202,253,259 | awk '$2 != "0B" && !seen[$1]++ { print $1 }')
Basically that will get only unique drive entries but keep in in the order of which lsblk sees the drives.
I doubt this will “fix” the issue you’re seeing, but it’s worth noting.
I still need to clarify, however, that this isn’t the coding fault. There’s 0 guaranteed method to ensure we always get the right drive, because in newer systems what is labelled the drive this cycle, can easily be labelled something else the next cycle.
hdd will always load in hda, hdb, hdc, hdd - this is about the only “guarantee” we can give.
Serial (USB, SATA, etc…) SATA would load (generally) in the channel order appropriately, but USB might or might not load before: so Something in the USB might take /dev/sda on this boot, and on the next, the channel 0 controller might take /dev/sda.
NVME, what’s nvme0n1 on this cycle, might become nvme1n1 on the next.
This is why the function you see is “best guess” at best.
I am wanting to make this seemingly more stable on your side of things, for sure, but just want to be clear on what you’re seeing, there’s never any potential we can guarantee we got the “right” thing.
thanks for testing and letting us all know!