Error while creating new image: No space left on device

[eVal]

Hello all,

I have a similar/same issue as mentioned in this topic: https://forums.fogproject.org/topic/13546/problem-capturing-image-no-space-left-on-device

I have FOG 1.5.7 running on Ubuntu 18.04. The bzImage version I’m using is 4.19.48. When I try to make a new image I’ll get the next error after resizing is done:

Contents of /dev/mac directory:

File: d1.fixed_size_partitions

:1:1

File: d1.original.fstypes

/dev/sda2 ntfs

File: d1.original.swapuuids

File is empty

File: d1.partitions

label: dos
label-id: 0xd74c9d19
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=      204800, type=7, bootable
/dev/sda2 : start=      206848, size=   123916800, type=7
/dev/sda3 : start=   124123648, size=      921600, type=27

Putting images back is no problem, but I can’t create anymore. Running a capture debug gives the next error:

Followed by

Image information in FOG:
Image Type: Single Disk - Resizable
Partition: Everything
Image Manager: Partclone Gzip

[Sebastian Roth]

@eVal Sorry still have not found the time to dig through the figures you posted. Will do so in the next days.

[Sebastian Roth]

@eVal Ok, looking through the details you posted I can’t see anything obvious being wrong here. Have you run defrag already? That sometimes helps.

[Quazz]

@Sebastian-Roth Possibly the same problem as https://forums.fogproject.org/topic/13546/problem-capturing-image-no-space-left-on-device

It’s really odd that the resize tests succeeds, but then the actual resizing fails! Logically speaking this shouldn’t happen, ever, since it makes no sense.

It’s worth noting that ntfsresize can fail due to bad sectors, which is potentially even the most likely explanation to this problem given that we rarely see people bring it up and they tend to fail to reproduce it.

@eVal How much data is currently in use on the main partition? We can see that FOS think it can go down to around 18.76GB

[eVal]

@Sebastian-Roth
I’ve run chkdsk, sfc /scannow and several DISM commands but all without succes.

@Quazz The total size in use is around the 18-19GB so that is correct. I also doubt that it’s a bad sector fault because I have tried making an image with several different PC’s.

Right now I’m using an old image to recover and I need to update Windows. If I try to create a new image from the updated Windows I get this error.
But when I recover the old image and directly try to make a new image it goes successful. I find that very strange.
I tried to recover an old image, update windows run chdkdsk several times, SFC and DISM but still I get this error.

I’m going on vacation for two weeks so I can’t respond for this period but if you leave any suggestions I"ll be happy to follow up on my return.
One of the first things I’m going to do is trying to create an image from a fresh Windows install.

[Quazz]

@eVal I’ve heard of people having issues capturing when updating existing images like that.

Most people’s workflow consists of spinning up the latest Windows 10 ISOs, installing all their software, sysprep and then capture I believe.

You might have to use cleanmgr.exe (default windows cleaning utility) to clean up the updates after they’re installed.

Defragging might also be since a large amount of data was moved around.

I don’t know if you tried dism /online /cleanup-image /startcomponentcleanup either.

But even after all that it might still act up.

[Sebastian Roth]

@eVal Any news on this? Last chance might be to reinstall.

[eVal]

I was on vacation for two weeks so couldn’t respond earlier.

But I’ve run the cleanmgr and dism command without any luck. So there is nothing left to do then a clean install. I’ll let you know if that works.

[Sebastian Roth]

@eVal Well, I can imagine we can come up with a quick hack for that by changing the size FOS tries to shrink your partition down to. Have you used postinit scripts yet? Take a look at George’s description: https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins

Using a postinit script you can change the behavior of the capture scripts on the fly without manually modifying the init files directly. Let us know if you are keen to give this a try. Please prepare a first postinit script for testing as described in the above mentioned topic. Keep your custom postinit script very simple as a first test. Something like this will do:

#!/bin/bash
echo "Test script works"
sleep 10

Now when you boot up a client that was scheduled for a task (capture task for example) pay attention to the messages on screen. You should see the “Test script works” at an early stage. Make sure this is working correctly and we take it from there.

[eVal]

Creating an image from scratch was the solution to my problem. So further trouble shooting/hacking is not necessary

Thanks for the help!