This does look super easy to implement now, there are even options for the size of swap that a user wants to implement. In the partition.conf module we would need to change neverCreateSwap: true to neverCreateSwap: false and then add:

userSwapChoices:
    - none      # Create no swap, use no swap
    - reuse     # Re-use existing swap, but don't create any
    - small     # Up to 4GB
    - suspend # At least main memory size

I tested this in Vbox from a daily iso and it seems to work as advertised with the exception of reuse, I wasn't able to see that as an option but perhaps I was doing something wrong. Any insight on this @tsimonq2?

I thought there was also the option of a swapfile, but it was unsupported. If we do swap, that's how we do it.

Another thing to test would be to see how Ubiquity does it in certain contexts. For example, on an SSD (bare metal) does it still do an install with swap? What about encrypted with BIOS?

In T22#334, @tsimonq2 wrote:

I thought there was also the option of a swapfile, but it was unsupported. If we do swap, that's how we do it.

There is but I didn't test that, it said it was unsupported :P I will give it a try though.

Another thing to test would be to see how Ubiquity does it in certain contexts. For example, on an SSD (bare metal) does it still do an install with swap?

I can check on that.

What about encrypted with BIOS?

We have to get that working again :(

In T22#335, @kc2bez wrote:

In T22#334, @tsimonq2 wrote:

I thought there was also the option of a swapfile, but it was unsupported. If we do swap, that's how we do it.

There is but I didn't test that, it said it was unsupported :P I will give it a try though.

"Unsupported" means nothing if it's fine after running it through Many QA tests. 😉

Another thing to test would be to see how Ubiquity does it in certain contexts. For example, on an SSD (bare metal) does it still do an install with swap?

I can check on that.

Thanks.

What about encrypted with BIOS?

We have to get that working again :(

I thought we had this working, is it now also broken with BIOS? :/

In T22#336, @tsimonq2 wrote:

What about encrypted with BIOS?

We have to get that working again :(

I thought we had this working, is it now also broken with BIOS? :/

Yeah, I don't know what happened there. I know it was working, I don't know when it stopped. I will make a task.

Thanks.

In T22#335, @kc2bez wrote:

In T22#334, @tsimonq2 wrote:

I thought there was also the option of a swapfile, but it was unsupported. If we do swap, that's how we do it.

There is but I didn't test that, it said it was unsupported :P I will give it a try though.

This is going to take some more code spelunking. Adding - file # To swap file instead of partition (unsupported right now) didn't get presented in the dropdown.

In T22#334, @tsimonq2 wrote:

Another thing to test would be to see how Ubiquity does it in certain contexts. For example, on an SSD (bare metal) does it still do an install with swap?

Ubiquity (Disco Dingo Beta Ubuntu Budgie) on a bare metal created a small (2G) swap file for my laptop with a 120G SSD. Laptop has 4G of RAM.

It seems there's an upstream issue specifically about swapfiles.

Isn't this as easy as adding an entry to etc/fstab ? Does this need to be done by calamares? We could create a post install script that do that.

If you're going to create a swap *file* then I'd strongly recommend it be the *first* thing done after the root file-system has been created - before any other files have been written to the file-system.

Reasons?

1. It will assist performance to guarantee the swap-file is a contiguous allocation of sectors
2. Being at the start of the file-system should avoid problems much later if the operator decides to resize (shrink) the file-system for some reason (resize involves moving blocks closer to the beginning of the file-system and filling gaps, resulting in a non-contiguous range)
3. Easier to reason about in the case of data recovery

Consideration also needs to be given to hibernation images in a swap file and the effect of LUKS encryption *especially* if the operator has a non-standard partition/file-system layout. (Maybe uses the Something Else option of the installer).

E.g. I always have separate LUKS-encrypted partitions for /boot/ and an LVM OS VG containing root-fs, /var/, /usr/local/, another data VG for /home/ and so on.

What about those building thin-ish clients and mounting file-systems over NFS - does the installer need to take account of that in deciding whether to use swap file or partition?

It could end up with a hard-to-diagnose broken boot as with the recent missing initrd.img bug.

Looks like btrfs just got swapfile support, perhaps making this more of a possibility upstream.

@Tj a question in regards to your special consideration: how does Ubuntu/ubiquity deal with this?

No movement upstream so bumping this.

This change is in proposed now for new Hirsute installs.