LinuxQuestions.org - fdisk: shrinking partion

- Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)

- - fdisk: shrinking partion - alignment problem (https://www.linuxquestions.org/questions/linux-general-1/fdisk-shrinking-partion-alignment-problem-4175492658/)

fdisk: shrinking partion - alignment problem

Hi,

I have a 500GB USB hard drive, which currently contains a single full-disk partition. I want to shrink this to 100GB.

I've already shrunk the filesystem using resize2fs, and am now trying to shrink the partition. However, /dev/sdb1 is currently aligned to sector 63, but fdisk wants to align the start of the new partition to sector 2048 (see below). This disk doesn't need an MBR.

Is there a way to get fdisk to stop trying to be clever and do what I'm telling it? If not, what's the best way around this? Should I go into the "extra functionality" menu, and use the b command to move the beginning of the data to 2048 (not something I've tried before)?

Code:

root@rob-laptop:~# fdisk /dev/sdb



Command (m for help): p



Disk /dev/sdb: 500.1 GB, 500079525888 bytes

255 heads, 63 sectors/track, 60797 cylinders, total 976717824 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: 0x33439e40



  Device Boot      Start        End      Blocks  Id  System

/dev/sdb1              63  976703804  488351871  83  Linux



Command (m for help): d

Selected partition 1



Command (m for help): n

Partition type:

  p  primary (0 primary, 0 extended, 4 free)

  e  extended

Select (default p): p

Partition number (1-4, default 1): 1

First sector (2048-976717823, default 2048): 63

Value out of range.

First sector (2048-976717823, default 2048): 

Using default value 2048

Last sector, +sectors or +size{K,M,G} (2048-976717823, default 976717823): +102G



Command (m for help): p



Disk /dev/sdb: 500.1 GB, 500079525888 bytes

255 heads, 63 sectors/track, 60797 cylinders, total 976717824 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: 0x33439e40



  Device Boot      Start        End      Blocks  Id  System

/dev/sdb1            2048  213911551  106954752  83  Linux



Command (m for help): x

Expert command (m for help): b

Partition number (1-4): 1

New beginning of data (1-976703804, default 63):

<rant>This sort of thing does really gall me. I thought this was Linux, not Windows. I thought we were supposed to be able to have control over our systems. I mean, Linux is supposed to be the OS which says "fine, I'll delete your entire home folder without asking 'are you sure?'." </rant>

Hopefully you have a good backup just in case.

gparted is a better tool for resizing partitions. It allows you to shrink the partition vs deleting and recreating. Newer versions of fdisk use 2048 to align with the new 4K disks and 1M boundaries.

The MBR is the first 446 bytes and starts at 0. The partition table is the next 66 bytes. The disk may not have a bootloader installed but the space is still reserved unless you are not using a partition table.

Certainly gparted is the best solution I have found - it (now) has the smarts to handle this. When this problem first started to arise some time ago, I put aside a liveCD with the older fdisk on it so I could decide how to manage things.

If you run fdisk in "DOS compatibility" mode ("c" command), the default starting location for the first partition will be at LBA 63 (the beginning of the second track).

Your suggestion to tell fdisk to move the starting location to sector 2048 would not work. fdisk never moves the contents of a partition. Your filesystem would still start where it does now at LBA 63, which is not where the new partition would start.

Thanks, rknichols, the c option was what I was looking for. And thanks for confirming my suspicions about the option to move the beginning of the data.

No, I haven't backed this data up, michaelk. I like to live dangerously ;). Seriously, though, the data on here is old backups. Wouldn't have been a disaster to lose it (the important stuff is already stored elsewhere, and it would give me an opportunity to try out some file recovery tools), and would have required even more disk shenannigans to make space to back it up.

You're probably right about gparted, but I find I have less trust in tools that make it easy to do something, but harder to tell exactly what is being done.

Glad you got it sorted out. Marking this thread "SOLVED" (in the Thread Tools, near the top of the page) would be appropriate.

Quote:

Originally Posted by Robhogg (Post 5106936)

<snip>
You're probably right about gparted, but I find I have less trust in tools that make it easy to do something, but harder to tell exactly what is being done.

One doesn't have to preclude the other. Even old Dos-based PQMagic had the ability to drop down to "ptedit". GParted, on any decent distro, live or otherwise, should likewise have that capacity. It's not binary. One can use both. It would be a sweet feature on "Expert Mode" if it was possible from selecting a menuitem to drop right to direct edit, and simply remove the step of launching a console.

Quote:

Originally Posted by enorbet (Post 5107093)

GParted, on any decent distro, live or otherwise, should likewise have that capacity.

By that definition, there are apparently no "decent" distributions, live or otherwise.

gparted is a high-level tool, and works only in high-level ways. Partition placement and size must be specified in mebibytes (power-of-2 megabytes) and decimal fractions thereof. Ever tried to figure out what decimal fraction of a mebibyte you need to enter to get a partition to start on a specific sector? (Should be easy. Let's see, with the common geometry of 255 heads and 63 sectors per track there are 7.844238 mebibytes in a cylinder, ... .) And how many digits of that fraction are needed to get it to round to the right integer? Ever tried to get gparted to move a partition whose content is opaque binary data (such as an encrypted partition)? (Hint: It won't do that.) gparted is totally the wrong tool for any forensic or recovery situation.