In one of my previous blog entries I described a way to enlarge partitions of UTM-1 appliances. This was necessary especially for the older x50 series appliances, as they had a smaller hard drive and a bad partition layout.
In the past I only enlarged the partition that held the log files because that’s were you have the most data. The procedure was working just fine and I was happy.
A couple of days ago I started updating x50 series appliances from R65 to R71. Even with cleaning up the system of unused files right before the update I got into serious trouble. The cause was that the root partition was nearly about full.
The update process itself came up with no error, but while operating the appliance the root partition was completely full in no time. Especially updating the URL Filterung database, which is now about 370MB, filled the root partition quickly.
When I tried enlarging the root partition with the described procedure I failed.
Resizing requires to unmount the partition before – but you can’t unmount the root partition.
So I had to find another way to modify the partition sizes of the appliance.
Here’s what I did:
I downloaded an ISO-Image of grml, a Linux Live system for sysadmins. Then I modified the ISO to display output on the serial console. You can download this modified ISO here.
I connected an USB-DVD-Drive to the appliance and booted the ISO image.
On the boot screen I added some parameters for the startup process:
Some information and boot options available via keys F2 - F10. http://grml.org/
grml 2010.04 - Release Codename Grmlmonster 2010.04.29
boot: serial debug=noscreen lang=de lvm
When grml was finished, it gave me a console with all the needed tools. LVM was loaded already and I was good to go.
I checked for the volume groups on the hard drive with the vgscan command:
root@grml ~ # vgscan -v
Wiping cache of LVM-capable devices
Wiping internal VG cache
Reading all physical volumes. This may take a while...
Finding all volume groups
Finding volume group "vg_splat"
Found volume group "vg_splat" using metadata type lvm2
Then I activated the logical volumes with vgchange:
root@grml ~ # vgchange -a y
6 logical volume(s) in volume group "vg_splat" now active
You can display the volume group with vgdisplay:
root@grml ~ # vgdisplay
--- Volume group ---
VG Name vg_splat
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 7
VG Access read/write
VG Status resizable
MAX LV 255
Cur LV 6
Open LV 0
Max PV 255
Cur PV 1
Act PV 1
VG Size 72.47 GiB
PE Size 4.00 MiB
Total PE 18553
Alloc PE / Size 7424 / 29.00 GiB
Free PE / Size 11129 / 43.47 GiB
VG UUID dCQA6u-z70X-LIsE-Xhmb-n5ho-ZMrX-JyBePy
You can display the logical volumes with lvscan:
root@grml ~ # lvscan
ACTIVE '/dev/vg_splat/lv_current' [5.00 GiB] inherit
ACTIVE '/dev/vg_splat/lv_log' [10.00 GiB] inherit
ACTIVE '/dev/vg_splat/lv_hfa' [5.00 GiB] inherit
ACTIVE '/dev/vg_splat/lv_upgrade' [5.00 GiB] inherit
ACTIVE '/dev/vg_splat/lv_fcd' [2.00 GiB] inherit
ACTIVE '/dev/vg_splat/lv_fcd62' [2.00 GiB] inherit
Then I did the resizing of the volumes groups to better values:
root@grml ~ # lvresize -L 11GB /dev/vg_splat/lv_current
Extending logical volume lv_current to 11.00 GiB
Logical volume lv_current successfully resized
root@grml ~ # lvresize -L 25G /dev/vg_splat/lv_log
Extending logical volume lv_log to 25.00 GiB
Logical volume lv_log successfully resized
Keep in mind that you will need some free space for imaging purposes, so don’t use up all the space on the hard drive!
Then a file system check has to be done, followed by the resizing of the file system.
root@grml ~ # e2fsck -f /dev/vg_splat/lv_current
e2fsck 1.41.11 (14-Mar-2010)
Superblock last mount time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set) Fix? yes
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/vg_splat/lv_current: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vg_splat/lv_current: 26973/655360 files (0.1% non-contiguous), 384238/1310720 blocks
root@grml ~ # resize2fs /dev/vg_splat/lv_current
resize2fs 1.41.11 (14-Mar-2010)
Resizing the filesystem on /dev/vg_splat/lv_current to 2883584 (4k) blocks.
The filesystem on /dev/vg_splat/lv_current is now 2883584 blocks long.
root@grml ~ # e2fsck -f /dev/vg_splat/lv_log
e2fsck 1.41.11 (14-Mar-2010)
Superblock last mount time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set) Fix? yes
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/vg_splat/lv_log: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vg_splat/lv_log: 56/1310720 files (3.6% non-contiguous), 49409/2621440 blocks
root@grml ~ # resize2fs /dev/vg_splat/lv_log
resize2fs 1.41.11 (14-Mar-2010)
Resizing the filesystem on /dev/vg_splat/lv_log to 6553600 (4k) blocks.
The filesystem on /dev/vg_splat/lv_log is now 6553600 blocks long.
To finish, deactive the logical volumes:
root@grml ~ # vgchange -a n
0 logical volume(s) in volume group "vg_splat" now active
root@grml ~ # lvscan
inactive '/dev/vg_splat/lv_current' [11.00 GiB] inherit
inactive '/dev/vg_splat/lv_log' [25.00 GiB] inherit
inactive '/dev/vg_splat/lv_hfa' [5.00 GiB] inherit
inactive '/dev/vg_splat/lv_upgrade' [5.00 GiB] inherit
inactive '/dev/vg_splat/lv_fcd' [2.00 GiB] inherit
inactive '/dev/vg_splat/lv_fcd62' [2.00 GiB] inherit
That’s it. Reboot again and start the Secure Platform.
Check with df -h that you have the desired partition layout:
[Expert@cpmodule]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_splat-lv_current
11G 1.4G 8.9G 14% /
none 11G 1.4G 8.9G 14% /dev/pts
/dev/hdc1 145M 13M 125M 9% /boot
none 502M 0 502M 0% /dev/shm
/dev/mapper/vg_splat-lv_log
25G 33M 24G 1% /var/log
Tobias Lachmann
