On 2/5/2014 12:47 PM, Curtis Gedak wrote:
Further, by undoing the following commit, the resize/move
operation proceeded past the failed e2fschk operation. :-)
Shrink file systems to exact size (#701075)
On 14-02-05 11:14 AM, Phillip Susi wrote:
I believe that -1 was masking the real error, which is in the
partition resize code, since the new size of the partition is not an
even multiple of 4k. The end sector also is not aligned to a 1 MiB
boundary.
Good catch Phillip.
This operation is a
Hi Anomie,
Thank you for your further investigation and for posting the steps you used.
By using the steps Mike first published and you outlined in detail, I
was able to recreate the problem you experienced.
Further, by undoing the following commit, the resize/move operation
proceeded past
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/5/2014 1:14 PM, Phillip Susi wrote:
I believe that -1 was masking the real error, which is in the
partition resize code, since the new size of the partition is not
an even multiple of 4k. The end sector also is not aligned to a 1
MiB
On 14-02-05 11:28 AM, Curtis Gedak wrote:
On 14-02-05 11:14 AM, Phillip Susi wrote:
I believe that -1 was masking the real error, which is in the
partition resize code, since the new size of the partition is not an
even multiple of 4k. The end sector also is not aligned to a 1 MiB
boundary.
On Wed, Feb 05, 2014 at 01:14:23PM -0500, Phillip Susi wrote:
The end sector also is not aligned to a 1 MiB boundary.
The explanation for that seems simple enough: this drive itself is not a
multiple of 1 MiB in size, the partition was using the whole drive, and
I never told gparted to change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well that explains the alignment issue and is probably fine then. I
am attaching a patch to the upstream bug report to fix the incorrect
rounding. If it looks good to you Curtis, I'll apply it to the debian
package and get it uploaded tonight and
Because this problem would affect all GNU/Linux distributions running
GParted, I have created an upstream bug.
The relevant upstream bug report is:
Bug 723543 - Shrink ext2/3/4 results in attempt to set partition smaller
than file system
https://bugzilla.gnome.org/show_bug.cgi?id=723543
Hi Anomie,
Can you confirm the version of Debian you are using as my attempt to
re-create the bug on my normal distribution didn't find an issue.
https://bugzilla.gnome.org/show_bug.cgi?id=723543#c2
Thanks,
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
Hi Anomie,
I too have been unable to recreate the problem you experienced. In
addition to Mike's question would you be able to provide answers to the
following?
Which alignment option did you choose?
(MiB, Cylinder, or None. Default is MiB)
Would you be able to provide the output from
On Mon, Feb 03, 2014 at 07:45:39PM +, Mike Fleetwood wrote:
Can you confirm the version of Debian you are using as my attempt to
re-create the bug on my normal distribution didn't find an issue.
I'm using unstable. gparted version 0.17.0-4.
On Mon, Feb 03, 2014 at 02:02:34PM -0700,
Hi Anomie and Phillip,
There was a recent change in GParted 0.16.2 that is directly related to
resizing ext2/3/4 file systems. Specifically the change no longer
subtracts 1 kiB from the file system size which would have prevented
this problem from occurring.
The relevant commit is:
Shrink
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/02/2014 12:35 PM, Curtis Gedak wrote:
Hi Anomie and Phillip,
There was a recent change in GParted 0.16.2 that is directly
related to resizing ext2/3/4 file systems. Specifically the change
no longer subtracts 1 kiB from the file system
Hi Phillip,
With this problem recently cropping up, I do think that restoring the
code back to the way it was will fix this problem.
The reason is that the file system will be resized slightly smaller.
Then it will fit within the same partition size. In other words it is a
different way
Initial reaction is that these days it is unusual to have an odd
number of sectors in a partition. I guess cylinder or no alignment
was used, rather than the default MiB alignment.
I'll have a closer look over the next day or so and see if I can work
out what's going wrong.
Mike
(For my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/02/2014 04:24 PM, Mike Fleetwood wrote:
Initial reaction is that these days it is unusual to have an odd
number of sectors in a partition. I guess cylinder or no
alignment was used, rather than the default MiB alignment.
Yes, the
Package: gparted
Version: 0.17.0-4
I tried to shrink-and-move a partition on an external hard drive. It
seems that gparted shrunk the parition to 93768726 4K blocks, but then
resized the parition to only 750149807 512-byte sectors (93768725.875 4K
blocks). The post-shrink e2fsck then errored out
Yikes, looks like gparted has an off by one: it set the partition size
one sector two small. Do you have any thoughts on this Curtis?
On 01/31/2014 02:16 PM, ano...@users.sourceforge.net wrote:
Package: gparted
Version: 0.17.0-4
I tried to shrink-and-move a partition on an external hard
18 matches
Mail list logo
