Back in 2017 some code was added to ignore failures tearing down loop devices. But debugging that growpart race on cloud images made me (very) aware of a potential cause of the race: doing something like zerofree on a device will cause udev scripts to run, and if they are still running by the time kpartx is called, you would expect the kpartx -d to fail. So lets see if a udevadm settle helps, and get rid of one of the "sometimes this fails but we don't know why" comments...arbitrary-model-names
parent
8f76e539b1
commit
2498aadebb
Loading…
Reference in new issue