If we believe this is what is causing the race here, we can try booting d-i with a kernel parameter 'scsi_mod.scan=sync' specified. (or i can rebuild d-i with such kernel cmdline built-in if required). And check if that helps to resolve this case.
I do wonder, if d-i should be taking the control of the scan itself, meaning, booting with scsi_mod.scan=none and doing `echo "- - -" > /sys/class/scsi_host/*/scan` at the appropriate stage of disk-detect.
Or if we do async scan, trigger a rescan at disk-detect stage. `echo 1 > /sys/class/scsi_device/device/rescan`
Will be checking the disk-detect / scsi code, to see if it does trigger scans, and if it correctly blocks on said scans to complete.
Two things.
SCSI_SCAN_ASYNC=y is set from xenial to bionic.
If we believe this is what is causing the race here, we can try booting d-i with a kernel parameter 'scsi_mod. scan=sync' specified. (or i can rebuild d-i with such kernel cmdline built-in if required). And check if that helps to resolve this case.
I do wonder, if d-i should be taking the control of the scan itself, meaning, booting with scsi_mod.scan=none and doing `echo "- - -" > /sys/class/ scsi_host/ */scan` at the appropriate stage of disk-detect.
Or if we do async scan, trigger a rescan at disk-detect stage. `echo 1 > /sys/class/ scsi_device/ device/ rescan`
Will be checking the disk-detect / scsi code, to see if it does trigger scans, and if it correctly blocks on said scans to complete.