Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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>
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.
<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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.