On Monday 30 November 2009, Frans Pop wrote: > I *can* reproduce the error by manually activating swap on /dev/hda5 > from a debug shell just before starting partman [...] [...] > Some wild theories: > 1) this is a libparted bug; somehow it manages to confuse itself about > the state of the disk (busy or not busy) > 2) this is a kernel bug; somehow it gives incorrect info to libparted > (possibly related to command queueing?) > 3) for some reason swap *was* active in your test (but WHY?); partman > disables swap just before committing changes, but this is not 100% > completed before changes really do get committed > 4) something other than swap really is keeping the disk busy > For now my guess is either 1) or 3).
If I snapshot my test system in Virtualbox just before the changes are committed to disk, I can reproduce the failure in about 50% of cases after restoring the snapshot. I've verified that the swapoff does happen just before changes are committed and also that it happens correctly [1]. I tried if adding a 'sleep 1' [2] after the swapoff (in disable_swap() in the base.sh library) helps, but it does not. IMO that makes 3) unlikely, but possibly makes 2) more likely. Even if it is related to command queueing, the bug is more likely to be in libparted than the kernel; really, really wild guess: maybe libparted should "flush" the command queue before trying to commit changes? The fact that the changes *are* correctly committed to disk makes this seem like a reasonable theory. Additional info: I was running the amd64 installer (daily build) in Virtualbox; disk driver module is piix. [1] I was able to reproduce with a 'cat /proc/swaps' between the swapoff and commit, which returned empty. [2] With a 'sleep 2' I was not able to reproduce, but adding that in the partman scripts does not seem like the correct solution to me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
