View previous topic :: View next topic |
Author |
Message |
Marcih Apprentice
Joined: 19 Feb 2018 Posts: 213
|
Posted: Wed Sep 16, 2020 7:40 am Post subject: Best way to resize root partition? |
|
|
I'm currently considering installing another operating system alongside my Gentoo install (trying out Hackintosh, to be specific) and my ext4 rootfs partition spans the entire disk: Code: | Number Start End Size File system Name Flags
1 1.00MiB 129MiB 128MiB fat32 boot boot, esp
2 129MiB 114472MiB 114343MiB ext4 OS | What would be the best way to shrink a partition? Although I may opt to just buy another SSD since this one is almost half full, I would still like to know how to correctly deal with something like this. If it were my /home, I would simply "cp -a" all the contents to another disk, delete all the partitions, redo them how I want and "cp -a" everything back (is there a better way for that too?), but rootfs is probably more complex than that.
Should I be creating a stage4? What about setting up LVM partitions, should I be doing that to simplify this process for myself in the future? _________________
Bones McCracker wrote: | It wouldn't be so bad, if it didn't suck. |
NeddySeagoon wrote: | The problem with leaving is that you can only do it once and it reduces your influence. |
|
|
Back to top |
|
|
alamahant Advocate
Joined: 23 Mar 2019 Posts: 3926
|
Posted: Wed Sep 16, 2020 9:29 am Post subject: |
|
|
Hi,
You can use resize2fs
Boot to a livecd and run
Code: |
e2fsck /dev/xxxx
resize2fs /dec/xxxx <new-size>
|
If it were on top of lvm you could do this online at some cases ie not needing unmounting or using livecd.
Please note that you can NOT shrink xfs filesystems.
Also for creating copies NEVER use "cp"
Use rsync instead.
Please have a look at
https://wiki.archlinux.org/index.php/Rsync#Full_system_backup
|
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22859
|
Posted: Wed Sep 16, 2020 4:17 pm Post subject: |
|
|
Strictly speaking, you can resize the root partition live, including shrinking it. Shrinking it like this will almost certainly destroy the filesystem. What you want is to resize the root filesystem, then resize the partition containing that filesystem. During the time that the filesystem is completely unmounted, you can have the partition be smaller than the filesystem, but the filesystem is not usable during this time (and will likely fail to mount). The only reason to do it is if you make a mistake, which you can correct if you catch it in time. Concretely, I would do as alamahant suggests (with some expansion):- Reboot to a livecd. To shrink a filesystem, it must not be mounted. The easiest way to unmount the root filesystem is to be running a livecd. This is noteworthy because for some less critical filesystems, you may be able to stop enough services that the filesystem can be unmounted while the system is running.
- e2fsck the filesystem, as alamahant said.
- Shrink the filesystem to the target size.
- Shrink the partition to the target size. If in doubt, you may wish to shrink the filesystem too far, then regrow it later. For example, shrink the filesystem to 9.8G, shrink the partition to 10G, then grow the filesystem to fill the tail. This is not necessary for correct operation, but it is cheap, and may be easier than worrying about whether the tools exactly agree on the interpretation of the sizes you give.
- Be sure that the kernel reloads the partition table. It may refuse if the device is busy. If you are using a livecd, the device should not be busy.
- e2fsck the filesystem again. This should be clean. If it is not, panic.
- If you chose to excessively shrink the filesystem, run resize2fs here to grow it back to fill the available space.
- Run e2fsck again, just to be very cautious. This also should be clean.
- Mount your filesystem from the livecd, just to verify that it mounts correctly.
- Unmount and reboot back into your system
If you were using LVM, all the same principles would apply, but you would use LVM tools instead of partition editing tools for the step where you resize the block device. |
|
Back to top |
|
|
halcon l33t
Joined: 15 Dec 2019 Posts: 649
|
Posted: Mon Dec 28, 2020 11:25 am Post subject: |
|
|
Hu, thanks for this tutorial! I tried it out in practice tonight. The root filesystem, shrinked from 500GB to 60 GB, boots fine; its number of files (reported by e2fsck) didn't change.
Hu wrote: | [*]Shrink the partition to the target size. If in doubt, you may wish to shrink the filesystem too far, then regrow it later. For example, shrink the filesystem to 9.8G, shrink the partition to 10G, then grow the filesystem to fill the tail. This is not necessary for correct operation, but it is cheap, and may be easier than worrying about whether the tools exactly agree on the interpretation of the sizes you give.[*] |
Special notes on this:
Yeah, I tried to calculate how one size corresponds to another, and calculated it in a wrong a way, and the filesystem turned out bigger than the shrinked partition I couldn't make the filesystem smaller and e2fsck was always dying... The solution was to just re-run parted with a bigger size; it made no harm to the filesystem; after that e2fsck wasn't showing errors anymore and I could change the filesystem size again; I found the corresponding sizes:
(parted) resizepart <devicenumber> 65GB with this devicenumber first block located at 538MB = resize2fs <device> 61475M = 59G in df -h (when mounted). _________________ A wife asks her husband, a programmer:
- Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?
He comes back with 6 cartons of milk.
- Why did you buy 6 cartons of milk?
- They had eggs. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|