After running mkswap, swap space is discarded, system fails to hibernate (invalid swap signature)

67437, 65798 might be duplicate, 48514 is probably related.

There seem to be further reports here:

http://www.ubuntuforums.org/showthread.php?t=270052

Scott, please investigate. I don't think this is related to bug 48514, though fixing that bug could cause other problems like this by creating a new uuid if we aren't careful.

could the problem be that there are two UUIDs for swap...one refers to the partition and the other refers to the swap-filesystem...

when i do mkswap it returns a new UUID for swap and no label...but when i do 'ls -la /dev/disks/by-uuid afterwards the UUID which refers to /dev/hda4 has not changed...

since i changed my /etc/fstab to contain the UUID which refers to /dev/hda4 i could do a 'swapon -a' after having done mkswap...if the UUID in fstab had referred to the UUID of the swap-filesystem it would have failed...

@jens: I think the by-uuid symlink is only updated after a reboot, you can try vol_id

I had to do the following to solve it:
- correct fstab with the UUID outputted by mkswap (vol_id might work, but /dev/disk/by-uuid definitely don't)
- put "RESUME=UUID=<uuid>" in /etc/initramfs-tools/conf.d resume.

The second step should definitely be done in postinst or upgrade for initramfs-tools since without this the swapspace get corrupted after a suspend2disk (currently the resume file is created only on install).

Now swsusp works and the laptop don't have any problem of swap disappearing.
I think the reason conf.d/resume wasn't created in the first place is because it was a "custom" dapper install (the swap already existed from a previous linux installation, so somehow when initramfs-tools was installed there wasn't any swap space available.

thank you tonfa...edited fstab and conf.d resume with value from mkswap
- regenerated initrd - and now it all works...

for anybody else reading this with the same issue regenerate your initrd
with "update-initramfs -u" after you have edited
"/etc/initramfs-tools/conf.d/resume" as tonfa described...

yay works for me now too.

The problem is running "mkswap", this will generate a new UUID and thus obsolete the information in both the /etc/fstab and /etc/initramfs-tools/conf.d/resume files -- which is why you need to edit those afterwards.

But anyway if conf.d/resume doesn't exist (that can happen), the computer will corrupt the swap when hibernating and the swap will not be used on reboot because it doesn't have a valid signature.
To me that's a bug, a system with a swap partition should pass a 'resume=' parameter to the kernel so that it can use it as swap even if a swsusp image is stored.

So please fix initramfs-tools to do that. I don't care for me, I fixed it anyway, but I'm sure there are other that would be happy if that is corrected.

Why is the swap partition corrupted?

On Wed, Oct 25, 2006 at 09:38:52AM -0000, Scott James Remnant wrote:
> Why is the swap partition corrupted?

hibernating without a proper 'resume=' parameter (either on the grub
commandline, or in the initrd)

--
:wq

right, you end up with a hibernate image in your swap partition; and nothing restores that

that's not corrupted though,you could just boot with resume= to restore it

running "mkswap" by hand is what actually buggers you :)

I've got the same problem (after upgrading from dapper to edgy).

Had the same issue. Solution from tonfa and jens_acamedia worked for me.

In order to work for me I had to change the symlink in /dev/disk/by-uuid by hand before the first hibernate.
Now swap (and hibernate) seems to work just fine

EDIT: The change in the symlink i required for the swapon command to work, which I performed before hibernate.

works for me too !

same problem herer aswell
jens' solution worked for me too (mkswap, change to new UUID in fstab, edit resume file, update initramfs). Haven't tried hibernation yet but swap is activated now on boot so it should work.

thx for all the help, but for me it does not work.
i did it as described and it updated the initramfs, but after every reboot the swap-partition has a different UUID.
i switched back to the old-fashioned style and my swap partition will be used as /dev/hda2, but if anyone has hint for me, i will try und report.

ben

Upon upgrade from a clean dapper install to the released version of edgy, this problem occurs. Suspend work ed the first time but I can't resume, and now I have no swap.

I can fix it by doing mkswap, and I plan to (as outlined in the steps above), but it would be nice if upgrading dapper users were not all burned by this.

Also note: after booting without resume=..., if the swap partition contains a valid resume image *it is dangerous to resume from it*. If you do, the kernel will have a different picture of the filesystem and its buffers than exists on disk and *filesystem corruption may result* (see the swsusp2 FAQ). One hopes the kernel is smart enough to mark the resume partition as out-of-date to avoid this pitfall.

I had also this problem, the fix mentioned above did the job well.

ben: did you edit your /etc/fstab (the swap line) and "/etc/initramfs-tools/conf.d/resume" as mentioned above?

amnesia: yes, i have done exactly this:

- determined my swap-partition device with fdisk -l

- got the right UUID of the swap-partition with vol_id

- wrote
<i>RESUME=UUID=<the-swap-partition-uuid-from-vol_ID></i>
in <i>/etc/initramfs-tools/conf.d/resume</i>

- wrote the right UUID into the /etc/fstab

- then i had to correct the symlink to /dev/hda2 (in my case) in /dev/disk/by-uuid to the new one, that vol_id has told me

- regenerated the initrd with update-initramfs -u, what finished without errors.

but after the next reboot, the swap partition is not used because the UUID has changed again ....

ben - uuid changes are not always reflected until after a reboot...

follow THESE instructions and report back

1, determine your swap with 'fdisk -l'
2, do mkswap on your swap partition - RECORD THE UUID WHICH THIS COMMAND
OUTPUTS
3, now use this UUID to put into fstab and resume
files...(RESUME=UUID=<the-swap-partition-uuid-from-vol_ID
should go in /etc/initramfs-tools/conf.d/resume
4, update-initramfs -u
5, reboot normally after this finishes

when the system has restarted again - do 'swapon -s' to check if your
swap is active...and do 'ls -la /dev/disk/by-uuid/'

dont change any symlinks etc. just try these instructions

jens_acamedia wrote:
> ben - uuid changes are not always reflected until after a reboot...
>
> follow THESE instructions and report back
>
> 1, determine your swap with 'fdisk -l'
it is /dev/hda2

> 2, do mkswap on your swap partition - RECORD THE UUID WHICH THIS COMMAND
> OUTPUTS
 mkswap /dev/hda2
Setting up swapspace version 1, size = 1496993 kB
no label, UUID=eb19acf3-bf59-484b-beac-a46f6b3dc990

> 3, now use this UUID to put into fstab and resume
> files...(RESUME=UUID=<the-swap-partition-uuid-from-vol_ID
> should go in /etc/initramfs-tools/conf.d/resume

done

> 4, update-initramfs -u
done, without errors

> 5, reboot normally after this finishes
now it works.
THANKS A LOT.

i try to figure out, what i have done wrong yesterday.
first i did determine the UUID of the swap-device and did a mkswap on the symbolic link /dev/disk/by-uuid/<uuid> (i do not know, why i did so) and maybe that will not work?!

again: thanks you very much for your step-by-step - instructions!

Thanks a lot for the instructions, they helped me a lot!

Buit, i still have a question:

Can I also put not the UUID but the vol_id in the /etc/initramfs-tools/conf.d/resume file?

It would look more nice, because I put the vol_id in the fstab and the UUID in the "resume".

Anyway it's not that important...

Grüsse aus dem Osten,

Johannes

May I ask what the big advantage of UUIDs is, since it causes so many
problems? Updating my server from Dapper to Edgy led to it using the
wrong / partition altogether!!! And there was no sign of my /
partition in /dev/disk/by-uuid!

Back to /dev/hda2, because that works, until someone clarifies why I
should use the new stuff... and the related bugs are fixed ;-)

On Sat, Nov 04, 2006 at 06:59:16PM -0000, Hervé Fache wrote:
> May I ask what the big advantage of UUIDs is, since it causes so many
> problems? Updating my server from Dapper to Edgy led to it using the
> wrong / partition altogether!!! And there was no sign of my /
> partition in /dev/disk/by-uuid!
>
It's related to the future switch to libata (kernel 2.6.18). If I
understand it correctly, ubuntu devs will probably switch to libata for
the next release.
libata is a new framework for the ata drivers (both sata and pata), when
you activate it, your devices will be renamed to /dev/sd* instead of
/dev/hd* so using UUID instead of device name will make the transition
not painful.

--
:wq

Have same problem here, on two laptops of mine. I suggest importance should be raised at least to important, since this bug is likely to cause troubles to a large part of user base who upgrades from dapper to edgy.

I can confirm the bug. It's quite suprprising, because for the first time in history mu vaio _did_ suspend to ram (and resume), which is notoriously more difficult than suspend to disk (aka hibernate), and failed to hibernate noe :-)!
I simple restored the /dev/hda5 fstab entry and added a resume=/dev/hda5 on the boot line.
I suggest that importance of this bug should me marked high, and then posting a "standard" solution so that things will not break again in the future.
OTOH: grat work for edgy. My vaio is now almost fully functional. Kudos!

I stumbled on this bugreport when searching for a solution for random system freezes in Edgy. I *think* the step-by-step of jens went alright, but it's bothering me that none of the swap is being used. The output of swapon -s for example:

Filename Type Size Used Priority
/dev/sda3 partition 4200988 0 -1

Is this normal (perhaps considering I have 2 Gb of RAM)?

P.S. I cannot comment on the system freezes being solved, but so far so good.

only found this by chance (thanks jens) so i changed the title to one that i would have found.

After using Jens's instructions, I had the same problem as Crakie. Swapon showed the priority -1 for my swap partition.
In the swapon man pages, I found that the priority should lie between 0 and 32767.
After adding 'pri=32767' to the swap partition's options in /etc/fstab, the swap partition is used.

andreas - why make it so complicated. priority -1 is not a problem....
if swapon -s reports a priority of -1 that means it is reporting an
ACTIVE swap partition...

for everybody else - dont mess with more than you have (unless you
really know what youre doing of course)...just follow the instructions
for a working system...

priority -1 was set by somebody as default on edgy for a reason...

I too had this problem (hibernation broke on update to Edgy). The procedure described above worked.

My problem may have been that my /etc/initramfs-tools/conf.d/resume file just said:

    RESUME=

Somehow the swap partition UUID never got registered there on the Edgy upgrade.

this happened on my FRESH install of edgy. I think they need to consider things like this to work tword BUG 1 being finished.

This still happens in Edgy. (December 2006) Been wondering for a long time why everything hangs so often.

So much for linux's stability?? This is totally unacceptable. Why aren't there updates for this when so many minor unimportant applications get updates?

To repeat what was said above- this is not just a problem of hibernation. Effectively, after a dapper->edgy upgrade, the swap partition is lost. Ubuntu does not work well without a swap partition, as it wil grind to a halt if you run more than a few programs at once, even at 256GB RAM. For the unsuspecting user, this bug results in strange halts or freezes, wondering why edgy is much more unstable than its predecessor. This makes the problem critical, and I agree with the poster above that it is puzzling to see so little developer feedback on this bug-report.

Some more observations:

* Symptoms include "free" displaying no available swap space and "swapon -a" failing with "no such device"

* This happens even if the user doesn't "mkswap" manually; upgrading is quite enough.

* This also (obviously) prevents hibernation from working (though trying to hibernate does not, for the most part, fail gracefully).

* Trying the fix above (using mkswap and update-initramfs) actually resulted in my root partition being corrupted: the partition could only be mounted ro, and fsck'ing made things worse yet. As to why this happened, I have no idea. It might very well be another unrelated bug.

In conclusion, it seems that this is a good candidate for a Edgy point release (if this can be thusly fixed), or at least a remark inside the release notes.

One more thing: I noticed that the UUID put into /etc/fstab was indeed correct - still "swapon -a" did not work. This seems to imply that there are some incompatibilites between the swap signature used in dapper and edgy, possibly related to hibernation (hence the remarks above about swap space being corrupted).

I think that the correct "ad-interim" (temporarily) solution is what I did. Just replace the fstab line referring to the swap with the absolute device name (/dev/hdXY, in my case was /dev/hda5), then mkswap /dev/hda5, and finally add "resume=/dev/hda5" to the options in the grub menu.lst file.
After that my laptop works like a charm --- much better than in Dapper, really: wifi, suspend to ram, etc...

I can confirm this bug for my upgrade from Dapper to Edgy. I tried the solutions mentioned by tonfa and jens_acamedia and it works for me! Thank you.

This is not an upgrade bug.

If you have a bug that is only related to upgrading from dapper to edgy AND YOU HAVE NEVER RUN mkswap (ie. your machine failed to hibernate), then you have a DIFFERENT BUG.

Please don't hijack this one.

Scott, thanks for you reply. You seem to claim the following about this bug:

1) It appears not only after a dapper->edgy upgrade.
2) It appears only after running "mkswap" on your swap partition without changing fstab accordingly.

You're right with the first point, this issue seems to be more general than I thought. Sorry for changing the subject. About the second point, though, I'm not so sure. I had the exact same problems described here without running anything manually (unless the swap parition is initialized in the automatic update). Also, please note that the bug submitter mentions an upgrade in his report, but not running mkswap.

Please re-read the bug's history, and also note the number of duplicates. I could file another report, but that seems both grauitious and harmful given the above.

It was confirmed that the reporter had run mkswap

I've the same problem and was partially solved recreating swap partition and changing fstab + /etc/initramfs-tools/conf.d/resume

I'm able to hibernate when Ubuntu is at GDM login screen but if I try to hibernate when gnome is active (session initiated) the hibernation fail, never resume, recovered only turning off and some times removing batteries. The are several file system problem after restarted.

Manuel

Acer Travel Mate, Centrino, Ubuntu 6.10 updated

To Scott: It happened to me just after the upgrade, and I do not remember having used manually mkswap before the breakage.
Nevertheless, I have to say that the upgrade failed midway for me, and I had to recover the system via a quite convoluted live-cd / manual mount / chroot and apt-get magic, so maybe in the meantime something strange happened. What I know is that I first noticed the problem due to inability to suspend-to-disk (aka hibernate).

> It was confirmed that the reporter had run mkswap

I dind't even KNOW that 'mkswap' command until reading about it here as being part of the solution!

I definitely did not run mkswap, ever. In fact, it happened on my FRESH install of Edgy. First time it happened it could have been because of an upgrade. I experienced massive instability, didn;t know about this bug at the time so then did a fresh install of Edgy. (re-using an existing swap partition). Not sure if the problem persisted or appeared again later.

Whatever the cause, it's bad. Perhaps do an active check during startup that swap space is indeed available and make noise if it doesn't.

I can confirm that an upgrade to edgy was enough to break my swap. The descibed procedure ("resume=uuid...") worked for me.

I also have this bug on a clean Edgy install.
I used Gparted to fix my swap partition but I don't remember if it happened before noticing that hibernation doesn't work or after.
I changed my fstab nad resume entries to plain old /dev/sda5, I'll test it in a moment.

Ok, I tested it - hibernation still doesn't work, sleep works but after waking up the system hangs (that also happened before my changes to fstab and resume).
My laptop is HP nx6325 EY349EA.
I didn't noticed the lack of swap because I have 1GB of RAM.

Without a "resume=UUID=<...>" update to my menu.lst file (for grub), none of this worked. (Alas, maybe one could do a "resume=/dev/hdxx" and it would probably work, too.)

Note that I can only get this to work for a 2.6.17.14 kernel running in Edgy; the standard 2.6.18.1 edgy kernel panics for both suspends and hibernates on my Thinkpad T41 2378DHU with 2GB of memory. The 2.6.17.14 kernel suspend and hibernate works like a charm...if I go around updating the 3 different places one must update for the swap pointers (/etc/fstab, /etc/initramfs-tools/conf.d/resume, and /boot/grum/menu.lst) after the dapper-to-edgy upgrade (...sigh...).

HOWEVER, 2.6.17.14 takes a full 3 minutes to boot up...UGH! 2.6.18.1 takes about 20 seconds to boot up on the same machine (great!), but experiences the kernal panics per the suspend/hibernate, and all I'm chaning between .17.14 and .18.1 runs is the kernel choice in grub--it's all run from the same machine.

Anybody know what gives?

I've spent several hours tonight trying to debug this. I'm not that pleased that edgy apparently didn't seem to get sufficient laptop test coverage, but I'm here to help with the effort.

Please let me know how I can help (more details needed for my system?), and thanks for any feedback.

-Matt

A clarification as per above: I was under the impression that Edgy ran "standard" with a 2.6.18.1 kernel...but alas, I may have been mistaken.

In any case, the kernel revs I report above are correct, but they may or may not have anything to do with Edgy "standard" stuff, for they may be there simply because I built them myself some time ago on my same system when it was previously a Dapper box...and said kernel revs were inherited when I upgraded.

How would I get the de facto Edgy kernel rev/source...or just get the binary from an apt-get somehow?

-Matt

Matt England:
> HOWEVER, 2.6.17.14 takes a full 3 minutes to boot up...UGH!

Perhaps the same issue as this one? <https://bugs.launchpad.net/distros/ubuntu/+bug/74522>.

Thomas Schwinge wrote:
> Perhaps the same issue as this one?
> <https://bugs.launchpad.net/distros/ubuntu/+bug/74522>.

Thanks Thomas, I started a followup conversation there.

With respect to this bug thread:

I am also still curious as to why my system seems to require a "resume=" entry in my /boot/grub/menu.lst file in order to get my hibernates to work for 2.6.17.14, while there is little if any mention of this anywhere else on this thread.

Also note, that I installed the binary linux-image-2.6.17-10-generic (2.6.17.1-10.34) package binary available from Ubuntu-Edgy's apt servers and had the exact same experience with slow bootups but working hibernates and suspends.

I am also building a 2.6.19.1 kernel to see if I can get the best of all worlds (fast bootups, working suspend and hibernates).

I would also like to see if there exists some sort of master test-plan framework for which outsiders like me can update so as to avoid what seems to be a lot of Dapper-to-Edgy-upgrade-based problems with laptops like mine.

-Matt

I'm using Ubuntu 6.10 and had the same sympthoms everyone else.

I followed comment #23 but it was not sufficient. Swap worked fine but hibernate didn't. After re-iterating I added the entry on menu.lst (like comment #50 recommended):

resume=UUID=<uuid from partition>

And now it works.

Just to add to this, I upgraded from ubuntu 4.10 all the way to 6.10. I noticed the problem first when my machine (VAIO laptop with 1 gig of ram) got irresponsive. Then I noticed I had no swap space.

I did try hibernate and suspend before, hibernate never worked, suspend might have once.

What might be interesting is that my machine had also had swap FILE setup which was also not being used when I had problems. running mkswap on that fixed the problem.

I have updated the UUID for the swap PARTITION in fstab using the instructions in

https://answers.launchpad.net/ubuntu/+ticket/2488

see also

https://answers.launchpad.net/ubuntu/+ticket/3234

swapon -a enabled the swap partition. I have yet to reboot to see if it remains working. I'll update the hibernation config (/etc/initramfs-tools/conf.d/resume) sometime later to see if hibernation now works. (which would be great).

After updating to the kernel 2.6.17-11-386, the update procedure blew off my grub.conf configuration and left my swap partition unusable.

this is still the same in feisty (confirmed in bug 85416)

For me still doesn't work after hibernate :(
I did it in that way:
-mkswap /dev/sda7
Setting up swapspace version 1, size = 1077473 kB
no label, UUID=36ddb4d6-f8b9-446b-bdbf-70d4b40c6d70
-in /etc/fstab:
UUID=36ddb4d6-f8b9-446b-bdbf-70d4b40c6d70 none swap sw 0 0
-in /etc/initramfs-tools/conf.d/resume
RESUME=UUID=36ddb4d6-f8b9-446b-bdbf-70d4b40c6d70
-update-initramfs -u
My system: 2.6.17-11-386

Did you update your grub.conf accordingly?

I think I am having a similar problem.

Please see the following forum discussion:
http://ubuntuforums.org/showthread.php?t=343570&highlight=swap+file+fails

I think it has something to do with this, but after Kubuntu Edgy (w. KDE 3.5.6) update to Feisty (or some of feisty updates) broke my swap and my hibernation.

When trying to hibernate, it looks like it's shutting down X, but then it pops back and gives this message:

/bin/echo: write error: Cannot allocate memory

Most likely this was because of the lost swap partition. I needed to re-activate the swap partition and change the UUID in /etc/fstab to make swap work again.

Haven't tried since does it hibernate, but I'll let you know if reactivating swap was a solution for me.

r

After installing Feisty hibernate was not working. I had to do the usual:

mkswap /dev/sda2 # grab the UUID=XXXXXXX
vi /etc/fstab # update the UUID on the line of /dev/sda2
vi /boot/grub/menu.lst # make sure this line is like: # defoptions=quiet splash resume=UUID=XXXX
update-grub
reboot

Perhaps https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/50437 is related to this one

fwiw, I disagree with some of the recent marking of duplications of this bug.

As Scott James Remnant states above, this bug is for dapper->edgy upgrades where people have run mkswap by hand. Many of the recent supposed duplications are from people running feisty who've never seen this problem before (such as me).

I think what is happening in fesity is that a hibernate/resume is failing for some reason (or more likely, various reasons), leaving the user with a swap partition that swapon doesn't like (although I can't be sure of that because it seems to have stopped happening to me) and so "correcting" it by resetting their swap, but this of course requires that fstab and /etc/initramfs-tools/conf.d/resume be updated and this (please correct me if I'm wrong) is not documented.

Perhaps mkswap could be patched to warn users that they will need to update these files, or it could be patched to retain the UUID (perhaps with an option to make a new one)

I had this problem with dapper->edgy, and the instructions above ( https://launchpad.net/distros/ubuntu/+bug/66637/comments/23 ) fixed it.
Now I've upgraded edgy->feisty. The problem has come back, and following the same instructions has not fixed the problem.

After upgrade to feisty my IBM ThinkPad T23 stop hibernate, complaining about invalid swap signature.

After triying some solution here proposed, i've simply put on /etc/initramfs-tools/conf.d/resume file not the UUID but the phisical partition (/dev/hda2) and now my TP hibernate correctly.

FYI.

I have been having the same problems: I recently installed Feisty in my laptop and it would grind to a halt, thrashing until I couldn't do anything. Suspend to disk failed. It took days until I did track the problem to the fact it was not using my swap partition because the uuid created in my /etc/fstab wasn't the same as in the physical partition. The swap partition's uuid would change unpredictably, and I had to adopt the notation /dev/hdaX in my /etc/fstab to actually be able to use my swap partition. see bug #67437 as well.

I can confirm this on Kubuntu Feisty: when I updated the initial kernel (the first update after the installation from the CD), not only the libata was gone and sdX reverted to hdX, but the swap UUID was changed, thus not being used anymore, and the hibernation failed!

Manually updating fstab fixed the thing. but this should be addressed programatically.

After completing the fix listed at http://www.thinkwiki.org/wiki/Installing_Ubuntu_7.04_on_a_ThinkPad_T43#Swap_and_Hibernation_problem, which is essentially the same as what's listed above, hibernation is working fine for me, and swap is enabled on boot, however swapon -s is listing an entry for both /dev/sda2 and /dev/mapper/sda2, and free -m shows double the amount swap space that it should.

This seems like something to me like something to be concerned about, but I'd like to get the opinion of someone more with a more thorough understanding of these issues.

Note that this is mentioned above (https://launchpad.net/ubuntu/+bug/66637/comments/30) by Crakie, but no one commented on the appearance of double the swap size.

@Darian:
swap mounted twice is already reported in bug 86234 (2 swap partitions each mounted twice in 2.6.20-8).

@Alex:

Ah ha. Thanks for the heads up. I added the temporary fix to rc.local.

I'm going to jump in on this. I'm seeing a different but related problem. I'm using Gutsy. I am working on bare metal restoration (http://www.charlescurley.com/Linux-Complete-Backup-and-Recovery-HOWTO.html). The least intrusive way for me to perform a bare metal restoration is to provide the UUID to mkswap when I create the swap partition(s) at restoration time.

I cannot let mkswap generate the UUID and then edit fstab gracefully because fstab isn't on the disk where I can get at it at the time the restoration code deals with mkswap and the swap partitions. Also, there could be other code elsewhere that uses the old UUID.

Reading this issue, I propose that mkswap accept a UUID and use it when preparing a swap partition. That would satisfy my requirement. In addition, mkswap should generate and assign a new UUID only if:

* There is no valid UUID already on the partition, and

* The caller does not provide a UUID as an argument to mkswap.

Alternatively, is there a general purpose tool one can use to set the UUID after running mkswap?

I predict that other bare metal restoration facilities like bacula will also hit this problem.

There is another alternative to solve the UUID problem, that is use the "mkswap-uuid" program.

Look at these two locations:
* http://www.nabble.com/DRBL-1.8.0-15-(stable)-released-t4492611.html
* http://free.nchc.org.tw/drbl-core/old/src/

You need to compile it manually, but the whole process takes only several minutes :-)

So here are the steps:

1. sudo apt-get install build-essential uuid-dev
2. mkdir ~/work ; cd ~/work
3. wget http://free.nchc.org.tw/drbl-core/old/src/mkswap-uuid-0.1.0-2.tar.bz2
4. tar -xjf mkswap-uuid-0.1.0-2.tar.bz2
5. cd mkswap-uuid
6. make && sudo cp mkswap-uuid /usr/local/bin

After that you have the "mkswap-uuid" binary which you can use to recreate the swap partition with desired UUID:

7. swap_device=/dev/<name-of-swap-partition>
8. swap_uuid=<put-desired-swap-uuid-here>
9. sudo swapoff ${swap_device}
10. sudo mkswap-uuid -U ${swap_uuid}
11. sudo swapon ${swap_device}
12. sudo blkid ${swap_device}

There.

A goblin ate some of my words. It should be:

10. sudo mkswap-uuid -U ${swap_uuid} ${swap_device}

Cheers!

Maybe at some point the system should also detect corrupted swap partitions and mkswap-uuid them so that no system can lose its swap without the user being told of it. For now, if people use mkswap, it's because their swap was corrupted, often because of hibernation problems - the two issues are linked.

This debdiff re-applies the mkswap-during-swapon, but includes the existing UUID. This will get uploaded after Beta has released.

This bug was fixed in the package util-linux - 2.13.1-3ubuntu1

---------------
util-linux (2.13.1-3ubuntu1) hardy; urgency=low

  * New Debian version: remaining ubuntu changes:
    - use libvolume-id instead of libblkid
    - udev hooks

util-linux (2.13.1-3) unstable; urgency=low

  [Kees Cook]

  * swapon: Reinitialize software suspend areas to avoid future corruption.
    LP: #66637

 -- LaMont Jones <email address hidden> Fri, 21 Mar 2008 10:20:36 -0600

I'm spending more time fixing bugs/ using workarounds than i am enjoying my Ubuntu OS. What gives?
YEARS later this is still a problem? I tried to put my computer into Suspend, and now I have no swap.
I have Ubuntu Hardy, the util-linux is up to date
I guess i'm going to have to forego this fix - and hope i dont make anything worse. I've got about 30 bookmarks for fixes i've needed to address when I reinstall Ubuntu...

Is there a reason that there's still a Baltix task open on this bug?

closing baltix task