Most likely these are partially (or fully captured that were unable to move) capture images hanging out in /images/dev

@irishfoguser Hi, generally speaking you’re better off using Resizable image. If this for some reason doesn’t work (fails to deploy), then trying the other options is recommended.

For your situation, it sounds like Resizable Image will do the trick. So I recommend picking an image, setting it to resizable, recapture, deploy and see if it works for you.

1.3 is able to resize the correct partition for you before Windows even boots for the first time.

To be fair, it’s been a longstanding recommendation that the FOG server should be running nothing but the FOG server for a reason.

@TomBagley Considering you have to enter tftp server address, it is likely you have another DHCP server on your network (likely your modem), which might be interfering.

Apparentally, to prevent Windows search from breaking after copying the profile over, all you have to do is delete

AppData\Local\Microsoft\Windows\UsrClass.dat

Windows will create one on login.

It’s /var/www/fog/service/ipxe (singular service)

I’m guessing you launch a batch script which launches a msiexec and then closes rather than waiting

Adjust accordingly.

What error are you getting?

set username foglogin
set password foglogin
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

Try using that, changing the set username and set password parts to your own webgui login info

@lebrun78 You could try a different disk boot command. You can choose these globally, per group or per host I believe. Default is Sanboot if I’m not mistaken.

There’s different options because different hardware handles it differrently, annoyingly enough.

Fairly certain the problem is that Snapins run under the System account, which cannot interact with the desktop, and thus you can’t “elevate” to administrator.

@ProfDrSir Ideally you’d use both! Sysprep does more than what the cleaning tool can do.

We often see images failing to capture after installing certain updates. Though typically these are version point upgrades.

Do you use sysprep for your images?

Sometimes it can be resolved by cleaning up the system and such.

(eg dism /online /cleanup-image /startcomponentcleanup)

Is this a legacy Windows 10 install that has been converted? The partition layout is not standard.

@ty900000 That build does not yet include the partclone fixes, though. But we are getting close to that.

@explosivo98 Latest dev build is available here: https://dev.fogproject.org/blue/organizations/jenkins/fos/detail/master/115/artifacts

I don’t believe we have actively tried to hunt this particular bug down, but changes have been made to kernel configs and inits, so worth a shot! (so get both the bzImage and init.xz)

Only use these for testing those devices for now. Still some bugs to kill, but you should be able to see if you can deploy at least.

@Middle That’s really unfortunate. We were hoping that would be sufficient for all usecases, but unfortunately it seems that in some cases that’s not true.

We also can’t disable it globally since that would hinder performance for a lot of users that don’t have this issue…

You can try setting the command in postinit scripts. (/images/dev/postinitscripts/fog.postinit)

The command should execute after the init has loaded and before FOG starts its magic.

@Middle Can you try the KERNEL ARGS George suggested?

nvme_core.default_ps_max_latency_us=0

@shruggy said in Development FOG not capturing image - PartClone update:

@Tom-Elliott said in Development FOG not capturing image - PartClone update:

I pushed another fix and believe the issue was as @Quazz noted is the -c argument was missing. Strange as that is, as the -c argument doesn’t appear to be a part of the spec list (unless somebody already added that to the patch for partclone and I didn’t know it?)

My understanding of it is this:

• images captured with partclone.imager -c need to be restored with partclone.restore, raw images captured with partclone.dd or with partclone.imager without -c need to be restored with partclone.dd
• the options for partclone.imager are basically the same as for any partclone.$ftype (including -c and -a), it’s partclone.dd that is a special case. The symbol DD only pertains to partclone.dd, the symbol IMG is specifically defined in Makefile for partclone.imager, but never gets used in upstream Partclone code.

Adding on to this, partclone.imager is generated using partclone.dd source files.

As per the makefile: https://github.com/Thomas-Tsai/partclone/blob/master/src/Makefile.am#L56

Making this commit: https://github.com/Thomas-Tsai/partclone/commit/2d1ee7c94139f390453ea8cb8675f67173bde33b problematic.

The special code for RAW is then locked to partclone.dd while partclone.imager is stuck using the “normal” code, which doesn’t work properly for its scenario.

Restoring the old code for partclone.imager should work. (there is no option to change the if condition main.c since there is no opt for imager…)

The stuff in https://forums.fogproject.org/topic/14078/1-5-7-89-partclone-doesn-t-capture-an-image-in-dd-mode-wrong-options-in-fog-upload/17 should work.

We just need to create a patch for it imo.

@Tom-Elliott I am fairly confident the -a0 is a bug, since it is listed in its options, but isn’t picked up for use.

-c was removed for dd (it’s implied I guess??)

Interesting you should mention it not occuring in debug. I have seen this problem before, but that was on… unreliable devices so didn’t think much of it when I couldn’t replicate it on other devices.

@Tom-Elliott I think it’s more likely to be caused by partclone.imager being broken in current 0.3.12

Note how the detected size of the partition is 0 by partclone.