Resizable Linux images - not expanding
Wayne Workman last edited by Wayne Workman
I’m running FOG r6483, on Fedora 23.
I just updated an image I have of Fedora 23, it’s a resizable image type - just one disk, it uses ext4 (not lvm).
The computer has a 128GB SSD in it - it’s worked fine in the past many times with fog and re-sizable images both with windows and Linux.
After uploading my new image, and then re-downloading it to test, I’ve noticed the partitions are not being expanded.
[wayne@LivingRoom ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 119.2G 0 disk ├─sda1 8:1 0 500M 0 part /boot ├─sda2 8:2 0 10G 0 part / ├─sda3 8:3 0 3.9G 0 part ├─sda4 8:4 0 1K 0 part └─sda5 8:5 0 463.6M 0 part /home sr0 11:0 1 1024M 0 rom
[wayne@LivingRoom ~]$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 12M 1.9G 1% /dev/shm tmpfs 1.9G 1.6M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/sda2 9.8G 6.0G 3.3G 66% / tmpfs 1.9G 56K 1.9G 1% /tmp /dev/sda5 328M 160M 136M 55% /home /dev/sda1 477M 148M 300M 33% /boot tmpfs 389M 16K 389M 1% /run/user/42 tmpfs 389M 28K 389M 1% /run/user/1000
Inside the Fedora23LivingRoom directory on the fog server:
total 3.3G drwxrwxrwx. 8 fog root 161 Feb 27 11:28 .. drwxrwxrwx. 2 root root 257 Feb 27 11:28 . -rwxrwxrwx. 1 root root 35M Feb 27 11:28 d1p5.img -rwxrwxrwx. 1 root root 512 Feb 27 11:28 d1p4.ebr -rwxrwxrwx. 1 root root 47 Feb 27 11:28 d1.original.swapuuids -rwxrwxrwx. 1 root root 3.2G Feb 27 11:28 d1p2.img -rwxrwxrwx. 1 root root 154M Feb 27 11:22 d1p1.img -rwxrwxrwx. 1 root root 512 Feb 27 11:22 d1p5.ebr -rwxrwxrwx. 1 root root 368 Feb 27 11:22 d1.minimum.partitions -rwxrwxrwx. 1 root root 1.0M Feb 27 11:22 d1.mbr -rwxrwxrwx. 1 root root 0 Feb 27 11:22 d1.has_grub -rwxrwxrwx. 1 root root 48 Feb 27 11:22 d1.original.fstypes -rwxrwxrwx. 1 root root 368 Feb 27 11:21 d1.partitions -rwxrwxrwx. 1 root root 6 Feb 27 11:21 d1.fixed_size_partitions
label: dos label-id: 0x3d3e7204 device: /dev/sda unit: sectors /dev/sda1 : start= 2048, size= 1024000, type=83, bootable /dev/sda2 : start= 1026048, size= 20971520, type=83 /dev/sda3 : start= 21997568, size= 8128512, type=82 /dev/sda4 : start= 30126080, size= 219943424, type=5 /dev/sda5 : start= 30128128, size= 949494, type=83
/dev/sda1 extfs /dev/sda2 extfs /dev/sda5 extfs
label: dos label-id: 0x3d3e7204 device: /dev/sda unit: sectors /dev/sda1 : start= 2048, size= 641056, type=83, bootable /dev/sda2 : start= 1026048, size= 15796978, type=83 /dev/sda3 : start= 21997568, size= 8128512, type=82 /dev/sda4 : start= 30126080, size= 219943424, type=5 /dev/sda5 : start= 30128128, size= 464818, type=83
/got expanded using all that is available on the drive… the
/homepartition did not get expanded.
That’s OK though - I can work with that at least.
So this is a non-issue. Turns out, the reason it didn’t expand was due to the image being corrupt from replication failure in this other thread: https://forums.fogproject.org/topic/6793/replication-failure
After I blasted the images on my slave storage node and let them all replicate over fresh, I deployed this image to the same hardware using the same version of FOG and it expanded exactly as expected.
@Tom-Elliott I canceled the download process (after uploading) because I realized my nodes had not replicated yet. I didn’t cancel an upload process.
I’m going to guess you stopped upload at one point and restarted it? I say this because the d1.partitions is identical to the d1.minimum.partitions.
I’ve been testing the Linux images for expanding and shrinking and can only replicate this if I cancel the upload process before it reexpands the disk.