Bug#558686: Partition manager fails to update kernel partition table
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.
Reply to: