enyc 5 years ago

Confirmed this same issue happens exactly the same in Ubuntu-MATE-18.04-64bit, as you suspected.



Failing to find bug-report or workaround for this specific issue, though there are many related issues.

https://bugs.launchpad.net/ubuntu/+source/ubiquity

... shows a large number of bugs, many old and quite likely many not relevant any more...

I may report a yet-another new bug upstream..  Not sure if worth me also suggesting many of the bugs get closed, or what...

clem 5 years ago

I think that's an upstream issue. Can you check if this happens in 18.04 as well? Any bug reports or known workarounds upstream on this? We could mention something in the relnotes.

enyc 5 years ago

I'm still having this infuriating bug with custom-partitioning-install, I'm afraid ;-(.

It keeps auto-mounting-swap-partitions even if you want to create a (separate) encrypted system via the custom-partitioning...

E.g. you have a disk with and existing older linux-system with a swap-partition /dev/sda5 (e.g.a guest system, mini recovery-system, or something, kept separate from 'encrypted' mint-19 system you want to install).

Before starting ubiquity, you "swapoff -a" and double-check "cat /proc/swaps" is now empty.

You then open installer, go to custom-partitioning ("something else"), try to create a new /boot (ext4, format yes, /boot) and you try to format the crypto-partition, at which point things go wrong...

You set parititon to be formatted as crypto, set password for it... And ubiquity AUTOMATICALLY remounts the' 'other' /dev/sda5  linux-swap  and you get papup screen  "Unsafe swap space detected (as superuser)".

[...]  "Please disable the swap space (e.g. by running swapoff)" ...etc...   Its' clearly "auto-re-mounting" the swap at a really-inconvenient moment...

EVEN if you have a "(while true; do swapoff -a; sleep 0.5; done)" running in a root terminal, I *still* find that this happens.  The only way I 'fixed' it is by temporarilaly zeroing out the swap-headers in the swap-partition then restoring it later (dd magic) to get it back as-before.   Clearly something in ubiquity or some kind of "re-scan-partitions" magic it calls-upon (elsewhere in live-systmem) is clearly "auto-mounting" linux-swap partitions.

This auto-mounting-swap can be problematic when doing partitioning of course, you can find you are unable to delete/resize another partition or (worse still) swap is still mounted when you do manual stuff with repartitiosing/filesystems and mayhem-ensues.