Changing SSD partition size

[whatthefunk]

I currently boot off a 60 GB SSD which has 20 GB allocated for the OS, 20 GB for /home, and the rest for dual booting. I would like to knock off 5-10 GB from the first partition and put it over to the /home partition...is that possible?

[Snowhog]

Yes.

I have to assume that the first partition is being used for root ( / ), and that the second partition is your /home. On that assumption, you will just resize the first partition, making it smaller -- shrinking from the right end. This will create 'unused' space between the end of the resized root partition and the start of your /home partition. The next step is composed of two parts: 'Moving' the /home partition to the end of the /root partition, and resizing it -- growing it from the end.

[whatthefunk]

I thought so. Just wanted to check. Thanks.

EDIT: Cant figure out how to do this using gdisk. Anybody know?

[Snowhog]

Do you have a CD/DVD drive in your PC? If 'yes', do yourself a favor and download/create a GParted LiveCD and boot using it and do your partition management from it.

[whatthefunk]

Do you have a CD/DVD drive in your PC? If 'yes', do yourself a favor and download/create a GParted LiveCD and boot using it and do your partition management from it.

I went ahead and tried with gdisk because I like to use GPT partitions. Did something horribly wrong because it wouldnt boot on restart. Maybe remounted everything wrong?? Not sure. Had to do a fresh install. Out of curiosity, I would really like to know how to do this using gdisk for future reference.

[james147]

Out of curiosity, I would really like to know how to do this using gdisk for future reference.

Its not easy with gdisk as it doesn't inherently support resizing of partitions and from what I can tell and so the only way is to delete the old partition and create a new on starting at the same point, but that doesn't move the data around on it. So this works best for growing a partition.

This is the one think I have found harder to do on command line then in a gui and am still looking for a nicer way to do it.

[SteveRiley]

gdisk doesn't have a method for resizing partitions. Gparted is usually the best tool for accomplishing what you've described. I'm curious what borked your system, though...can you retrace your exact steps?

Now, something more interesting to ponder, is this. It's entirely possible to delete and recreate a partition without damaging the file system or its data, using a combination of gdisk to delete/recreate partitions and resize2fs to change file system sizes. This is a tricky maneuver, and one slip at the CLI can render your data inaccessible.

Let's work through a scenario. Here's a sample partition table:

steve@x1:~$ [B]sudo gdisk /dev/sdb -l[/B]
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 15625008 sectors, 7.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2A292DAB-A13B-4E8D-9AD4-C1B1DE218B9B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 15624974
Partitions will be aligned on 2048-sector boundaries
Total free space is 944877 sectors (461.4 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         4196351   2.0 GiB     8300  Linux filesystem
   2         4196352        12584959   4.0 GiB     8300  Linux filesystem
   3        12584960        14682111   1024.0 MiB  8300  Linux filesystem

Let's imagine that we want to shrink /dev/sdb1 from 2.0 GiB to 1.5 GiB, and then expand /dev/sdb2 to fill the free space. I like to perform these kinds of operations using sector sizes, because these tools have inconsistent meanings for KB/KiB and GB/GiB. Assuming 512-byte sectors, we arrive at 3,145,728 sectors for 1.5 GiB thusly: 1.5 * 1024 * 1024 * 1024 / 512

First, we shrink the file system on /dev/sdb1:

steve@x1:~$ [B]sudo e2fsck -f /dev/sdb1[/B]
e2fsck 1.42.4 (12-Jun-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb1: 11/131072 files (0.0% non-contiguous), 25388/524288 blocks

steve@x1:~$ [B]sudo resize2fs -p /dev/sdb1 3145728s[/B]
resize2fs 1.42.4 (12-Jun-2012)
Resizing the filesystem on /dev/sdb1 to 393216 (4k) blocks.
Begin pass 3 (max = 16)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/sdb1 is now 393216 blocks long.

(resize2fs wants us to run e2fsck first; also note the s after the number, which simply indicates that we're using 512-byte sectors in the computation here; actual physical sector size is irrelevant)

Next, start gdisk. Print the partition table and note where /dev/sdb1 starts. Delete /dev/sdb1. Recreate /dev/sdb1, using the following parameters:
* starting sector: the value we just noted
* ending sector: +3145728 (note: this is exactly the same value we computed for use with resize2fs)

Print the partition table again to verify. Finally, write the changes to disk. Here's my walkthough:

steve@x1:~$ [B]sudo gdisk /dev/sdb[/B]
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): [B]p[/B]
Disk /dev/sdb: 15625008 sectors, 7.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2A292DAB-A13B-4E8D-9AD4-C1B1DE218B9B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 15624974
Partitions will be aligned on 2048-sector boundaries
Total free space is 944877 sectors (461.4 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         4196351   2.0 GiB     8300  Linux filesystem
   2         4196352        12584959   4.0 GiB     8300  Linux filesystem
   3        12584960        14682111   1024.0 MiB  8300  Linux filesystem

Command (? for help): [B]d[/B]
Partition number (1-3): [B]1[/B]

Command (? for help): [B]n[/B]
Partition number (1-128, default 1): [B]1[/B]
First sector (34-15624974, default = 2048) or {+-}size{KMGTP}: [B]2048[/B]
Last sector (2048-4196351, default = 4196351) or {+-}size{KMGTP}: [B]+3145728[/B]
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): [B]p[/B]
Disk /dev/sdb: 15625008 sectors, 7.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2A292DAB-A13B-4E8D-9AD4-C1B1DE218B9B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 15624974
Partitions will be aligned on 2048-sector boundaries
Total free space is 1993453 sectors (973.4 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         3147775   1.5 GiB     8300  Linux filesystem
   2         4196352        12584959   4.0 GiB     8300  Linux filesystem
   3        12584960        14682111   1024.0 MiB  8300  Linux filesystem

Command (? for help): [B]w[/B]

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): [B]y[/B]
OK; writing new GUID partition table (GPT) to /dev/sdb.
The operation has completed successfully.

We've now decreased the partition size of /dev/sdb1 and also the file system on that partition.

Next, we need to expand the /dev/sdb2 partition and also the file system it contains. Because we're expanding from the beginning, we can't use gdisk and resize2fs -- the man page for resize2fs warns against recreating a partition on a different starting sector. Essentially, we need to "slide" the file system in /dev/sdb2 from its current location to the beginning of the partition. This involves rewriting inodes and other parts of the file system structure, and none of the utilities in e2fstools can do this. It's possible to slide the partition in chunks using dd, but we have to be extremely careful when doing this. Each slide must be precisely performed:

1. create /dev/sdb4 in the space between 1 and 2
2. dd precisely 0.5 GiB of data from 2 to 4
3. move the start of 2 to the "right" by precisely 0.5 GiB
4. extend 4 to the "right" by precisely 0.5 GiB
5. dd precisely 0.5 GiB of data from 2 to 4, specifying the starting offset to be one sector past the end of step 2
6. repeat steps 3 through 5 (changing the starting offset each time) until 2 contains everything except the final 0.5 GiB chuck
7. delete partition 2
8. change the end of partition 4 to what was the end of partition 2
9. renumber 4 to 2

As you can imagine, there's a fair amount of risk involved. This is where a GUI tool like GParted really helps.

[Qqmike]

Jeezus Steve. Blow me away, baby.
(Should I include this as an application of dd in my dd how-to? Naw, better not.)

[SteveRiley]

I had read about these kinds of capabilities before, but never really had the need to investigate. I figured now was as good a time as any to test the safety of manipulating partitions without damaging the data, and reporting my findings. Indeed, the same files I placed in /dev/sdb1 before the resize operation did indeed remain intact. So long as one is careful, editing partition tables and changing the ends of partitions and filesystems is safe. So taking the time to post the above was as much of an educational exercise for myself as for anyone else who might want to try but wanted to see a step-by-step. Besides, what else are lazy Sunday afternoons for?

I agree what you wrote about dd, though. Sliding a partition with dd is totally a hack, and a very dangerous one at that.

[whatthefunk]

gdisk doesn't have a method for resizing partitions. Gparted is usually the best tool for accomplishing what you've described. I'm curious what borked your system, though...can you retrace your exact steps?

Unfortunately, I backed my system up just before attempting this so my bash history file doesnt include the commands I used to bork my system. I too used resize2fs but I didnt use sector size, just used GB so Im guessing that this may have been my fatal error. I should have thought of that because Ive noticed that different programs provide different partition size readings. Crap. Oh well. Thanks for posting this Steve.

[Qqmike]

and I'm sure you caught/know this, whatthefunk: there's a time to use 1000 (MB, GB) and a time to use 1024 (MiB, GiB).

[whatthefunk]

and I'm sure you caught/know this, whatthefunk: there's a time to use 1000 (MB, GB) and a time to use 1024 (MiB, GiB).

Yeah. Really dont know what I was thinking.....

[SteveRiley]

Unfortunately, I backed my system up just before attempting this so my bash history file doesnt include the commands I used to bork my system. I too used resize2fs but I didnt use sector size, just used GB so Im guessing that this may have been my fatal error. I should have thought of that because Ive noticed that different programs provide different partition size readings. Crap. Oh well. Thanks for posting this Steve.

I would hazard two guesses at a couple things you might have done:

* It's very easy to misread gdisk's "resize partition table" command as "resize partition." I know I've made that mental swap a couple times myself.

* resize2fs can't extend a file system "to the left" -- that is, to start on a lower sector number than where it was first created. resize2fs won't stop you from trying, and indeed, it won't display an error. But the outcome is that the partition won't mount. One thing I discovered in my experimentation is that you can re-do the resize2fs and place the partition's starting sector back to its prior value, which un-borks the partition. Very handy.

[whatthefunk]

* resize2fs can't extend a file system "to the left" -- that is, to start on a lower sector number than where it was first created. resize2fs won't stop you from trying, and indeed, it won't display an error. But the outcome is that the partition won't mount. One thing I discovered in my experimentation is that you can re-do the resize2fs and place the partition's starting sector back to its prior value, which un-borks the partition. Very handy.

Ahh...this may have been the system breaker. Root is mounted on partition 1 and /home on 2. I attempted to shrink 1 and expand 2 to the left. This has definitely been a learning experience...

[SteveRiley]

From man resize2fs:

The resize2fs program does not manipulate the size of partitions. If you wish to enlarge a filesystem, you must make sure you can expand the size of the underlying partition first. This can be done using fdisk [or gdisk] by deleting the partition and recreating it with a larger size or using lvextend, if you're using the logical volume manager lvm. When recreating the partition, make sure you create it with the same starting disk cylinder as before! Otherwise, the resize operation will certainly not work, and you may lose your entire filesystem. After running fdisk [or gdisk], run resize2fs to resize the ext2 filesystem to use all of the space in the newly enlarged partition.

If you wish to shrink an ext2 partition, first use resize2fs to shrink the size of filesystem. Then you may use fdisk to shrink the size of the partition. When shrinking the size of the partition, make sure you do not make it smaller than the new size of the ext2 filesystem!