Posts tagged resize2fs
These are some rough notes for colleague of mine, on how to make more swapspace available and resizing partitions in general. The workflow highly depends on the previously existing layout. Here's a shot on a manual on how to approach this.
This is mostly written from memory, so bear with me if you stumble upon errors. No guarantees for nothing below this line.
do you use XFS? or do you REALLY need another swap partition, when you don't have unpartitioned space?
In case you need to resize a partition, as you do not have unpartitioned space available, you cannot enlarge the swap partition or add a second one, if you cannot shrink the filesystem (i know that's the case with XFS) on the partition which you want to shrink. Shrinking partitions is more like deleting the currently available partition and recreating it, only smaller. (Linux lets you do that, even if you make the partition smaller then the filesystem that should be in there, rendering the system unbootable in case you do this. Don't worry, it can be fixed by recreating the old partition schema, so you better backup the information good.)
If the stuff above is the case, you need to create a swapfile and use that. Of course you need enough free space on the filesystem.
There should not be a speed difference from what I heard (and honestly I am too lazy to test that), if you have enough free space in your filesystem, create the file with
mkswap it and fix
Enough tutorials are on google, this approach is the easiest, hands down.
But let's go on.
how does the system boot: does it use BIOS or UEFI?
- BIOS -> can work with either a MBR or a GPT
- UEFI -> needs a GPT, using a MBR won't work
Also UEFI needs a bios boot partition. Basically:
- first partition is like 300m in size
- with a fat32 file system
espflags (sometimes also called
bios boot partition)
- is mounted likely to
/boot/efiin your linux installation
The rest is as usual, like you can have a separate boot partition housing the
/boot mountpoint, or just using another large partition for
/ and everything else directly.
how is the partitioning info saved
- MBR -> 4 primary partitions are maximum, or use the 4th one as an extended partition, which points to further partitioning info somewhere else.
That's also the reason why you might have
/dev/sda5 after a fresh install.
- sda1 = primary partition
- sda2 = primary used as extended partition
- sda5 = first logical partition
The MBR is located on the first sector of a harddisk and 512k in size. During the boot process the executed boot code from the BIOS scans all disk in hope of finding a MBR or GPT. Due to the MBR's structure it can only store the information for four partition entries. Information for partitions of type 'primary' is stored directly in the MBR. Partitions cannot be larger then 2t, if you need that you either have to use a GPT instead or build a logical volume via LVM out of several MBR partitions. (Ok, in that case go for GPT...)
An extended partition points to another partitioning table in a VBR. That's like a MBR, but without boot code and located in the first sector of a partition depicted in the MBR.
- GPT -> all partitions are created equal (haha), but you need a bios boot partition (see above) so it can work.
You can delete the partitions as you please, and it's autmatically backupped to the end of the disk. Its 33 logical blocks in size (like 33 * 512b or 33 * 4k in disk size, depending on block size), and uses the first 33 and the last 33 blocks of the disk. (In comparison to the MBR, which uses only the first block on a disk.)
Maximum size are about 8 zebibytes or 9 zettabytes, which should do rather fine for the storage needs you have with five nines of probability.
Keep that in mind when you want to use a sofware raid and the raid superblock shall be stored at the end of the disk, depending on the version of the software raid metadata.
backup your partitioning info!!!
Resizing partitions is more or less just deleting a partition and recreating it with a different size. This can fail, rendering the system unbootable when the partition is smaller then the filesystem it shall contain. This can be fixed by deleting the partitioning info for the partition in question, and recreating it bigger again.
Nothing is destroyed here, unless you start recreating filesystems on your newly created partitions, keep that in mind prior to panicking.
Partition info's are just pointers to start and end of a partition, so the kernel knows where to look for filesystems relative to its start.
Also the absolute sizes are important. Best in sectors, bytes do work, too.
Copy the output of the commands below into a text editor and save it somewhere (when working over
ssh) or use your smartphone camera to make a picture.
Of course pen and paper work, too, but don't do anything without this information backed up. SERIOUSLY!
These will give the partition boundaries in sectors or bytes. I prefer sectors.
parted /dev/sdX u s p
parted /dev/sdX u b p
Don't read on unless you did this.
If you still do and fuck up, you can try
testdisk, but this will not work with more complex setups.
From my experience,
testdisk only works with like a 60% chance.
highlevel overview for the general approach, the shrink and resize operations
You can only use continuous space for creating new partitions.
I.e. if you have like a 1g swap partition which you want to enlarge, followed by a 100g root partition, you can shrink the root partition, but the new unallocated space will be located at the end of the disk.
If you cannot do that, you need to use LVM.
- Create new partition in the unallocated space.
- Create physical volumes on the first partition and the newly-created one.
- Add both to a volume group.
- Create a new logical volume using the fully available space in that volume group.
- Use the new LV as swap.
This would be the work without LVM being used:
- Reset, and boot from a livedisk like grml
- To shrink, start with the innermost part, the filesystem.
- Shrink filesystem via
resize2fs. Either to a particular size, or with the
-mflag to the minimum size. This may take time.
- Delete partition of filesystem you re sized.
- Recreate partition, but larger than the filesystem. To be on the safe side, create it like 1g bigger than the filesystem, calculating that is annoying due to 1000 vs. 1024 base discrepancies.
- You may also delete partitions you still don't need anymore. If you do that, fix the
/etc/fstab, else no boot for you.
- Reboot and see if the system still works as you need it to.
- If it doesn't, look up your backup information from above, and recreate the boot and/or root partitions properly.
- If it does, create your other partition(s)/logical volume(s) and work on.
In case you have LVM in use:
- From inner parts to outside, too.
- First shrink filesystem.
- Then shrink the logical volume where the filesystem lays on, but not smaller than the filesystem was.
- Resize the physical volume, too, in case you want to create a new volume group for whatever reason.
- Adjust partition size if you need to for your desired layout.
Remember, if your system does not boot because you made partition(s) or logical volume(s) too small, that is fixable. But only as long as you did not kill any data on disk, i.e. by creating file systems.
- From outside to inside, basically the reverse from above.
- Enlarge existing partition.
- Enlarge physical volume if lvm was used, so also the volume group gets bigger. (
pvresize /dev/sdXywill use all available space.)
- Enlarge logical volumn, if lvm was used. (
lvextend -l +100%FREE /dev/mapper/<vg-lv-name>is what you want to use all available space.)
- Enlarge filesystem. (
resize2fs /path/to/device, so either
/dev/sdXywithout lvm, or
/dev/mapper/<vg-lv-name>, to use all available space.)
changing partitions via
For editing partitions
parted does work quite good, both for MBR/GPT partition tables.
gdisk also still do exist, if you want something with a fancy curses gui go with
Also there are are
sgdisk for the hacker types, according to the manpage.
- "f" -> edit MBR's
- "g" -> edit GPT's
parted commands cause immediate changes, whereas the others let you view your changes, but won't change anything until you write the changes to disk.
I really prefer using
parted non-interactively nowadays, though I cannot explain why.
All commands in as short as possible:
# show help parted /dev/sdX h # show help on particular command, may help greatly parted /dev/sda h <parted_command> # drop partition info parted /dev/sdX u s p # "unit sector print" parted /dev/sdX u s p free # "unit sector print free" parted /dev/sdX u b p # "unit byte print" # create new disklabel, read: MBR or GPT. # if you do this you basically delete the complete partitioning table # do only if you need to, and backupped the 'print' output above! parted /dev/sdX mkl msdos ## create MBR parted /dev/sdX mkl gpt ## create GPT # delete partition parted /dev/sdX rm <ID> # 1 or 2 or 3, depending which partition you want to edit # create partition # -a opt can be used with all commands listed here, but only has impact here # units can be mixedly used, like 2048s, 10GiB, 10GB, 100% parted -a opt /dev/sdX mkp # mkpart, -a opt is essential for optimal alignment! # show options parted /dev/sdX h set # enable/disable options (like boot flag) parted /dev/sdX set <ID> <OPTION> on # enable parted /dev/sdX set <ID> <OPTION> off # disable
If you can still boot, and have a shiny new partition (or logical volume) which you can use, finish:
/etc/fstab, i.e. create an entry so the system knows about the swapspace
This should be everything one may encounter. Good luck.
fter resizing the the virtual harddisk of your virtual machine, several other steps are needed so you can utilize this additional space within the VM. This will only talk about increased sizing, which will usually just work. Unlike with downsizing, which are the same steps just in reverse order, but where you can easily kill your currently still running system. Handle downsizing with very, very much care.
This guide assumes you have a single partition, which is used by LVM, where in you have your filesystem(s) in different logical volumes.
resize the partition
I have a vm with hostname called 'test', which has a single disk (
/dev/vda), with a single partition (
/dev/vda1), which is used by lvm.
LVM volume groups are usually called like the hostname (best approach I know of, so here
test), and the logical volumes what they are used for (
swap), or where they are mounted (i.e.
var_lib_vz, not shown here).
root uses ext4 as file system.
Initially the disk size was 50G and was increased to 500G.
After the disk size was increased, you can see the available space on the device:
root@test:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 253:0 0 500G 0 disk +-vda1 253:1 0 50G 0 part +-test-root 252:0 0 14.3G 0 lvm / +-test-swap 252:1 0 976M 0 lvm [SWAP]
Use a partition manager of your choice (
cfdisk for disks with an MBR,
cgdisk for disks using a GPT, or
parted if you know what you are doing.), delete your partition.
Recreate it with the maximum size, reboot.
Then it should look like this, with adjusted partition size:
root@test:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 253:0 0 500G 0 disk +-vda1 253:1 0 500G 0 part +-test-root 252:0 0 49G 0 lvm / +-test-swap 252:1 0 976M 0 lvm [SWAP]
resize PV, LV, file system
First make LVM format the addition free space: (It will 'partition' it so it can work with it, effectively splitting it into junks of like 4MB if I recall correctly.)
root@test:~# pvresize /dev/vda1 Physical volume "/dev/vda1" changed 1 physical volume(s) resized / 0 physical volume(s) not resized
Since the PV was already a member of the VG, no need to extend the VG.
Now for the actual volume:
root@test:~# lvextend -L 499G /dev/test/root Size of logical volume test/root changed from 49.04 GiB (12555 extents) to 499.00 GiB (127744 extents). Logical volume root successfully resized.
Here I specified it to be resized to 499GB. If I wanted to just use all available space, I'd do:
lvextend -l +100%FREE /dev/mapper/test-root root@test:~# lvextend -l +100%FREE /dev/mapper/test-root Size of logical volume test/root changed from 450.00 GiB (115200 extents) to 499.04 GiB (127755 extents). Logical volume root successfully resized.
-L is just easier to remember.
Lastly, resize the used filesystem:
root@test:~# resize2fs -p /dev/mapper/test-root resize2fs 1.42.13 (17-May-2015) Dateisystem bei /dev/mapper/test-root ist auf / eingeh�ngt; Online-Gr��en�nderung ist erforderlich old_desc_blocks = 1, new_desc_blocks = 32 Das Dateisystem auf /dev/mapper/test-root is nun 130821120 (4k) Bl�cke lang.
root@test:~# df -h Dateisystem Groesse Benutzt Verf. Verw% Eingehaengt auf udev 983M 0 983M 0% /dev tmpfs 201M 3.2M 197M 2% /run /dev/mapper/test-root 492G 2.3G 469G 1% / tmpfs 1001M 0 1001M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1001M 0 1001M 0% /sys/fs/cgroup
To shrink a LVM partition, there are several steps to be reproduced:
- the volume has to be unmounted
- activate the LVM volumes, so linux can handle them
- check that the filesystem is error free
- shrink filesystem, a little more than needed
- shrink LVM partition
- expand filesystem to full LVM partition size
- fsck again, if you are anxious :)
If the volume is mounted, you will not be able to filesystem-check it, or even shrink it. So you can not simply shrink the root partition of your running live system. For this you will need a live disk (google for 'grml linux') and boot from this to make the changes.
So here something to copy paste from:
vgchange -a y e2fsck -f /dev/<volume_group>/<logical_volume> resize2fs /dev/<volume_group>/<logical_volume> <size-in-GB-MINUS-1GB>G lvreduce -L <size-in-GB>G /dev/<volume_group>/<logical_volume> resize2fs /dev/<volume_group>/<logical_volume> e2fsck -f /dev/<volume_group>/<logical_volume>
Usually you'd want to do this in order to create another volume / partition, but this is stuff for another blogpost.
View posts from 2017-03, 2017-02, 2017-01, 2016-12, 2016-11, 2016-10, 2016-09, 2016-08, 2016-07, 2016-06, 2016-05, 2016-04, 2016-03, 2016-02, 2016-01, 2015-12, 2015-11, 2015-10, 2015-09, 2015-08, 2015-07, 2015-06, 2015-05, 2015-04, 2015-03, 2015-02, 2015-01, 2014-12, 2014-11, 2014-10, 2014-09, 2014-08, 2014-07, 2014-06, 2014-05, 2014-04, 2014-03, 2014-01, 2013-12, 2013-11, 2013-10