On Mon, Feb 03, 2014 at 07:45:39PM +0000, 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, Curtis Gedak wrote: > > Which alignment option did you choose? > (MiB, Cylinder, or None. Default is MiB) I left it at the default. > Would you be able to provide the output from the following two commands? > > sudo fdisk -l -u Note I've finished repartitioning the drive since this bug report.[1] Disk /dev/sdc: 2000.4 GB, 2000398933504 bytes 81 heads, 62 sectors/track, 777982 cylinders, total 3907029167 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00023c76 Device Boot Start End Blocks Id System /dev/sdc1 2048 3907029166 1953513559+ 83 Linux > sudo parted /path-to-your-device unit s print Model: Seagate GoFlex Desk (scsi) Disk /dev/sdc: 3907029167s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 2048s 3907029166s 3907027119s primary On Mon, Feb 03, 2014 at 07:45:39PM +0000, Mike Fleetwood wrote: > https://bugzilla.gnome.org/show_bug.cgi?id=723543#c2 Based on that, I managed to recreate the issue as follows: $ truncate -s 2000398933504 /tmp/loop0.img $ sudo losetup -f --show /tmp/loop0.img /dev/loop0 $ echo -e "o\nn\np\n\n\n\nw\nq\n" | sudo fdisk /dev/loop0 [...] $ sudo partprobe -s /dev/loop0 /dev/loop0: msdos partitions 1 $ sudo fdisk -l /dev/loop0 Disk /dev/loop0: 2000.4 GB, 2000398933504 bytes 81 heads, 62 sectors/track, 777982 cylinders, total 3907029167 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xcf75b6a0 Device Boot Start End Blocks Id System /dev/loop0p1 2048 3907029166 1953513559+ 83 Linux $ sudo mkfs.ext4 -q /dev/loop0p1 $ sudo gparted /dev/loop0 * Select the partition * Click "Resize/Move" * Drag the left end of the slider to the right. This time it says free space preceeding is 1556706, size is 351022, free space following is 0, align is MiB. * Hit "Ok" and confirm. Then apply. * The output is roughly the same as in the original attachment: the resize2fs step reports the new filesystem is 89861654 blocks, the partition shrink takes it down to 718893231 sectors, then the e2fsck complains that the filesystem is 89861654 blocks while the device is only 89861653. Then I removed the loop device, deleted /tmp/loop0.img, and redid the above except I typed "1600000" in the free space before box instead of using the slider. e2fsck again failed saying the filesystem was 78778390 blocks while the partition was 78778389. And I did it again a few more times, same sort of results each time. [1]: The plan was to shrink the existing filesystem, move it to the end of the disk, create a new dm-crypt partition taking up most of the disk, copy everything from the old to the new, delete the old, expand the new to use the whole disk again, and then at some point run zerofree or the like over it. gparted was supposed to make it so I didn't have to worry about matching filesystem blocks and disk sectors when shrinking and moving... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
