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

  • Hello ladies and gentlemen,
    I wanted to capture two images today using fog, both of which where basically updates for old ones. The thirst worked without any problems, the second though I just can not get working. I’ve been trying for hours now, via trying different settings for my image, looking on the internet … I just can’t get it working. Off course I checked if there actaully isn’t enough free space, there’s about 150gb free, image size should end up at about 30gb…
    I’ll add a photo of the error screen here, please tell me if you need any more info.
    And please excuse me, if I forget any important info, I’m absolutely new to all of this, I’ve basically been forced into this due to office staff changes and I am only an intern starting his job training summer this year, so… yeah…
    Hope this is enough information to start off with, and thanks a lot in advance 🙂

  • Senior Developer

    @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

  • 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.

  • 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 🙂

  • Moderator

    @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.

  • Senior Developer

    @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…

  • 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.

    3107_03.jpg 3107_02.jpg 3107_01.jpg

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

  • Senior Developer

    @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.

  • Moderator

    @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.

  • 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 😕

  • Senior Developer

    @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.

  • Moderator

    @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.

  • 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

  • Moderator

    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?