Share same swap partition on different distribution

I’m using Kali Linux and Open SuSE 15 alongside. Both distribution uses same swap partition but when I start suse a start job on swap partition running for about 1.30 mins. When I format swap In Suse same happens in Kali.
How to use same swap on both distribution without glitch.

Thank you
Yogesh Kumbhar

Yes, you can use the same swap.

But, yes, you will run into problems. Unfortunately linux distros get this wrong.

Example: I recently installed both “Ubuntu 19.04” and “Kubuntu 19.04” along side one another. This was in a virtual machine. The two different Ubuntu variants were unhappy about sharing swap.

Here’s the problem. The first Ubuntu that I installed wanted to mount swap by UUID. And it formatted swap.

The second Ubuntu (or Kubuntu) also wanted to mount swap by UUID. And it too formatted swap.

The problem is that when the Kubuntu install formatted swap, that changed the UUID and broke the first install.

If sharing between openSUSE and another system, the easiest solution would be to install openSUSE last. That’s because openSUSE does not insist on reformatting swap. You can tell it not to reformat, in which case it does not change the UUID.

The other method that I could have used, would have been to not assign swap for the second install (for the Kubuntu) install. And then I could manually add it to “/etc/fstab” later.

The way to really avoid problems, is to access swap by device-id rather than by UUID. The device-id should say the same, even if another install reformats swap.

In any case, I fixed the Ubuntu/Kubuntu issue by editing “/etc/fstab” in Ubuntu and changing the UUID used to match the one that was current. You can find the current UUID with the “blkid” command (as root).

In an openSUSE system, the swap partition also shows up in the “resume=” boot parameter. You can change that Yast bootloader.

I have Solus installed in a VM. And it is using swap. But there is no entry for swap in “/etc/fstab”. I’m assuming that there is a “systemd” unit file which identifies swap. But I haven’t gone looking for that, because it is not currently causing problems.

I hope I did not confuse you with too much detail.

Debian and its derivatives all insist on formatting swap at installation time - if swap is to be used. My workaround is to ***not ***designate a swap partition at all during “debian” installation, then on first boot, add the existing labeled swap partition to the new fstab, mounting by label, which is how I specify mounting all native partitions anyway. UUIDs are for robots, not humans.

Resuming is a booby trap in multiboot environments. Specifying noresume on all kernel cmdlines instead of any resume= avoids the potential trap, and any need to coordinate UUIDs among the diverse installations and grub configurations.

When installing the second OS don’t use swap. When done add swap manually, preferably by copying the line in fstab from the first OS and turn it on by “swapon -a”. Update grub2 accordingly.

What exactly is it necessary to update in grub2? grub does not care about swap at all.

The original poster asks for “use of same swap without glitch”. When installing without swap hibernation will be disabled. It can be enabled by reinstalling grub2.

If swap is shared between multiple OS instances, hibernation image cannot be stored on this swap partition, because image will be overwritten by booting different instance.

It is possible to use dedicated partition in each OS (it need not be swap). It may be possible to use file, but here I am not sure if current tools actually support it.

And it is not necessary to reinstall grub, all you need is just recreating grub.cfg.

Now I’ve solved the problem removing Kernel Parameter resume=
is that OK?

That may mean that hibernation won’t work. Personally, I never hibernate my system, so that would not bother me. Whether it matter for you, is something for you to decide.

There was a UUId for my earlier swap partition. Should I change it to existing UUId?

Yes, that change would fix any problems. And it should still allow hibernation.

Yes, that change should fix any problems and still allow hibernation.

You might need to also fix “/etc/fstab” if that uses UUID for swap.