GNOME Bugzilla – Bug 638634
Unable to move ext3 partition after resize on USB attached disk
Last modified: 2012-10-01 09:36:53 UTC
Created attachment 177467 [details] gparted_details.htm I needed to expand /boot ext3 partition located in /dev/sdb5 - first partition in extended section /dev/sdb3. Right after sdb5 there is ext3 sdb6 partition with debian in the same extended section (debian is not the primary system). GParted fails after resize - log is attached. The disk is accessed through SATA->USB 2.0 adapter. The connection is stable.
To further diagnose this problem, would you be able to provide the output from the following two commands (root privilege is needed)? fdisk -l -u where one of the options is a lower case "L" and not the number one. parted /path-to-your-device unit s print where /path-to-your-device is something like /dev/sdb
Unfortunately, I've already made modifications to the partitions. I can only send the table after modifications. The resize of sdb6 partition from the left failed every time until I also shrunk it from the right. I tried many times one step at a time, but didn't record the correct combination. I may try it again. I also got the feeling that batch execution of operations fail unpredictably, because operating system (Parted Magic 5.8) tries to remount USB drive after each operation and enters into race condition with GParted, but I can't prove that.
Created attachment 177964 [details] fdisk log with finally corrected partition table
Created attachment 177965 [details] parted log after some more modifications
Created attachment 177966 [details] try2.gparted_details.htm Ok. I've tried to resize sdb6 again and extend sdb5 and it failed. I attach log after failed operation. My two previous attachments illustrate initial system state. I hope there is enough information for debugging the issue.
The partition table is changed after the 2nd try, therefore I am attaching fdisk and parted logs again.
Created attachment 177967 [details] try2.fdisk-l-u.log
Created attachment 177968 [details] try2.parted-unit-s-print.log
In this state I am trying to move sdb6 to the right, but if I choose MiB alignment, GParted keeps unallocated space about 1.89 MiB between end of sdb6 and start of sdb9. So, I am forced to use cylinder alignment. The same problem is with resizing sdb5 as a second batch operation. This batch failed immediately on the first try to launch it. Unfortunately, I didn't save the log, but I believe "check file system" step failed, because /dev/sdb6 couldn't be opened. Now running the same batch for the second time. It didn't fail immediately and still works now being in r/o test phase of "moving partition to the right".
Created attachment 177973 [details] try3.gparted_details.htm As you may expected, batch operation failed. Attaching log and current state.
Created attachment 177974 [details] try3.fdisk-l-u.log
Created attachment 177975 [details] try3.parted-unit-s-print.log
There is still unallocated space about 1.55 MiB after sdb6.
Created attachment 177977 [details] try4.gparted_details.htm The batch operation to resize both partitions to fill available space failed. I attach only fail log, because it is quite evident that the output of other utilities will be.
Created attachment 177978 [details] try5.gparted_details.htm Seems like partitions are now resized as required, but on the way it failed one more time. Seems like GParted is unable to lock USB device from the system.
It appeared that after the last operation filesystem is not resized accordingly to partition size and GParted doesn't warn me about this. I filled bug #639204
Hi techtonik, From the activity in this bug report I can see that you are keen to resolve the issue and have made several attempts. If you wish me to help with this problem, then I need you to stop all of these attempts. Each one can change the situation and makes it more difficult to determine what has happened. As such I will only address your last comment. If the file system has failed to grow to fill the partition, then please try the following steps to resolve the problem: 1) In GParted, select the partition which failed to grow to fill the partition. 2) Choose the menu option "Partition --> Check" 3) Apply this operation 4) Check to see if the file system has grown to fill the partition.
Your solution works to grow the filesystem, but it is not related to this bugreport, but to bug #639204. As for the subject of this particular bug, it is about reason why this grow operation and all previous operations failed. Please review this problem from the start. I've added information incrementally starting from comment 3 on purpose, so that you can inductively figure out what's going on. I feel that this specific problem is only related to USB devices.
Are you using GParted from a Live CD or USB drive? If so which Live CD and version? The error message "No such file or directory while trying to open /dev/sdb6" implies that somehow the device entry no longer exists. Many other subsystems play a role in how device entries are maintained so it is important to know which which GNU/Linux distribution is being used. From the fdisk and parted output listings, it appears that you have partition /dev/sdb9 set up under Logical Volume Management. Is this true? If so, are the background processes for Logical Volume Management running while you are trying to resize /dev/sdb6?
(In reply to comment #19) > Are you using GParted from a Live CD or USB drive? > If so which Live CD and version? > > The error message "No such file or directory while trying to open /dev/sdb6" > implies that somehow the device entry no longer exists. Many other subsystems > play a role in how device entries are maintained so it is important to know > which which GNU/Linux distribution is being used. I am using the same Parted Magic 5.8 as in comment 2. Booted from microSD card into memory (the first option). microSD is imaged with UNetbootin. No idea on which distribution Parted Magic is based on. Perhaps 5.8 version info in news can have details. http://partedmagic.com/doku.php?id=news > From the fdisk and parted output listings, it appears that you have partition > /dev/sdb9 set up under Logical Volume Management. Is this true? Yes. > If so, are the background processes for Logical Volume Management running while > you are trying to resize /dev/sdb6? I don't know. I didn't access the USB HDD partitions. Extended partition with LVM wasn't marked with lock in GParted. Only LVM itself was marked with warning sign. Some time ago I've already killed another USB HDD with GParted, that's why I am not inclined to think that LVM is the reason.
With an MSDOS partition table, partitions /dev/sdb5 and higher are logical partitions. These logical partitions are represented as a chain from one partition to another. Consequently a change to one logical partition has implications to the other logical partitions in the chain. This interaction among the chained partitions is why one cannot delete a lower numbered logical partition if a higher numbered logical partition is active. By the word "active", I mean the partition is somehow in use (i.e., mounted, active swap, or active LVM). The GParted code does not contain logic to determine if a partition is "active" due to an active LVM partition. It can only determine if the partition is mounted or if swap is active on the partition. Hence this is why I think that the presence of LVM on this drive is likely to be related to the problem. If LVM is active, then this could prevent GParted from having the GNU/Linux kernel utilities properly read the changed partition table and update the device entries. Are you using the LVM partition on this drive, or is this something you can remove and then re-try your resize operation? This would help to determine if LVM is a factor in this problem.
LVM is a big PITA for me, because it is absolutely impossible to fetch data from it on Windows system. But I can't remove this partition right now, because there is a lot of data, which I physically can't copy to other part of the disk. The only thing I can do right now is to boot into Parted Magic with this USB HDD plugged in, and check that LVM is not active swap, and not active LVM (I believe we've already figured out that it was not mounted). But you need to tell me how to check.
My assumption is that LVM would require some type of background process to provide access to the logical volumes inside the physical volumes. Unfortunately I do not know what exactly how this works and was hoping that someone that uses LVM would know more than me. :-) Perhaps you could try the lvdisplay command to see if it works. That might give us a clue as to whether LVM is active or not. A bug report exists for adding LVM support in case this helps you with this determination. https://bugzilla.gnome.org/show_bug.cgi?id=160787
@techtonik, would you be able to try using GParted Live instead of Parted Magic? The reason I for this request is upon reviewing the log file in the first post it appears that the device entry for /dev/sdb6 was not created. This is a function of components in the underlying GNU/Linux operating system. In our forum we received a similar report and it appears that the problem occurs with Parted Magic only.
Unfortunately, I can't risk experimenting with this HDD right now. Ping me again in a few weeks.
techtonik, ping, do you have any update for the bug ?
Well, I didn't want to risk the data or wait USB process to complete. Now I mounted it as ordinary disk in Ubuntu and tried to shrink and move the last partition. It failed again.
Created attachment 216573 [details] fail.png
Created attachment 216574 [details] fail details
Partition table: Number Start End Size Type File system Flags 1 2048s 3074047s 3072000s primary ntfs diag 2 3074088s 55119014s 52044927s primary ntfs 3 55119015s 488392064s 433273050s extended 5 55119078s 56179304s 1060227s logical ext3 boot 6 56179368s 76437269s 20257902s logical ext3 9 76437271s 97754901s 21317631s logical lvm 7 97755588s 102253724s 4498137s logical linux-swap(v1) 8 102253788s 484197595s 381943808s logical ext3
GParted 0.11.0
techtonik, as per comment #24, would you be able to try using the latest version of GParted Live? Currently the most recent release of GParted Live is 0.12.1-5 which includes a patch for a problem with overlapping partitions. http://gparted.org/livecd.php The reason I am asking you to try GParted Live is because many other distributions contain older versions of GParted that do not contain the most recent patches.
No. Unfortunately I don't have any more time to test this stuff manually as I couldn't wait anymore to fix it. But I can help to reproduce my settings for the test suite. Is there a test suite for GParted?
Hi techtonik, Thank you for your persistence with this bug report. Since the original report was filed, you have encountered several problems: 1) When the bug report was first opened, the gparted_details.htm log file indicated the following problem: No such file or directory while trying to open /dev/sdb6 My suspicion was that this problem was related to underlying components in the distribution (Parted Magic in your situation). Based on the log in comment #29, I can see that the problem is now in a different area. Hence the original problem of this bug report appears to have been addressed, at least with your Ubuntu Live CD. 2) Another piece of the problem had to do with GParted not detecting the active/inactive status of LVM partitions. This can cause problems with logical partitions due to the way one partition is chained to another partition. Since the time of the bug report, this deficiency has been addressed. See Bug #160787 - Add read-only support for LVM PVs 3) The latest piece of the problem involved overlapping partitions. A recent patch to GParted deals with overlapping partitions. See bug #661744 - Ensure Align to MiB does not overlap following partition Hence I believe that GParted 0.12.1 will get past this problem. > But I can help to reproduce my settings for > the test suite. Is there a test suite for GParted? At the moment there is not a test suite for GParted. Discussion has begun on this in the GParted Forum, but we are a long, long way off from an actual implementation. Idea for Automated Testing of GParted http://gparted-forum.surf4.info/viewtopic.php?id=16432 It could help if you could run the following command and provide the output file: sudo sfdisk -d /path-to-disk-device > device-mbr.out Where /path-to-disk-device is something like /dev/sdb In conclusion, I can appreciate that you no longer have time to manually test if this problem is resolved. My personal thoughts are that the original problem is solved since it did not occur with your Ubuntu Live CD. Also the subsequent problems have had fixes to address these areas as well. If you have no more time to test this problem, then we should close this bug report. I am okay with closing it as "INCOMPLETE", though personally I do think that GParted Live 0.12.0-5 addresses all of the problems listed in this bug report. Of course without a final test we will never know for sure.
Oops, typo on the last version. It should have read: ... think that GPArted Live 0.12.1-5 addresses all ....