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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1552539
Title:
Ubiquity Erase Disk and Install Fails to create Swap Space
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1552539/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
