A fellow administrator had the task of re-allocating precious space on a server, that meant partitions would be moved around. Apparently during the process the swap partition was resized which resulted on the system loosing all of the available swap, despite the fact that the partition was never actually deleted.
After noticing the problem I decided to check /etc/fstab, I could see an entry for swap at boot. However the partition was not being mount it during boot up, leading me to believe that the UUID might have changed.
UUID – Universally Unique Identifier
First use the blkid program to determine the new UUID of the swap partition. Look for the entry with the TYPE=”swap” and copy the UUID.
$ blkid /dev/ramzswap0: TYPE="swap" /dev/sda1: UUID="8192a29b-e191-4347-a65c-3be8546a5c5c" TYPE="ext3" /dev/sda5: TYPE="swap" UUID="b6a5fce4-9938-4518-809a-2cd0f5e194e8" /dev/loop0: TYPE="squashfs"
Now open /etc/fstab and visually compare the swap UUID output from blkid with the current entry on fstab which should be different.
My swap partition is located in /dev/sda5.
# /dev/sda5 UUID=55a68fbd-2f25-447b-99fd-02e972937a3c none swap sw 0 0
Because they are different the problem is evident the UUID changed, meaning the system no longer has the correct swap UUID to call on boot up.
The solution is simple just remove the old swap UUID entry found on /etc/fstab and paste the new UUID you got from blkid.
# /etc/fstab: static file system information. # #
proc /proc proc defaults 0 0 # /dev/sda1 UUID=8192a29b-e191-4347-a65c-3be8546a5c5c / ext3 relatime,errors=remount-ro 0 1 # /dev/sda5 UUID=b6a5fce4-9938-4518-809a-2cd0f5e194e8 none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
The last thing to do is reboot the system and check the available swap.