I've read that you need to put the swap partition on HDD rather than SSD.

My questions are the following:

• When and how is the "checking" done by the distribution (or something else) to find its Swap partition?


• Does it happen during boot?


• It just checks all available disks and searches for a partition with 'swap' flag?


• What happens if there are several partitions like that?


• Also, how many swap partitions do I need to have if I run, for example, two different distributions on the same disk, let's say Fedora and Ubuntu?

Statically configured swap space (the type that pretty much every distribution uses) is configured in /etc/fstab just like filesystems are.

A typical entry looks something like:

UUID=21618415-7989-46aa-8e49-881efa488132 none swap sw 0 0

You may also see either discard or nofail specified in the flags field (the fourth field). Every such line corresponds to one swap area (it doesn't have to be a partition, you can have swap files, or even entire swap disks).

In some really specific cases you might instead have dynamically configured swap space, although this is rather rare because it can cause problematic behavior relating to memory management. In this case, the configuration is handled entirely by a userspace component that creates and enables swap files as needed at run time.

As far as how many you need, that's a complicated question to answer, but the number of different Linux distributions you plan to run has zero impact on this unless you want to be able to run one distribution while you have another in hibernation (and you probably don't want to do this, as it's a really easy way to screw up your system).

When you go to run the installer for almost any major distribution (including Fedora, OpenSUSE, Linux Mint, Debian, and Ubuntu), it will detect any existing swap partitions on the system, and add those to the configuration for the distribution you're installing (except possibly if you select manual partitioning), and in most cases this will result in the system being configured in a sensible manner.

Even aside from that, I would personally suggest avoiding having multiple swap partitions unless you're talking about a server system with lots of disks, and even then you really need to know what you're doing to get set up so that it performs well.

let's say Fedora and Ubuntu?

… both of which are nowadays systemd operating systems.

What happens in systemd operating systems

the native mechanism

Systemd employs various kinds of units. .mount unit files instruct it to mount volumes. .swap unit files instruct it to tell the kernel about swap partitions. (.service unit files instruct it how to run services. And so on.) These are the native systemd mechanisms. To enact them, systemd itself forks off child processes that make the relevant system calls.

If you use the systemctl command (with --all) on such a systemd operating system, it will tell you about the loaded .swap units. For example:

dev-disk-byx2dpartuuid-40549710x2d05.swap loaded active active /dev/disk/by-partuuid/40549710-05
dev-disk-byx2duuid-1bb589e8x2d929fx2d4041x2d81f4x2dff2b339b4e2a.swap loaded active active /dev/disk/by-uuid/1bb589e8-929f-4041-81f4-ff2b339b4e2a
dev-sda5.swap loaded active active /dev/sda5

It will also tell you about the .mount units.

A system administrator can actually write such .swap unit files by hand, just as xe can write .service, .socket, and other unit files by hand. systemd itself just looks for unit files in the filesystem. They are its native mechanism.

One can even get systemd to show you what is in these unit files and where in the filesystem they can be found:

$ systemctl cat dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a.swap 
# /run/systemd/generator/dev-disk-byx2duuid-1bb589e8x2d929fx2d4041x2d81f4x2dff2b339b4e2a.swap
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)

[Swap]
What=/dev/disk/by-uuid/1bb589e8-929f-4041-81f4-ff2b339b4e2a
Options=sw
$ 

automatically generated unit files

One can write them by hand. Usually however such .mount and .swap unit files are automatically generated by programs known as generators. Two such generators are systemd-fstab-generator and systemd-gpt-auto-generator. They both run early in the bootstrap process and in response to a systemctl daemon-reload command, and (as you can see above) they generate a whole load of unit files into an undocumented subdirectory in /run/systemd/. systemd itself just uses those generated unit files.

The former generator reads /etc/fstab, recognizing several systemd extensions to that file format. As I pointed out in an answer comment, traditionally swap partitions have the mount type of sw and that is how one will find that other operating systems recognise swap records in this table. But Linux softwares have taken the alternative tack of recognizing the VFS type instead, looking for swap as the VFS type. systemd-fstab-generator is no exception here, and that is how it interprets /etc/fstab when converting it into the native mechanisms.

The latter generator processes the EFI partition table that is on the same disc that holds the EFI System Partition, looking for EFI partition table entries that have various well-known partition type GUIDs. One of those GUIDs is the conventional GUID assigned to Linux swap partitions; and if systemd-gpt-auto-generator finds a partition with that GUID (that satisfies the criteria given in the systemd doco) it will make a .swap unit for it; no /etc/fstab involved at all.

Of course, this process has lots of side-effects. For example, because /etc/fstab has no primary key to the table, records can have duplicate "spec" and "file" (i.e. "what" and "where") fields. In the native systemd mechanism, though, the "file" (i.e. "where") field is a unique key for .mount units, embedded into the unit names. No two .mount units can share it. For .swap units the "spec" (i.e. "what") field is the unique key for units. No two .swap units can share that. So not all records in /etc/fstab are necessarily convertible to the native mechanisms and will work, especially if people do things like list the same mount point for two different purposes or list the same swap partition in two different ways.

Similarly, because it has translated /etc/fstab into the native mechanism and systemd's native mechanism has other ways of activating units, the behaviour is subtly different to that of non-systemd operating systems. A .mount unit will, by default, be automatically activated by systemd-udevd, even after bootstrap, in response to the appearance of the mounted storage device. Or it can be listed as a Wants= or Requires= of some .service or .socket unit, meaning that it will be (re-)activated when they are. There is even RequiresMountsFor=.

installer programs and the systemd way

Traditionally, operating system installer programs, and the systemd administrator afterwards reconfiguring the system, have written sw entries to /etc/fstab. And that is how the native .mount and .swap units end up being auto-generated. The install/configuration utility "knows" where the swap file was put, because in its user interface the system administrator made some sort of choice, and writes an /etc/fstab to match. Sometimes that choice is I need you to make me a swap partition as part of installation.; sometimes it is Just use the swap partition that you have found already on the disc. (installers looking at the partition types, too).

But the systemd people have this idea of operating systems that auto configure themselves from a largely empty /etc tree, so-called stateless systems, and that is what mechanisms like the generator that reads the EFI partition table are all about. In the systemd people's plan, there is no /etc/fstab, and indeed is no persistent configuration data under /etc at all, and all of this stuff is deduced from the contents of the partition table on disc, at every bootstrap and at every systemctl daemon-reload. They are nowadays promoting operating system installer programs than do not write an /etc/fstab.

In the traditional scheme, of course you can indeed have each operating system have its own private swap partition, and not have them touch one another's swap partitions. And indeed if you are using hibernate to disc via a swap partition and expecting to be able to multi-boot to another operating system whilst hibernated (which is a very bad idea because it is very easy to cause filesystem corruption this way) that will be necessary.

In the systemd scheme, even if the operating system is not yet as the systemd people envisage it and "stateless", the aforementioned generators run; and thus all swap partitions (on the ESP/root disc) with the requisite partition type are automatically employed by all systemd operating systems. Since they will be sharing all automatically discovered swap partitions, one really does not need to create one swap partition per installed operating system.

Further reading

• https://unix.stackexchange.com/a/332797/5132


• https://unix.stackexchange.com/a/233581/5132


• Lennart Poettering et al. (2016). The Discoverable Partitions Specification. freedesktop.org.


• Lennart Poettering et al. (2017). systemd.swap. systemd manual pages. freedesktop.org.


• Lennart Poettering et al. (2017). systemd-fstab-generator. systemd manual pages. freedesktop.org.


• Lennart Poettering et al. (2017). systemd-gpt-auto-generator. systemd manual pages. freedesktop.org.


• Lennart Poettering (2014-06-17). Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems. 0pointer.net.


• Lennart Poettering (2014-09-01). Revisiting How We Put Together Linux Systems. 0pointer.net.


• Lennart Poettering (2017-06-28). mkosi — A Tool for Generating OS Images. 0pointer.net.

Historically, the swap partition is specified in /etc/fstab with an entry of type swap. On boot, the startup processes will read that file and push that configuration into the kernel.

An example of the entry in /etc/fstab is:

/dev/sdb none swap sw 0 0

I'm not familiar with how systemd manages swap, but I do believe that the end result is the same: a userspace process is aware of what space is allocated for swap, and the userspace process informs the kernel.

All the other answers mention how to point to a swap filesystem at boot.

However, several points to add to the other answers:

• the swap space can also be a file;


• a swap space partition is marked usually as type 0x82;


• you can mount a swap space at any point in run-time;


• for marking/initialising a partition/file, for it to be recognised and used/mounted later on as swap space, you need to use the command mkswap;


• for activating/using a swap partition/file by hand you use the command swapon;


• likewise for swapping it off, you go with swapoff.