On Wed Mar 18, 2026 at 9:22 AM CET, Peter Korsgaard wrote: > There is already a wait_for_device_probe() just above the loop, so what > does this fix exactly? Do we need both?
The mmc_rescan() function (that probes the MMC device) is called in a delayed work. When the issue occurs, MMC device has not started probing yet (bacause the work has not been scheduled yet), so the first wait_for_device_probe() does not wait for it. That's also the reason why this waitfor parameter exists, otherwise the first wait_for_device_probe would be enough to wait for the MMC device if probing wasn't deleayed. The second call ensures that this delayed probing, which includes scaning avaialble partitions, is done. That's also what is done for rootwait=, there is a first call to wait_for_device_probe() in prepare_namespace(), then the busy while loop in wait_for_root() still wait for probing to be done. > Interesting enough, I have never encountered this issue myself. I do use > a partition identifier (dm-mod.waitfor="PARTLABEL=root-a") which > presumably sidetracks the /dev/mmcblk0 available, but partition table > not yet parsed issue. Yes, the issue occurs only when partition scaning has not finished yet.
