ubiquity must NOT format a valid SWAP partition on manual partitioning

[Etienne URBAH]

On manual partitioning, ubiquity systematically formats the SWAP partition, even if this SWAP partition is perfectly valid.

For the SWAP partition, this unnecessary formatting modifies its filesystem UUID and blanks its filesystem LABEL.

This BREAKS COMPATIBILITY with other distribution(s) installed on the same machine, whose '/etc/fstab' reference the SWAP partition by UUID or LABEL.

If fact, ubiquity must NOT format a valid SWAP partition.

This issue is :
- similar to the 3rd item (left uncorrected) of bug #83166
- related to bug #533618

[Etienne URBAH (eurbah)]

On manual partitioning, ubiquity systematically formats the SWAP partition, even if this SWAP partition is perfectly valid.

I can suggest 2 workarounds for keeping compatibility with other distribution(s) installed on the same machine, whose '/etc/fstab' reference the SWAP partition.

1) Where possible, use GPT (GUID Partition Table) on the mass storage unit containing the SWAP partition, and reference the SWAP partition by its PARTLABEL (which ubiquity does NOT modify).

2) After completion of ubiquity, but before reboot, use the attached BASH script, which :
    - sets the filesystem label of the SWAP partition to a value beginning by SWAP,
    - sets the filesystem label of the distribution root partition to a value beginning by the distribution name,
    - converts the ugly UUID references generated by ubiquity inside '/etc/fstab' into human-readable LABEL references

In the hope that these workaround suggestions may be helpful.

[Phillip Susi (psusi)]

It has code to preserve the UUID, but not the LABEL.

[Steve Langasek (vorlon)]

partman-basicfilesystems is obsolete as a source package; reassigning to ubiquity.

[Dan Bungert (dbungert)]

It is possible to re-partition the disk and preserve the partition label. On Subiquity installers this will do the right thing, we preserve the partition label unless we've been told not to.

If an interested community member wants to address this that would be a useful improvement for Ubiquity installers, and for Subiquity installers this should be resolved.