Problem capturing image - " no space left on device"?

[Quazz]

Is this on FOG 1.5.7?

When using resizable image type, FOG will try to resize the partitions it thinks should be resized. Something appears to go wrong in this case however. The space attributed is not enough to do even very basic operations.

Is this a GPT partition layout?

Can you share a picture of diskmanagement?

[Stepa]

Okay, that’s weird.
I’m guessing you mean the windows diskmanagement of the pc I try to capture?

Hope it’s not to bad it’s german…
edit: yes, it is fog 1.5.7

[Quazz]

@Stepa Looks like an MBR layout.

Fixed size partition seems to be correct as well.

I’m not 100% sure what would cause this at this point.

Can you post the contents of the text files in /images/dev/000cd615c141 (from the FOG server) here? That way we should be able to see what kind of results the FOS logic came up with and try and reverse engineer what happened.

[Sebastian Roth]

@Stepa Definitely follow Quazz advice und post the text content of the files from the directory mentioned.

As well you can try defrag the Windows partition before capturing.

[Stepa]

Oof sorry for taking so incredibly long to answer again, had a nightmare of a workday so far.
Here’s a screenshot of all the files contents . It’s not much though, hope it’s sufficient.

edit: Defraging the source pc was the first thing I tried, didn’t work

[Quazz]

@Stepa I could be wrong, but don’t notice anything wrong so far.

Something goes wrong with ntfsresize or the size it’s ordered to try.

Perhaps try a debug capture (under advanced tasks of a host) (type enter until you’re at command line after loading and then type in fog and press enter, then press enter for each step)

Does it say * Possible resize partition size: (size here) a few steps before the error?

Just want to see if the numbers make sense.

[Sebastian Roth]

@Quazz I see there is something wrong. Where is p1.minimum.partitions. Should be another text file very similar to p1.partitions…

@Stepa Please do a debug capture as suggested and take pictures of the messages on screen while it goes along. Post those pictures here.

[Stepa]

Yeah I searched for it… p1.minimum.partitions does not exist it seems…
I did a debug capture and took some pictures of the things that seemed weird to me.

just realised I might have compressed them a little too much this time. Hope its still readable.

[Sebastian Roth]

@Stepa said in Problem capturing image - " no space left on device"?:

just realised I might have compressed them a little too much this time. Hope its still readable.

Compression ratio is not a problem here. The ceiling lights is what makes reading it hard.

Not shrinking (/dev/nvme0n1p1) fixed size

That one is ok. It’s the first partition which is detected as fixed and FOG doesn’t resize it.

I guess I was on the wrong track at first. The p1.minimum.partitions is not being created until FOS was abel to resize the partition…

[Quazz]

@Sebastian-Roth Looking over the shrinkPartition function, it looks like the new size is calculated as the theoretical minimum size as given by ntfsresize + 5% of that size. (for safety and consistency I believe).

However, I can foresee situations where the theoretical minimum is small enough that the 5% of “safety space” isn’t enough to accomodate everything. I don’t think this will happen under every circumstance, only when there’s certain kinds of fragmentations that it can’t resolve.

Perhaps a preset minimum should be added to ensure a minimum safety boundry (like say 200MB)

Ntfsresize man page mentions you don’t require defragmentating the drive prior to using it since it kind of does that itself, but obviously on an SSD that logic doesn’t really make sense anyway!

Those are my current thoughts on this, but quite honestly I could be completely wrong.

[Stepa]

So, I kinda had to give up on that device, had to ship it. No idea what excactly was the problem with that.
I’ve set up a new devive today (basically same computer), did the same routine of setting it up, installing winodws and so on… With that one, capturing went perfectly fine. So basically my problem is somewhat solved by that… In the way that my company can continue their workflow as usual.

I still would like to understand what was going on with that pc… But I can’t do any more test on that one… So I guess we’ll never know…

Thank you guys for helping me

[eVal]

I have the same issue on diffrent PC’s. Since this topic is closed because the problem was “solved” for the reporter, what info do you guys need from mee?

My error screen looks the same as the reporter.

I’m on FOG 1.5.5 because I can’t yet upgrade to 1.5.7 due to problems with confilcts between ubuntu, mariadb and fog.

[Sebastian Roth]

@eVal said in Problem capturing image - " no space left on device"?:

My error screen looks the same as the reporter.

I am absolutely sure the information on your screen looks different to the one posted here. Pretty much ever situation is a little different and I may ask you to just open a new topic and if you like add a link to this one as well. In that new topic add all *your information. FOG version, picture with the error on screen, contents of p1.minimum.partitions, p1.minimum.partitions and p1.fixed_size_partitions, the actions you took to try and fix it so far and maybe more

[benc]

I’ve never run into this specific problem until today. Generally, issues with resizing can be fixed by increasing the CAPTURERESIZEPCT in Fog Settings > General Settings. I agree with what @Quazz said about certain kinds of fragmentations causing issues with the theoretical minimum partition size. I’ve found that the more used (fragmented?) a drive is, the more likely it is to fail during resize. I was able to get past the no space left on device and numerical result out of range errors by increasing the CAPTURERESIZEPCT to 15%.