Deploying image, "~empty image might cause issues," but it initially shows as 65GB then 0.0 after deploy
-
The title says most of it. I capture an image from this box. Listing images shows it to be 65GB, great. Swap HDD, then try to deploy the 65GB image to the new HDD only to receive the odd error “seems like you’re trying to restore an empty disk… no image file found that would match the partitions to be restored.” At this point if I list images the image is shown to be 0.0GB. Thoughts anyone? Did it really fail to capture even though it completes with a “mission accomplished” and shows a size, or is it actually stepping on a good image in the deploy process?
-
Can we get a bit more details on the target computer?
Who made it and what model number?
Is this in uefi or bois (legacy mode)?
From the FOG iPXE menu did you see if the hardware was compatible with FOG? Did both network and disk pass? -
The box is a Dell Inspiron 3650. It is UEFI, but I set vendor codes so I get the same behavior whether booting legacy or uefi. Drive is set to AHCI, and that is the only option. Secure boot is disabled. There really isn’t much to fiddle with in the bios.
The HDDs and network pass the compatibility test.
-
@geardog I’ve seen this similar error when in uefi mode and the disk controller is set to raid-on mode.
Can you schedule another capture or deployment to this target computer, but before you submit the job, tick the debug check box then pxe boot the target computer. After a few enter key-presses on the target computer you will be dropped to a linux command prompt. At the command prompt please key in the following command.
lsblkand post the results here. -
The bios only shows AHCI. No other option exists.
-
@geardog On the plus side FOS sees your disk (/dev/sda) so that issue is not it.
Can you show the output of this command
ls -la /images/sales-04There has to be a reason why its saying “No image files found…” -
I took two shots of ls -la results. The first pic is where the image is shown as being 0.0GB in image listings. The second picture is a re-capture to again show 65GB in the image listing. As soon as I try to deploy this 65GB image it fails and goes to 0.0GB.
-
As an update to this peculiar behavior, I see that fog has written the target drive for deployment to be a 1TB drive, but it is a 250GB. Connecting the mis-sized drive to a windows box and opening a storage management window, I see that it is GPT protected and it is 1TB (the size of the drive that was captured coincidentally). If I open diskpart, it shows as the expected 232GB. Cleaning the disk with diskpart returns it to expected values in windows’ storage management viewport.
-
@geardog Just so I’m clear on this. The reference image (original) had a 1TB hard drive. You captured it as single disk resizable. You are now trying to restore the image to a 250GB disk? The total size of all of the data is less than 250GB right?
Looking at the partition layout I see P3 being 38GB (compressed) and P5 being 12GB (compressed).
Is this is standard windows 10 disk layout?
-
@geardog Can you please post the contents of p1.partitions, d1.minimum.partitions and d1.fixed_size_partitions so we can take a look.
What comes to my mind when you say it seems to deploy a 1 TB disk size. Is the old disk 512 block size while the new one is 4096?
-
@george1421
You have it correct. Compressed, it adds up to 65GB. It is an OEM layout that probably has a recovery partition, that I’d hope to never deal with really. For “siplicity” I hoped to just grab and go dealing with the extra data.@Sebastian-Roth
That is a good thought! I’ve never run into compatibility issues on this topic. The original is 4k, and the target that got mis-sized is 512.Edit:
-
@geardog Just a comment here on your screen shots. It would be much easier if you connected to the FOG server using putty or some other terminal program so you can copy and paste directly from the fog server into the forums. There’s a point when the images you post are so small that they are hard to read even if the pictures are enlarged.
-
This post is deleted! -
Based on what I’m seeing the drive should be in mbr mode? I’m saying this because of partitions 4 and 5.
Windows tried to fix gpt but nearly fails when the original layout was gpt. They leave remnants of gpt lying around which can cause fog to not like it?
Are these machines booting via UEFI or Legacy? Was the image adjusted for Windows to boot MBR or GPT?
Again I’m only guessing based on what I’m seeing from the d1.partitions file. I could be wrong though.
If you can boot the client machine into debug deploy, what is output of
fixparts /dev/sda -
I’ve not adjusted anything. This machine is how Dell shipped it. It is a box with UEFI. “Windows tried to fix gpt but nearly fails…” doesn’t make much sense to me, as all of this is outside of windows. The only time windows has any play is when it is booting the original working drive, at which point it works fine. I attached the intended target drive (after deployment failure) to a running windows box to see that mis-sized 1TB protected gpt partition business. As I haven’t successfully cloned the drive, I’m not keen on fixpart’ing it. Maybe tomorrow I’ll call it quits, and just install fresh on another drive, leaving this odd issue to experimentation.
I can boot from fog either uefi or legacy, but native is surely uefi. I get the same squashed image results.
EDIT: Ah, you’re curious about output of fixparts on the target drive, I suppose. I’ll try it tomorrow.
-
With the hopes of clearing any confusion, I used diskpart to clean the 250GB drive that was mis-sized with the protected GPT partition mess. It was then 238GB unallocated, which I tried to deploy the 65GB image to again, with the same results.
-
Update:
The box itself clearly hasn’t been the issue. I’ve done a fresh install of Win10. It captured and deployed successfully to the same target drives. The computer handles 4k and 512 drives fine. -
In case there is desire to sort out what was going on I ran through the attempted capture/deploy of the original disks. Hoping I’m giving the info asked for.
This is the disk I captured.
This is the error I got deploying was:
“no image files found that would match the partitions to be restored”This is the debug info I got of the target of failed deployment.
-
@geardog forgive me if this has already been asked before.
Can you capture and deploy correctly to the same computer?
Also I assume in your last post the top picture and bottom picture are from two difference computers? Are they the same make and model? Do they have the same exact hard drive installed? If the target system is just one byte smaller then fog can’t deploy to it.
Are these two computers the exact same model? If so what model of computers are they? There is something here amiss. This is not a typical message we see. Its kind of hard to debug remotely without being able to touch the machines.
-
@george1421
I had a handful of the target drive model. I used the same drives I attempted to use as a deploy target to start over. I reinstalled windows on one of the handful of 512 sector drive, and managed to capture and deploy flawlessly to the same box (a Dell Inspiron 3650).I then started over trying to capture/deploy the OEM drive/install to help debug the issue. I still can’t deploy an image of the OEM successfully. All of this has been on the same box.
The error came in when capturing a 4k sector drive and deploying it to a 512 sector drive. This failed in the same way repeatably. This scenario is what I’ve documented here in various ways. The last pictures are of the originating 4k 1TB OEM dell install drive, next the error on deploying the capture of that drive (that was listed as a successful capture), and finally a debug deploy showing the resulting partition info on the intended 250GB 512 target drive.
