GNOME Bugzilla – Bug 368199
problems with manipulation of logical partitions
Last modified: 2008-06-18 19:04:58 UTC
over time people experienced problems while trying to manipulate logical partitions. Most of the times the entire partitiontable gets wiped with the following error: 'Invalid partition table on /dev/sda -- wrong signature 2c9e.' Of course the signature varies from case to case.
I agree, the program was still running, therefore it was not a "crash". Forgive me for thinking like a user and not a developer. I suppose that comes from the fact that I am a 'user' and the product I was using is a 'released' product, not a beta test. To me, like the millions of Windoze users we are trying to sell on Linux, the loss of 40 GB of data is a catastrophic event no matter what you call it. [Is the tragedy of 9/11 any less of a disaster because the perpetrator is still around to thumb his nose at us?] To me, partitions are just another step up in the data hierarchy. With the phenomenal growth of densities, manipulation of partitions needs to be done as easily and confidently as that which is presently done with files and directories. As I paraphrased in an earlier post, this program is of the utmost importance to the future of computing. Reiserfs be damned. If we can't confidently and easily resize and move whole partitions of data, it really doesn't matter how efficiently we store it or retrieve it. I may be an 'early innovator' but I haven't thought of myself as a 'tester' since the 1970's. Yes, it was only 20 GBs of personal data a few weeks ago, but next week it will be Terabytes of serious business data that's at risk. As I said before, I'll do whatever I can reasonably do to help you but I'm not an experienced 'tester', I'm an end user who's getting very used to seeing eyes roll when he looks over the remains of his data and says, '...it didn't work!'.
I've looked at the foregoing and realized that it is not very constructive. I do want to help if I can. Last night I had occasion to move and resize a couple of partitions. I used your program but documented each step carefully as it was similar to some moves that had caused crashes, er... program anomalies of some sort, in the past. It took about an hour of extra time to learn how to document what I was doing and prepare for the capture of data should I have a problem. (Although you sent me that information, none was included in the download and it's not exactly intuitive for someone like me who has not done any testing in over ten years.) So I documented each step but of course the program worked perfectly. I have attached a two page history of my relationship with computing and how I use my computers. Maybe it will help you to understand what I can and can't do to help you.
Created attachment 75955 [details] Comments from Winger on personal history and use of computer.
thanks very much for all your work, i'll go over it asap :)
wow! i just read your backgroundstory, pretty heavy stuff ;) I don't think you qualify as 'just an enduser' :) Nevertheless you are right, it should just work and that's what we're working on. For now i will consult with the libparted people about this bug (it starts to be a common problem) and see what they have to say about this. i'll keep you posted!
Created attachment 75994 [details] gparted_details.htm a reallife example of the error mentioned in the bug. The message is at the very end of the file.
There may be a clue in the attachment. The 16th data line says: "Superblock last mount time is in the future. Fix? yes" In the documentation I did of my successful operation I noticed the same message. However, I can't come up with any reason why the last mount time should be incorrect. Is it possible that the program not in proper alignment with the "Superblock", (whatever that is)? If you can believe the "yes", the program is rewriting some data at this point, possibly incorrectly. Unless I am misunderstanding something, (highly likely), this could be the initial cause of the invalid partition table.
Created attachment 76026 [details] Example #1 of 'last mount time is in the future' This operation completed successfully but the referenced message at data line 16 appears to be incorrect. My system clock is set with NTP and the last mount time should be correct.
Created attachment 76028 [details] Example #2 of 'last mount time is in the future' Again, the same message on data line 16. This and the preceding are the only files I saved. Both contain the same message and in neither case are they reconcileable with what I believe to be true.
This could mean there's something wrong with the time/date stuff on the livecd, but it's highly unlikely this has anything to do with this bug, because the bug has nothing to do with filesystems, but with partitions. thanks anyway :)
I didn't intend to sacrifice my laptop's 80 GB hard-drive to the cause of solving this dilemma but that appears to be what I have done! The hard-drive did have twelve partitions but now reports none. There were two small partitions adjoining one another that I wanted to resize such that one would be larger and the other smaller, the two still occupying the same total space. There wasn't any data of any consequence in either of them so I didn't care whether it worked or not. In fact, I was kind of hoping it wouldn't work so I would have something for you to work with. Well, I got my wish but instead of just losing those two partitions, I lost the whole partition table. The disk now displays as empty but I know its not. I have shut the computer down to make sure that the disk is not accessed. (Your program is the last thing that accessed the disk.) I need help. I badly need to recover that partition table, or at least most of it. I hope that you or someone you know can help me. Fortunately I have some documentation this time. See the following attachments.
Hi, don't worry, it's easy to recover a lost partitiontable :) boot the gparted livecd and use 'testdisk', it's pretty self-explanatory and works just fine. and yes, this bug wipes complete partitiontables, which makes it so scary :/ let me know if you need any more help with the recovery, but please, use our forums for that (http://gparted-forum.surf4.info/index.php)
Created attachment 76078 [details] Partition table as it existed before using Gparted This is based on memory so I hope it's correct: Partition 1 - NTFS - Windows XP Home with the configuration changes I have made. It would be nice to get this back. There is a lot of time spent on the configuration. (There is no data of consequence.) Partition 2 - NTFS - Paging file - Easily replaceable. Partition 5 - Fat32 - This is part of the data that is shared by Windows and Linux. Important to recover this. Partition 6 - Linux Swap - Easily replaceable. Partition 7 - Ubuntu 6.06 with Gnome desktop. Lots of customization in this. I'd certainly like to get it back. Partition 8 - Shows as unknown and unused but actually is an encrypted data partition that is shared by XP and Linux. About 33 GB of it is actually in use. The backup I have for this is at least a month old. This is where my heaviest daily activity is. It probably can't be recreated in its present state. Partitions 9 and 10 - Those were the two I was trying to resize. My next step would have reformatted both of them. I don't need to recover the data from eith of them. Partition 11 - Xubuntu 6.06 with xfce desktop. This is heavily used and has lots of configuration in it. I need this back badly. Partition 12 - Boot partition. This has the grub menu and files as well as a number of configuration files, (like network) that are used by Partition 7 and 11. Like 7 and 11, there's a lot of configuration in this and I would like to have it back.
Created attachment 76079 [details] Screen shot of partition table before applying first step.
thanks, but the most important thing would be the details. Do you have them around?
Created attachment 76080 [details] Screen shot of partition table after successfully applying first step. This step completed successfully so I have no detailed print-out for the step.
Created attachment 76081 [details] Screen shot of partition table just before the error operation.
Created attachment 76082 [details] Detailed listing from error operation.
Created attachment 76083 [details] Screen shot of (non-existent) partition table after error operation. Please find what is causing this and get it fixed. I nearly lost my supper when I saw this. And I desperately need someone to help me recover this.
thanks for the info, the screenshots are not necessary :) About finding and fixing.. we do our best, but you have to realize we all do this in our spare time and are busy with other things as well. Personally i hardly have time to answer bugmail atm.. as for recovering, you should use 'testdisk' as i already mentioned in c12. It really works very well and should recover your partitiontable within a matter of minutes :) good luck!
hmmz, i can't reproduce it on my usb-stick. I'll see if i can find another portable HD.
nope, no luck. I tried several operations on logical partitions on another disk and still nothing happened. Could you try to reproduce the error again and post the details (not the screenshots, just the details :) ) ? thanks NB. any luck with testdisk?
Created attachment 76087 [details] gparted_details.htm another (old) occurrence of this bug.
Yes, I think I have recovered. It wasn't quite as easy as you suggested. My lack of familiarity with Testdisk contributed to the time factor though. I have screenshots showing what Testdisk found if that will be any help to you. Of course you are kidding about repeating the incident. The program stopped after it had moved partition 10 but before it had increased its size. I am going to use Gparted to increase the size of that partition, but otherwise, Gparted is not going to touch that drive or any other I have until the bug is found and fixed.
One more comment. The severity should be set to 'critical'. The bug definitely causes a 'loss of data' which makes it 'critical'. (Had I been any less computer literate than I am the entire partition would have been a loss.) And the priority should be set to 'urgent'. "This bug blocks usability of a large portion of the product, and really should be fixed before the next planned release." That's Gnome's definition of 'urgent' and it definitely fits in this situation.
Warren, please try to realize it's an incidental bug. It doesn't happen very often, so the situation isn't as bad as you think. At this moment i'm not even able to reproduce it, whatever i try... About loosing data.. I and every other partitionguy out there always urge people to make a backup of important data before doing anything to your partitions... You could try to reproduce it on another (usb)disk. We need more testdata since we cannot reproduce it ourselves and this bug seems to happen on your machine quite frequently. Of course you should not try this on a disk with valuable data..
While I don't have an exact batting average for it, I would estimate that I have encountered problems with the product at least 20% of the times that I have used it. Considering the result when it fails, I would not describe it as an incidental bug. The only reason it doesn't happen more often is that I don't use the program very often and I'm extremely careful when I do use it. (I will not do anything that could leave the disk in a state where Testdisk cannot identify the beginning and end points of the partitions, as was the case in the first incident.) As I explained earlier, it is not 'machine', it is 'machines' (plural). I use your product on three different machines from three different manufacturers with three different architectures. Even the hard-drives come from three different manufacturers and the program has failed on all three systems. I have had a failure on a 20 GB from Western Digital, a 40 GB from Maxtor and an 80 GB from I don't know who, (it's in a Toshiba laptop). The smallest of those would take something like 30 CDs to back it up. (If I used single layer DVDs I could backup my smallest drive with about 5 of them. But I also have a 160 GB external drive that fortunately has not been the subject of any misfortune. It would take about 35 DVDs. That's about ten hours of backup time.) When we all used command line tools for partitioning we only used them once or twice a year. But with a gui on a live cd or usb that is supposed to be able to move or resize partitions, and with disk densities sky-rocketing, cautioning people to back up their data before partitioning is like telling someone that it's not safe to use their automobile on a public highway. It might be true, but who's going to listen? As much as I admire people such as yourself who are responsible for the incredible innovation that is taking place with free software, I am also beginning to understand why the business world is not ready to trust their data to Linux. If this were recognized as a serious problem, it would get all the attention I could give it. But since it's only an "incidental bug" that's not "as bad as [I] think", I see no reason to bother myself further with it.
That's the interesting part of the problem. Afaics it's consistent on a very small number of systems. First i thought it had to be your system, but now it seems it happens to all HD's on all your machines. Maybe it's something with your livecd? The way it was burned? There has to be a consistent factor which explains all this. Since i filed this bug i have tried to reproduce it myself on 2 different machines on 3 different disks, without success. I have asked 3 other persons to try it as well and none of them managed to reproduce it. I have looked at the source for a clue, but cannot see why it should fail. That's why i'm so interested in your case. Somehow you are able to trigger this bug in 20% of the cases. That's why i requested to try it again on an USB disk without any valuable data. In short, i do recognize it as a serious problem, but without reproduction of the error, it's very hard to fix. I simply need more data. It would be great if i could reproduce it myself, so i could trace everything step by step, but since i can't reproduce it, i have to settle for a more indirect approach. Gathering data en see if i can find a clue as to what is causing this.
Created attachment 76630 [details] another case..
Created attachment 77017 [details] and yet another
cool, i think i've got an idea :) all cases involve moving a logical partition to the left with overlap. Because we copy sector by sector i think the metadata between logical partitions gets overwritten which results in an error when reading the partitiontable. I have to go now, but i'll test it later, with this knowledge reproduction should be easier.
ok, i finally managed to reproduce the error and i've landed a fix in CVS. I'm quite sure it's fixed, but it would be nice if some of you could test the fix. Let me know if you need any help with this :)
Created attachment 77203 [details] YAF: Yet Another Faillog (nice feature bytheway). While moving a logical partition less than its size to the left.
Hey Vincent, See comment #32, this should be fixed by now, today or tomorrow i'll do a new release.
btw, drop by in IRC if you need any help with testdisk, a 100% recovery is perfectly possible.
Hello Warren and Vincent, My name is Curtis Gedak and I am the new C++ developer for GParted. From reading comment #32, it sounds like Bart fixed this bug but never got around to marking this bug as resolved. Have either of you experienced this bug since? According to the ChangeLog, the bug fix was included in version 0.3.2 of GParted. Regards, Curtis Gedak
After performing multiple move / resize operations involving overlapping regions, all of which were 100% successful, I believe that this bug has been fixed as was stated in the ChangeLog. Closing this bug as it appears to have been fixed as of GParted version 0.3.2.