Comment 17 for bug 48517

For me, you can either apply the patch or do something similar.

There is a larger problem here and this would be a THIRD proposed fix (the first two are 1. a patch, or 2. something that would disable or warn on creating a swapfile in the first place)

Filesystems that refuse to umount - for any reason - should abort the shutdown or go into single-user mode. Individuals would then have an indication or could take action manually to fix things - once for the instance, then to go out and find the patch if it is systemic.

In this case, you have something known to cause a condition which can result in data loss which is serious.

Secondly, to be robust, swapoff and umount -a could be done repeatedly until nothing happened on both (followed up by mount ... -o ro for anything left). Or umount needs a "swapoff to" option.

Consider the case of a loopback disk image on an external USB drive. That might also stick.

I can come up with scripts or utilities that would accomplish this (basically the above patch extended to the general case plus a shutdown interruption if I can manage it).

I'm only going to write them if they would actually make it into the distribution. I know enough to fix my own system but I'm not going to bother coming up with a very clean and well tested solution for one or two computers while everyone else loses data.