This tutorial explains how to expand a FreeBSD virtual machine inside Oracle Virtualbox. Basically it means expanding the hard drive capacity, and then syncing the operating system so acknowledges it.
1) Current state:
We start from a virtual machine with one virtual drive, capacity 45GB
% gpart show
=> 3 94371829 ada0 GPT (45G)
3 127 1 freebsd-boot (64K)
130 66584 2 efi (33M)
66714 2097152 3 freebsd-swap (1.0G)
2163866 92207966 4 freebsd-ufs (44G)2) Power off the virtual machine and go to main window of Oracle VM VirtualBox Manager, top section called Tools.
3) Select the .vdi for the virtual machine, and enlarge its size, for example from 45GB to 65GB (shrinking is not currently implemented in version 7.0.4) -> Apply
4) Start the virtual machine and check partition table status:
# gpart show
=> 3 94371829 ada0 GPT (45G)
3 127 1 freebsd-boot (64K)
130 66584 2 efi (33M)
66714 2097152 3 freebsd-swap (1.0G)
2163866 92207966 4 freebsd-ufs (44G)
# gpart recover ada0
ada0 recovering is not needed
Still shows the previous size and does not detect enlargement. This is because there are still snapshots for the virtual machine.
5) Delete all snapshots after powering off the virtual machine.
6) Start the vm again and check:
# gpart show
=> 3 94371829 ada0 GPT (65G) [CORRUPT]
3 127 1 freebsd-boot (64K)
130 66584 2 efi (33M)
66714 2097152 3 freebsd-swap (1.0G)
2163866 92207966 4 freebsd-ufs (44G7) Recover the partition table:
# gpart recover ada0
ada0 recovered8) Now the free space is shown:
# gpart show
=> 3 136314869 ada0 GPT (65G)
3 127 1 freebsd-boot (64K)
130 66584 2 efi (33M)
66714 2097152 3 freebsd-swap (1.0G)
2163866 92207966 4 freebsd-ufs (44G)
94371832 41943040 - free - (20G)9) Enlarge the partition /dev/ada0p4:
# gpart resize -i 4 ada0
ada0p4 resized
# gpart show
=> 3 136314869 ada0 GPT (65G)
3 127 1 freebsd-boot (64K)
130 66584 2 efi (33M)
66714 2097152 3 freebsd-swap (1.0G)
2163866 134151006 4 freebsd-ufs (64G)
# growfs /dev/ada0p4
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/ada0p4 from 44GB to 64GB? [yes/no] yes
growfs: /dev/ada0p4: Operation not permittedWe need to force it with the service:
# sysctl kern.geom.debugflags=16
kern.geom.debugflags: 0 -> 16
# growfs /dev/ada0p4
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/ada0p4 from 44GB to 64GB? [yes/no] yes
growfs: /dev/ada0p4: Operation not permitted
# service growfs onestart
Growing root partition to fill device
ada0 recovering is not needed
ada0p4 resized
gpart: arg0 'gpt/rootfs': Invalid argument
super-block backups (for fsck_ffs -b #) at:
92192448, 93472896, 94753344, 96033792, 97314240, 98594688, 99875136, 101155584, 102436032, 103716480, 104996928, 106277376, 107557824, 108838272, 110118720, 111399168, 112679616,
113960064, 115240512, 116520960, 117801408, 119081856, 120362304, 121642752, 122923200, 124203648, 125484096, 126764544, 128044992, 129325440, 130605888, 131886336, 133166784
# growfs /dev/ada0p4
growfs: requested size 64GB is equal to the current filesystem size 64GBWe can check for filesystem status:
# fsck /
** /dev/gpt/rootfs (NO WRITE)
** Last Mounted on
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no
SUMMARY INFORMATION BAD
SALVAGE? no
BLK(S) MISSING IN BIT MAPS
SALVAGE? no
418878 files, 4628857 used, 11612452 free (19164 frags, 1449161 blocks, 0.1% fragmentationA reboot is advisable. If we check again from a livecd it should say the filesystem is clean, but from the live system some warnings or errors may appear.
Links
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.