Partition is too big for the for the disk.

[obzen]

Hello,

I’m running latest 1.5.9 version of FOG.
I made a VM with windows 10 pro with only 65GB drive, UEFI boot.
Captured the image with the resizable option.
When I deploy it to a different physical machine, I get the error that the Partition is too big for the disk which doesn’t make sense since the machine has a 256gb drive > the original 65GB.
I also pulled the image with the resizable option.
I read on the forums that the recovery partition could cause this issue, so I removed it and re pulled the image, but deploying it still fails.

Thoughts?

[george1421]

@obzen I guess lets start with having you upgrade your fog install to the dev branch. In this article https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk perform the steps in the Update to latest section. Then recapture the image and deploy. There are some fixes in the version of fog 1.5.9.115 and later that might help.

On the captured system vs the target system do they have two different drive types (i.e. sata vs nvme)?

Do either of the source or target systems have multiple disks installed?

[obzen]

@george1421 Hi george, I will update the system using the link and retry the operation. to answer your first question, the capture system is a VM that runs on ESXi host(VMWare) that has datastores attached to it and serving the VMs. The target has an NVMe disk.
To your second question - Neither does the source or target have multiple disks installed.

may i add that i was using ipxe.efi boot file vs undionly.kpxe.

I was able to image a different system using undionly.kpxe just now but that one doesnt support uefi, its an older system, which makes me think the problem may be related to uefi builds, but i am not 100% sure.

I will try to upgrade the fog install and retry my original test case, in which the target is an uefi system.

[obzen]

I installed 1.5.9.158 from dev-branch, and tried to deploy with bootfile snponly.efi to the target but same issue persists. I did not recapture the image thought, should i do this before trying to deploy again?

[obzen]

Re pulled image but that didnt help. FWIW the target system has an NVMe drive.

thoughts?

[george1421]

@obzen said in Partition is too big for the for the disk.:

and tried to deploy with bootfile snponly.efi to the target but same issue persists

The issue is with FOS Linux so bzImage and init.xz not iPXE. Changing the ipxe boot loader will not impact these results. Now I’m not saying the problem is with FOS Linux just its not with iPXE (ipxe.efi or snp.efi).

[george1421]

@obzen said in Partition is too big for the for the disk.:

Re pulled image but that didnt help

Ok. If you look into /images/<image_name> directory. There are files that end in .img What is the largest file size of those img files? Those are actually the partition content compressed archived.

[obzen]

@george1421 thanks for the reply, the largest .img file is 16gb

[root@fog  windows_10_pro_64bit]# ls -ltrh
total 16G
-rwxrwxrwx. 1 root root  678 Aug 18 15:06 d1.partitions
-rwxrwxrwx. 1 root root    0 Aug 18 15:06 d1.original.swapuuids
-rwxrwxrwx. 1 root root   15 Aug 18 15:06 d1.original.fstypes
-rwxrwxrwx. 1 root root    6 Aug 18 15:06 d1.fixed_size_partitions
-rwxrwxrwx. 1 root root  678 Aug 18 15:06 d1.shrunken.partitions
-rwxrwxrwx. 1 root root 1.0M Aug 18 15:06 d1.mbr
-rwxrwxrwx. 1 root root  678 Aug 18 15:06 d1.minimum.partitions
-rwxrwxrwx. 1 root root 9.6M Aug 18 15:06 d1p1.img
-rwxrwxrwx. 1 root root  773 Aug 18 15:06 d1p2.img
-rwxrwxrwx. 1 root root  16G Aug 18 15:14 d1p3.img

[root@fog  windows_10_pro_64bit]# cat d1.minimum.partitions 
label: gpt
label-id: 0022D61A-2393-4A81-AC68-71D0B3C98212
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 136314846
sector-size: 512

/dev/sda1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E300D277-3B87-4F46-9E79-340C2B01EED7, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=89626C7E-1E8C-41D1-9923-A493121C56E4, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=      239616, size=   136072863, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=444C017D-4B5E-4919-8557-BC2102A054A8, name="Basic data partition"

[Sebastian Roth]

@obzen Please post the contents of the (text) files d1.partitions, d1.shrunken.partitions and d1.minimum.partitions.

[obzen]

@sebastian-roth hi sebastian

take a look below:

[root@fog  windows_10_pro_64bit]# cat d1.partitions
label: gpt
label-id: 0022D61A-2393-4A81-AC68-71D0B3C98212
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 136314846
sector-size: 512

/dev/sda1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E300D277-3B87-4F46-9E79-340C2B01EED7, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=89626C7E-1E8C-41D1-9923-A493121C56E4, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=      239616, size=   136072863, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=444C017D-4B5E-4919-8557-BC2102A054A8, name="Basic data partition"

[root@fog  windows_10_pro_64bit]# cat d1.shrunken.partitions
label: gpt
label-id: 0022D61A-2393-4A81-AC68-71D0B3C98212
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 136314846
sector-size: 512

/dev/sda1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E300D277-3B87-4F46-9E79-340C2B01EED7, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=89626C7E-1E8C-41D1-9923-A493121C56E4, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=      239616, size=   136072863, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=444C017D-4B5E-4919-8557-BC2102A054A8, name="Basic data partition"

[root@fog  windows_10_pro_64bit]# cat d1.minimum.partitions
label: gpt
label-id: 0022D61A-2393-4A81-AC68-71D0B3C98212
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 136314846
sector-size: 512

/dev/sda1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E300D277-3B87-4F46-9E79-340C2B01EED7, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=89626C7E-1E8C-41D1-9923-A493121C56E4, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=      239616, size=   136072863, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=444C017D-4B5E-4919-8557-BC2102A054A8, name="Basic data partition"

thanks

[Sebastian Roth]

@obzen Oh, I just noticed you had posted d1.minimum.partitions earlier already. I can see nothing obvious with the partition layout that could cause such a trouble. Except one thing makes me wonder: In each of the three partition files we see the size of sda3 being 136072863 sectors (roughly 65 GB - as you mentioned before). But eventhough using the resizable image type it does not seem to be able to shrink the filesystem. Because if it would we should see sda3 to have a smaller size in d1.minimum.partitions and d1.shrunken.partitions.

Let’s take one step back. First, could you please take a picture of the whole screen with error mentioned in your initial post (“Partition is too big for the disk”). And second, may I ask you to schedule the capture in debug mode (same as normal but before you click the Create Task button in the web UI there is a checkbox for debug), then let the machine boot up, hit ENTER twice, start the task using the command fog on the shell and step through the whole process. Pay attention to where it tries to shrink your partitions. Any errors/warnings?

[obzen]

@sebastian-roth said in Partition is too big for the for the disk.:

I think I posted [previously a complete error photo of the error found here.
Though the image says its 65GB i do believe its shrunk because my over all disk space on my fog box is ~100GB which contains two of these “65GB” images. Th biggest file in the image dir is 16gb, d1p3 as seen from the screenshot below.

[iiliev@fog  windows_10_pro_64bit]$ ls -ltrah
total 16G
-rwxrwxrwx. 1 root       root  678 Aug 18 15:06 d1.partitions
-rwxrwxrwx. 1 root       root    0 Aug 18 15:06 d1.original.swapuuids
-rwxrwxrwx. 1 root       root   15 Aug 18 15:06 d1.original.fstypes
-rwxrwxrwx. 1 root       root    6 Aug 18 15:06 d1.fixed_size_partitions
-rwxrwxrwx. 1 root       root  678 Aug 18 15:06 d1.shrunken.partitions
-rwxrwxrwx. 1 root       root 1.0M Aug 18 15:06 d1.mbr
-rwxrwxrwx. 1 root       root  678 Aug 18 15:06 d1.minimum.partitions
-rwxrwxrwx. 1 root       root 9.6M Aug 18 15:06 d1p1.img
-rwxrwxrwx. 1 root       root  773 Aug 18 15:06 d1p2.img
-rwxrwxrwx. 1 root       root  16G Aug 18 15:14 d1p3.img***

Perhaps it seems like there is a disconnect between the GUI (image shown as 65GB) and the actual footprint on the command line.

I did a fog debug you can see the result of it failing here.

Thanks!

[Sebastian Roth]

@obzen said in Partition is too big for the for the disk.:

I did a fog debug you can see the result of it failing here.

I was asking for a debug capture to maybe find out why it does not shrink sda3 in the first place.

The d1pX.img files only contain the actual data. So if the partition is 65 GB but contains 16 GB of data the resulting image file will only be 16 GB - actually even smaller because we run it through compression as well. What you see in the web UI is the original disk size. In the web UI settings you can enable “size on server” to be displayed as well.

[obzen]

@sebastian-roth I thought I followed your instructions correctly by checking the debug option before scheduling the task and iterating through the tasks with ENTER key Is there something I am missing as to how to get the capture of it correctly?

[obzen]

FWIW the system in question is a Dell Wyse 5070 with nvme. It appears that this is so far the problem child, as i have successfully imaged 3 other systems with both spinning disks, ssds and nvme.

[Sebastian Roth]

@obzen said in Partition is too big for the for the disk.:

I thought I followed your instructions correctly by checking the debug option before scheduling the task and iterating through the tasks with ENTER key Is there something I am missing as to how to get the capture of it correctly?

The pictures posted don’t show capture (from the source VM) but actually the deploy (to the target device). Nevermind.

FWIW the system in question is a Dell Wyse 5070 with nvme. It appears that this is so far the problem child, as i have successfully imaged 3 other systems with both spinning disks, ssds and nvme.

Well that’s an interesting detail! So it’s not a general issue but only caused on this particular machine. Looking at the pictures again I noticed it tries to deploy to /dev/mmcblk0. Sounds like the Dell Wyse 5070 has different drives and you need to specify the correct drive in the Host settings.

But first let’s find out what drives it has. So schedule another debug deploy (yes, deploy this time!) task for the Dell_Wyse and boot it up to the shell. Run lsblk to see a list of drives and partitions. Probably you’ll see /dev/nvme0n1 in the list. Put exactly this into the Host setting field Host Primary Disk (FOG web UI -> hosts -> Dell_Wyse). Now in the command shell on your Dell type reboot and let it jump right into the existing deploy (debug) task again. This time start the deploy (command fog) and see if it errors out again.