Comment 23 for bug 1552539

Martin Pitt (pitti) wrote :

So according to the traces, these are the commands that ubiquity calls:

  swapoff /dev/sda3
  grep "^/dev/sda3 " /proc/swaps
  log-output -t partman --pass-stdout mkswap /dev/sda3

and the latter fails with

  open("/dev/sda3", O_RDONLY|O_EXCL|O_CLOEXEC) = -1 EBUSY (Device or resource busy

I tried to reproduce this with just

  swapoff /dev/sda3; grep "^/dev/sda3 " /proc/swaps; sleep 0.5; mkswap /dev/sda3; swapon /dev/sda3

for varying values in the sleep (or no sleep at all), so far not successfully yet. I also don't believe that this is generally broken as it is quite hard to reproduce. Slower machines/hard disks do seem to help, though.

Another theory is that something else has the swap device open; ubiquity (or some called programs) open it quite a lot, things like blkid; but mkswap works fine while the device is opened read-only (tail -f /dev/sda3) or even write-only (dd of=/dev/sda3) and I also let blkid race against mkswap:

    while blkid -p /dev/sda3; do true; done # in one shell
    while mkswap /dev/sda3; do true; done # in another

on Dave's machine, and all of these work.

I also put systemd into debug mode (systemd-analyze set-log-level debug) and watched journalctl -f to verify that there is no automatic activation of the new swap partition after mkswap. It just tracks swapoff and swapon via the uevents.

Thus so far I'm none the wiser yet.