Partition is too big for the for the disk.
-
@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.
-
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?
-
Re pulled image but that didnt help. FWIW the target system has an NVMe drive.
thoughts?
-
@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).
-
@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.
-
@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" -
@obzen Please post the contents of the (text) files
d1.partitions,d1.shrunken.partitionsandd1.minimum.partitions. -
@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
-
@obzen Oh, I just noticed you had posted
d1.minimum.partitionsearlier 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 ind1.minimum.partitionsandd1.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
fogon the shell and step through the whole process. Pay attention to where it tries to shrink your partitions. Any errors/warnings? -
@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!
-
@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.
-
@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?
-
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.
-
@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
lsblkto see a list of drives and partitions. Probably you’ll see/dev/nvme0n1in 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 typerebootand let it jump right into the existing deploy (debug) task again. This time start the deploy (commandfog) and see if it errors out again.
