[Feisty] Swap partition receives new UUID

Bug #105490 reported by tactus
This bug affects 1 person
Affects Status Importance Assigned to Milestone
udev (Ubuntu)

Bug Description

I noticed recently my swap partition was gone. free -m returned zero space swap. /etc/fstab was configured with a wrong UUID for my swap partition (/dev/sda2).

Updating fstab with correct UUID and a reboot brought back my swap disk, but upon hibernate (or later reboot) the UUID for my swap disk changed to a new value and I have to manually update my fstab file again to restore swap.

Something is causing UUID value to change on my swap partition.

Xubuntu 7.04 beta.

tactus (tactusetc)
description: updated
Revision history for this message
moma (osmoma) wrote :

I can confirm this.
UUID for the swap partition was wrong in /etc/fstab. Swap was not mounted or activated.

I do not have laptop so I cannot test the hibernation.

Anyway, this is how to find the correct UUID for any partition.

Find the device name of swap.
$ sudo fdisk -l

Find the UUID for that partition. Eg.
$ sudo vol_id /dev/sda3

Revision history for this message
omichalek (bng) wrote :

I can confirm this as well, I had submitted another bug, and my swap uuid changes repeatedly after every few reboots.

Revision history for this message
Brian Murray (brian-murray) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. What version of the kernel are you using? Thanks in advance.

Revision history for this message
tactus (tactusetc) wrote :

My current kernel version is:
$ uname -a
Linux dellbox 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

Not sure if this is useful, but /etc/fstab and vol_id showed some confusing data this morning (/dev/sda2 is my swap partition):

$ cat /etc/fstab | grep swap
UUID=9a42174c-13f8-4d19-8412-8810d5996eee none swap sw 0 0
#/dev/sda2 none swap sw 0 0

$ sudo vol_id /dev/sda2

$ free | grep Swap
Swap: 2096472 0 2096472

Revision history for this message
tactus (tactusetc) wrote :

Update: After rebooting with the above /etc/fstab settings my swap is once again gone (as expected).

$ free | grep Swap
Swap: 0 0 0

$ sudo vol_id /dev/sda2 | grep UUID

What happened prior my post above I tried to hibernate from the gnome power manager applet in system tray (xfce). It seemed to work okay, but when turning on the computer it just booted up normally and didn't restore from hibernate state.

Hope this information can be useful.

Revision history for this message
davidlm (guardhexen-ubuntuforum) wrote :

I have the same error the swap gone....previous i tried to hibernate.....

Revision history for this message
anthony baxter (anthony) wrote :

Same problem here. The UUID in fstab didn't match the one in /dev/disk/by-uuid/. This started after a sleep/wake cycle. Had to fix it by hand by editing fstab to use the correct value from /dev/disk/by-uuid. swapon -a was reporting:
% sudo swapon -a
swapon: cannot stat /dev/disk/by-uuid/15ed6769-566c-4228-bb35-d9a0131dc42c: No such file or directory

There was nothing relevant in the dmesg output.

This is pretty serious - when the swap was missing, I was seeing the machine running very, very slowly.

Revision history for this message
Lionel Duval (fennec) wrote :

You can correct by hand the UUID in /etc/fstab after doing a new mkswap and copying the new UUID from vol_id. It should work. Report please.
Nevertheless, it's really a bug: we shouldn't have to put our hands there.

Revision history for this message
CyberRaven (cyberraven) wrote :

Confirmed by me as well. I'm running Kubuntu 7.04 on a ThinkPad X41 with kernel

eivind@ravenwing:~$ uname -r

Suspend and hibernate worked out of the box, but after a few restarts, hibernation ceased to work (it wouldn't hibernate at all). (Suspend still works.) When trying to hibernate, it gave the following message in dmesg (the last one);

eivind@ravenwing:~$ dmesg | grep swsusp
[ 3540.088000] swsusp: critical section:
[ 3540.088000] swsusp: Need to copy 126471 pages
[ 3540.088000] swsusp: Normal pages needed: 66997 + 1024 + 32, available pages:
[ 3540.088000] swsusp: critical section/: done (126471 pages copied)
[ 3545.384000] swsusp: Cannot find swap device, try swapon -a.

I checked my KSysGuard, and it claimed "No swap space available" in the status bar - "Odd", I thought. When searching the web, I found this bug, and a thread on ubuntuforums.org, http://ubuntuforums.org/showthread.php?p=1683612 (See also https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/66637 and https://bugs.launchpad.net/ubuntu/+bug/67437)

Here are some outputs, in case they could be of any help (/dev/sda6 ought to be my swap partiton, but as the following indicate, its uuid has somehow changed, and doesn't match the one in the fstab):

eivind@ravenwing:~$ free -m | grep Swap
Swap: 0 0 0

eivind@ravenwing:~$ sudo swapon -s
Filename Type Size Used Priority

eivind@ravenwing:~$ sudo fdisk -l | grep swap
/dev/sda6 3817 4093 2094088+ 82 Linux swap / Solaris

eivind@ravenwing:~$ sudo vol_id /dev/sda6

eivind@ravenwing:~$ cat /etc/fstab | grep -B 1 swap
# /dev/sda6
UUID=8cb560ee-a321-4e9a-9805-ccf589b109de none swap sw 0 0

eivind@ravenwing:~$ sudo swapon -a
swapon: cannot stat /dev/disk/by-uuid/8cb560ee-a321-4e9a-9805-ccf589b109de: No such file or directory

After following the method in this post, http://ubuntuforums.org/showpost.php?p=1773316&postcount=3 (similar to Lionel Duvals suggestion), swap works again;

eivind@ravenwing:~$ swapon -s
Filename Type Size Used Priority
/dev/sda6 partition 2094080 0 -1

(...but sadly, now hibernation fails on resume. That's not relevant for this bug, though...)

Revision history for this message
CyberRaven (cyberraven) wrote :

^^ update, Just in case anyone else has the same symptoms, or it has relevance for the bug; after another reboot and update-initramfs (see mentioned thread on ubuntuforums) hibernate works again!

Revision history for this message
grahams1 (gps1539) wrote :

I have this issue with 2-6-20-16 when hibernate stopped working and would just bounce back to the screen saver. I finally tracked this down to my swap partition failing to load as the UUID had changed.

After running blkid and editing /etc/fstab with the new UUID, swapon -a loaded swap. I hibernated ok, but then could not resume. I had no swap again and found the UUID had changed again and did so on every reboot !

The following seems to work and stops my swap partition UUID from changing

edit the file '/etc/initramfs-tools/conf.d/resume' (ie sudo vi /etc/initramfs-tools/conf.d/resume) and updated the line that begins 'RESUME=UUID= .... ' with the new swap partition UUID.
edit the swap entry in /etc/fstab with the new swap partition UUID
 'sudo update-initramfs -u' to update the intitrd with the new UUID.

I've hibernated correctly a few times now.

Revision history for this message
Brian Murray (brian-murray) wrote :

grahams1 were you able to pin down what was making the UUID change?

Revision history for this message
Srivatsa Kanchi R (srivatsak) wrote :

I confirm this problem of swap not been activated. The UUID changes when resumed after an hibernation. can we just replace the UUID with the actual device block (say /dev/hda6 , which represents a swap partition, in my case)

Revision history for this message
Hidetomo Hosono (h12o) wrote :

I confirmed this problem, too.

Here is what I did to fix:
1. follow all this procedure: https://bugs.launchpad.net/ubuntu/+bug/105490/comments/9
2. sudo /etc/init.d/udev restart
3. remove /etc/uswsusp.conf
4. sudo /usr/sbin/update-initramfs
After these procedure, hibernation feature works correctly.

I think that the generated /etc/uswsusp.conf is not suitable. But I have not reveal what is wrong of uswsusp (or other packages).

Revision history for this message
Gabriel Bouvigne (bouvigne) wrote :

Same problem here, but this was because my swap partition was gone.
Now, I am really wondering why was it gone.

Revision history for this message
Bèr Kessels (berkes) (ber) wrote :

Has been troubling me too.
My fix around this is to change fstab and make it use the old and proven none-uuid devices
  # /dev/hda5
  /dev/sda5 none swap sw 0 0

Certainly not a /real/ solution, more a hack to make things work again, so to say.

However, this broke several times because during updates ubunty switched my disks from hda5 to sda5 twice already. That, however, is an entirely different issue.

Revision history for this message
Nick (morrownr) wrote :

I've confirmed this problem on multiple systems with Fiesty and Gutsy. I've followed the recommendations above but have been unable to get the Swap UUID to stick. I've searched the forums, the internet and here. My conclusion is that this problem is at the root of many reported problems.

This problem kills hibernate capability.

Request that the priority be bumped to HIGH.

Revision history for this message
Nick (morrownr) wrote :

After much searching, reading and testing I now have hibernate and Swap going reliably on one system. I'll test this on other systems as I have time. I realize this is not the fix we really need but at least it works for now here:

Fiesty Swap/hibernate fix:

- Check swap: $ free | grep Swap

  If you see the follow then your Swap file is broken:

  Swap: 0 0 0

- Find the device name of swap: $ sudo fdisk -l

  UUID support appears to be broken as far as the Swap is concerned.

- Edit fstab with correct non-UUID information: $ sudo gedit /etc/fstab

- Edit resume with correct non-UUID information: $ sudo gedit /etc/initramfs-tools/conf.d/resume

  Example: RESUME=/dev/sda6

- sudo update-initramfs -u

- Reboot

- Check swap if you want: $ free | grep Swap

- Open some apps

- Test hibernate

Revision history for this message
George Moody (gmlnx+) wrote :

I found the value of the UUID given by mkswap was incorrect. Post reboot the vol_id value differed to the mkswap value.

After correcting /etc/fstab, /etc/initramfs/config.d/resume , boot/grub/menu.lst to the vol_id value then restarting udev, updating initramfs and another reboot, I can resume from hibernate.

Revision history for this message
reliable-robin-22 (nicolasdiogo) wrote :


i really had a hard time figuring out what was wrong with my system.

but thanks to this post i fixed (so far).

i followed the advice of tactus said on 2007-04-19:

and updated all values of UUID in my /etc/mdadm/mdadm.conf file with the new ones and it works...

hope Ubuntu Team takes this post and fix the problem.



Revision history for this message
ubergeeknz (dan-capper) wrote :

This is occuring also on my Feisty installation, no wonder my laptop has been running like the proverbial mutt. I followed the above instructions to use plain old filesystem locations and now my swap is back!!

This really really needs to be fixed!! If there is any debug information etc that will help further then please advise...

Revision history for this message
t33baum (gamblar3) wrote :

i had the same problem.

the problem is the symbolic link in /dev/disk/by-uuid/ at the swap partition.

to fix it make:

sudo mkswap /dev/<swap partition>

copy the new uuid

edit your /etc/fstab
       UUID=<new UUID> none swap sw 0 0

edit your /etc/initramfs-tools/conf.d/resume file
       UUID=<bew UUID>

go to the /dev/disk/by-uuid/ directory and make this entry
       ls -al | grep <swap partition>

this gives you your old UUID

and now make this entry
      sudo mv <old UUID> <new UUID>

    sudo swapon -va

    sudo update-initramfs -u

the problem is fixed after a reboot

Revision history for this message
miaviator278 (stormesi) wrote :

All this talk about removing UUIDS from fstab is not a solution. Every boot my Device Names and UUID's are changing. The only way for me to boot this system currently is to hand edit fstab every boot, or to use a different distro.

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

miaviator: if this happens at every boot despite of the fix above, please report a separate bug. Are you sure UUIDs are changing?

Revision history for this message
Hervé Fache (rvfh) wrote : Re: [Bug 105490] Re: [Feisty] Swap partition receives new UUID

@miaviator278: what version are you running? I haven't seen this issue
in a long while!

I run 8.04 LTS and have never seen this sort of behaviour, using
suspend almost all the time.

I am also quite sure 7.10 was fine.

Revision history for this message
thulir (sittilingi) wrote :

am using 7.10, and have got the same problem after I crated a new partition for swap and deleted the old one [as I wanted a bigger swap.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers