Posts made by TBCS

@george1421 Thank you george. Updating the kernel did fix the issue however the capture still halts at around 30%. Unfortunately there’s no error as the capture doesn’t fail, it just stops. This is the first windows 11 image I’ve attempted to capture though I notice it doesn’t exist on the drop down when I specify the OS when creating the image (only windows 10, which is what I selected). Could something related to windows 11 be causing this issue?

I don’t have a lot of info about why this is failing, because I don’t know if there are any logs I can find that are generated during an image capture. It technically doesn’t fail it just stalls.

This is a windows 11 image and I’m attempting to capture from a Yoga 7i 14ITL5

I can deploy images to this computer. Here’s what happens when it fails.

I wish I had more info but maybe if someone can point me to some logs we can get to the bottom of things because I assume this isn’t enough to pinpoint what’s happening.

I’m running FOG version 1.5.10

@george1421 Yes all of these files aside from the .img files (I guess I could delete the 4th one) although the swapuuids I think was blank. And for d1.mbr it took a bit of guessing but there was some plaintext. I tried all but d1.mbr initially but that wasn’t enough.

@george1421 You’re always there when I need you, you’re doing the Lord’s work. In the future I’ll have to be sure to capture Win 10 2004 images on the smallest possible drive I’ll ever use and/or delete the recovery partition before capturing. Seems to be applying perfectly fine (one of the files wasn’t plaintext though so I had to hope and pray a bit with that one)

@george1421 I’d love it if that worked I’ll try it now

@george1421 Is there any way that I can remove that partition now after the capture has already happened? This image definitely used to work, and the other 2004 image works. Is it related to disk size? If I capture from a specifically small disk will this not be an issue?

@george1421 The command was successful but I still get the same error

@george1421 I get this error I’m sorry I’m not familiar enough with linux to know the equivalent fdisk command

@george1421 the source is windows 10 2004, and yes I still have the FOG debug mode computer open in the same state I took the picture in. The image that works is also Win10 2004

The output of that file is

:1:2

The sata disk is slightly smaller (120GB vs 128GB)

My fog installation recently broke and I had to move everything to a brand new installation. I had another ticket on here but nothing I tried worked so I had to totally reinstall. After that I imaged 300 odd machines of varying models but all with the same image. It worked great, but 2 other images I’ve tried to use this morning have given me GPT Partition errors.

Here’s the error I get with the debug menu

And here is the text of the d1.partitions of the offending image

label: gpt
label-id: 52125BB2-B685-4664-9E80-D66B4B9964E3
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 250069646

/dev/nvme0n1p1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=56BBB14C-0960-4D45-8143-27E070F6BF28, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=9FAFAB3C-9C1B-400D-B2D6-B93C42D9D20B, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      239616, size=   248791157, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=BEC960CC-44EA-45FD-91DC-566179E190BC, name="Basic data partition"
/dev/nvme0n1p4 : start=   249032704, size=     1034240, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=9EEF9D5F-4665-4DAA-978A-D1E793FE25B6, attrs="RequiredPartition GUID:63"

The working image says dev/sda instead of nvme, would changing that in this file fix the issue? I don’t know why it would say nvme

I do want to post the log file as we’re still working on this, I’ve checked all the settings on my network I can think of related to multicast and can’t find anything that will fix it (especially since this has always worked until a week ago) But when I schedule a debug task, it’s not for a multicast session which is the only thing we’re having problems with. Is this log still useful when the image deploys fine normally?

The forum is actually giving me an error when I try to upload the image, but the box in the middle of the part clone page doesn’t even show up, nor do the progress bars. I have updated fog, restarted fog, and am testing multicast with only 2 devices. I’m very confused at this point. @Sebastian-Roth

Unfotunately the last time I tested it I rebooted the server, and used only 2 machines to test the multicast and it still hung at the part clone screen. The way I “fixed” the first error was remaking the image under a different name. I’ve tried multiple multicasts after multiple reboots even prior to your suggestion and it still hangs at the part clone screen. I can take a picture when I go in and test it again today, it seems to hang earlier than even when waiting for all members to join the session.

I’m sorry I haven’t had a chance to do that yet, I can soon and I’ll get that file. But I do know the issue happens on all multicast attempts (even though we normally use them) and not any normal image install attempts. Unfortunately we have 300+ computers to image and not using multicast to do them in larger groups is very slow. Do you know of any common issues where normal image deploy works and multicast throws that error? Also now the error is slightly different. It’s getting to the part clone screen but just hanging before any progress bars show up.

It has a SATA disk, I did capture it from an nvme machine though. Do I need to be sure to capture from the same type of disk?

Yes d1.mbr is there

I just captured an image via Windows 10 sysprep (I have captured many before in the exact same way). It shows on the fog server as being 18GiB. Then immediately when I try to deploy it (multicast if that matters) I get a GPT partition error (see attatched) and then the image shows 0iB from the web management! I’ve never had this happen before and am capturing this image the same way I always have (including several in the past few weeks) the only difference is installed programs. This has happened twice in a row with the same image and same multicast deploy task. I’m posting here because I really don’t want to go through the trouble of creating this image a 3rd time if there’s something bigger going on.

@george1421 No we are running 1.5.5. Unicast images fail most of the time, on some yogas it seems like it works sometimes but in general they fail all in the same way.