Natty swapfile fails to clear after hibernate wakeup

[psusi]

You didn't have testdisk repair the partition table yet.

[Sleepy-zz-John]

Are you recommending testdisk as a preferable option to repair the partition table rather than e2fsck? Both seem to have a repair capability, but I don't know which would be safer/easier/better. There's even GParted as a 3rd option, but again, no experience on relative merits.

If you're recommending testdisk, then apart from general interest and gathering information, I'm unclear what the point of the yesterday's fsck excercise was.

I've now burned a Live CD of BootMed1 (basically a Live Maverick with testdisk and other partition-related utilities burned into it), which I find is infinitely easier than struggling with trying to install testdisk working from my live Natty CD. This Live Maverick seems a lot more stable and much less resource-hungry than my Live Natty. I'm beginning to wonder if this might have some bearing on my original Natty hibernation troubles.

[psusi]

Are you recommending testdisk as a preferable option to repair the partition table rather than e2fsck? Both seem to have a repair capability, but I don't know which would be safer/easier/better. There's even GParted as a 3rd option, but again, no experience on relative merits.

e2fsck is for checking and repairing the ext2 series of filesystems. It has nothing to do with partitions or partition tables. Testdisk can repair partition tables.

If you're recommending testdisk, then apart from general interest and gathering information, I'm unclear what the point of the yesterday's fsck excercise was.

The point was to make sure that you didn't just have some minor filesystem damage that it would easily fix. Instead it confirmed that the problem is with the partition table.

[Sleepy-zz-John]

You didn't have testdisk repair the partition table yet.

OK, I'm now trying to do that using testdisk on a live BootMed CD

Encountering some difficulty in TestDisk (please see my attached "TestDisk.png") because when I highlight the 2nd entry there as shown in white, and I then press Enter, instead of analysing that (0,1,1) to (3464,254,63) partition it moves on to the next line, Linux Swap, shown there in green, and asks me if I want to write to that, which I don't.

In an attempt to understand the structure of what I'm trying to do, I've prepared a small spreadsheet from earlier details extracted from my partman log. Not sure how much it can help, but I'm attaching it here as "summary.ods", anyway.

I'm also attaching "Mount-error.png" showing the exact result I get when I try to mount sda1 on my live BootMed CD platform. This makes me wonder whether I'm trying to fix a partition table error or a file system error, or both.

[Sleepy-zz-John]

Since my last posting, I've discovered that TestDisk will only write table entries that are showing green, so I've now been able to make some of the other lines green by changing them to show up as P for primary.

But having re-written 4 lines into a new table, the problem I have now seems to be that the sda numbers on my newly-written entries don't coincide with the sda numbers I had before. Compare the numbers in my latest result "Write1-4.png" with the original sda numbers in "Summary.ods".

Also I'm now missing the entry for the extended LBA part of my DATA that was originally on sda3.

So my questions now are:
a) How do I write a new sda3 line into the currently saved table to match the original sda3 line I had?
b) How do I edit TestDisk's currently saved sda3 line to make it show up as sda5, and generally change the listing order so that all the sda numbers match their previous allocations?

[wasteinc]

I have the same problem with my swap file (after suspending, it gets full and then in random times it empties and then fills again)

I have 4GB of RAM and I certainly dont wont to use my swap. If I turn it off completely would this be wrong? I think it will save me a lot of trouble with suspending