We use Sophos AV, too, and before sysprepping and pulling the image I uninstall Sophos AV, but just the program itself, not the Auto-Update application, which is separate.
After putting the image on another PC, Sophos AV is automatically installed via the Auto-Update, that was still on the image (including the update information, i.e. where to download it from). Has always worked for me this way.
I have to take back, what I said earlier.
When I first tried to migrate the database, I apparently did something wrong while exporting the db, because the size of the dump wasn’t nearly as big as it is now, when I tried it again. I now was able to successfully import the database and I have hosts, image definitions and users showing up properly in the web interface.
The next step is to perform all of this on my actual FOG server, as this was only a test with a VM.
Thanks for the help everyone!
Before you take the image:
After the deploy Sophos should now automatically install. At least that’s how I do it, no Snapins needed.
With the new init (20211107) I re-captured from a SSD machine and was finally able to deploy to a HDD machine. So I guess the fixes can be implemented in the next official release. Thank you Sebastian!
I re-captured an image on a SSD machine (with the new init) and deployed to the HDD machine, but got the same error message as before.
From the re-captured image:
d1.minimum.partitions:
label: gpt
label-id: 8C0CB60E-93F5-4C14-B633-3852928F826C
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 1000215182
sector-size: 512
/dev/nvme0n1p1 : start= 2048, size= 1433600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=2AFFEC30-5F77-4C6B-BA7C-902A01A971E1, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start= 1435648, size= 262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=E8336B4A-8C8F-48F5-85DE-E6237B7A372F, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1697792, size= 995426761, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=38131294-BD57-43F5-ACE4-2E1413614C9A, name="Basic data partition"
/dev/nvme0n1p4 : start= 997126144, size= 1060864, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=A31B261E-E3EB-4671-BE66-F71AEEB51DB8, attrs="RequiredPartition GUID:63"
/dev/nvme0n1p5 : start= 998187520, size= 2027520, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=84072955-EDFD-4E05-84E6-C3A6C50CDB30, name="attrs=\x22RequiredPartition GUID:63
d1.partitions:
label: gpt
label-id: 8C0CB60E-93F5-4C14-B633-3852928F826C
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 1000215182
sector-size: 512
/dev/nvme0n1p1 : start= 2048, size= 1433600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=2AFFEC30-5F77-4C6B-BA7C-902A01A971E1, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start= 1435648, size= 262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=E8336B4A-8C8F-48F5-85DE-E6237B7A372F, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1697792, size= 995426761, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=38131294-BD57-43F5-ACE4-2E1413614C9A, name="Basic data partition"
/dev/nvme0n1p4 : start= 997126144, size= 1060864, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=A31B261E-E3EB-4671-BE66-F71AEEB51DB8, attrs="RequiredPartition GUID:63"
/dev/nvme0n1p5 : start= 998187520, size= 2027520, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=84072955-EDFD-4E05-84E6-C3A6C50CDB30, name="attrs=\x22RequiredPartition GUID:63"
The third partition still seems to be too big (i.e. not shrunk), do you agree?
@sebastian-roth said in FOG deploy: partitions 4 and 5 too big for disk:
Sure thing. As I said in my last post you should capture and deploy. In your case the already captured image doesn’t have the proper shrunken partition layout and therefore can’t be deployed to a smaller size disk I suppose. If you try deploy those Win 10 images to a large disk, do they fail just the same way? If so I ask you to take a picture of the error on screen and post that here.
Ok, I think I might get my hands on one of the SSD machines later this (or next) week. I will then re-capture, deploy and report back.
FYI:
Just for the fun of it, I tried to deploy an Windows 7 image from 2018, which worked perfectly fine, but all my Windows 10 images fail.
@sebastian-roth said in FOG deploy: partitions 4 and 5 too big for disk:
@madeyem Please download this FOS init and try capture or deploy again. The issue should be fixed.
I replaced the default init.xz with the one you linked and tried to deploy, but unfortunately I still get the same error message. The correct init version is shown (20211009).
I can try to re-capture an image as soon as I have one of the SSD machines at my disposal (or when the new PCs I ordered finally arrive).
@sebastian-roth said in FOG deploy: partitions 4 and 5 too big for disk:
@madeyem Please download this FOS init and try capture or deploy again. The issue should be fixed.
I’m currently on vacation for two weeks. I will report back, as soon as I’m back in the office and have tested it. Thanks!
@sebastian-roth said in FOG deploy: partitions 4 and 5 too big for disk:
@madeyem Ok, I had another look at this and I have to say that my initial thought was right. Your issue is caused by the same problem discussed in the other forum topic mentioned before.
I can say that FOG 1.5.7 would not have been able to shrink this layout either I am pretty sure!
Proofed myself wrong!
I will look into fixing what is causing this in the inits. Will let you know as soon as I have it ready for testing.
Ok, thank you!
@sebastian-roth said in FOG deploy: partitions 4 and 5 too big for disk:
@madeyem said in FOG deploy: partitions 4 and 5 too big for disk:
I can say, that I did not have any problems under FOG 1.5.7, which I used for a long time. I will see, what I can do.
I can say that FOG 1.5.7 would not have been able to shrink this layout either I am pretty sure!
ok 
@sebastian-roth said in FOG deploy: partitions 4 and 5 too big for disk:
@madeyem Don’t you have a so called master machine that you use to build your “golden setup” on to capture an image from (the same machine every time)?
Unfortunately not.
Not that I know of. We are missing some information here. No idea why this fails in your specific case. Does not seem to be a general issue.
I can say, that I did not have any problems under FOG 1.5.7, which I used for a long time. I will see, what I can do.
