@Sebastian-Roth said in FOG 1.5.6: Deploy is leaving remnants of previous data:

What exactly goes wrong? Error message?!

I told you before. It’s complaining my unattended setup answer file is invalid during the first boot of the deployed image (the part where Windows figures out what it’s running on.) And it doesn’t do it every time, only like… 70% of the time, and only on UEFI deployments. Legacy deployments are unaffected. Same answer file, same setup for the Windows image, except the UEFI/legacy partition layout differences, and DOS vs. GPT style partition tables.

I’m also attacking this from the Windows angle too, trying to make a new answer file to put into my images, but of course, Microsoft’s tools are malfunctioning on me as well.

It’s possible I’m incorrect in my assumption that there is data remnants causing issues.

Basically the error I get, during Windows first-boot is it’s complaining my unattended setup answer file is incorrect. But it’s not doing it for every deployment. Seems random. I think my image is just messed up.

However. It would still be nice to be able to nuke a portion of the drive with all zeros if needed for some reason. Maybe an optional place to insert a ‘dd’ command line during the deployment. I don’t think it’s entirely necessary, but could be handy.

I was honestly just going to pull at the threads of this thing to find the deployment scripts and slide in a dd drive nuking command myself. But it may be unnecessary. The randomness of my issue made me believe it’s data remnants. But hand-nuking drives yield no better result.

I’ll mark this as solved since it appears to be me, not FOG.
EDIT: Can’t seem to change the solved/unsolved status of this topic. So, just tag it solved for now, since I’m pretty sure it’s my mistake, not FOG.

2nd EDIT: I did want to mention, I am only encountering this issue on UEFI deployments. Normal legacy (BIOS) deployments are unaffected. Which is partly why I was suspecting FOG of messing something up, or leaving junk behind that Windows was finding and choking on. On UEFI, I will mention, I have not successfully created a PXE boot environment that works on UEFI machines, so I do have to flip target machines back to legacy BIOS mode to do the deployment, then flip it back to UEFI/Secure Boot afterwards to boot up the machine. This is when the issue comes up. Since the error I’m getting is complaining about my unattended answer file being messed up, this seems relevant. I’m using the same answer file for all my images (there’s 6 of them.) and only the UEFI deployments are choking on it. So… not sure what’s going on there. Going to regenerate my answer file with the Windows ADK today to see if that will fix things. Maybe something changed in 1903 UEFI that the legacy deployments are unaffected by.

One more edit haha: On the unattended setup answer file, in the past, if this file was malformed in anyway, sysprep would bitch right out of the gate and refuse to run. I am not encountering that, it’s only when the image is deployed and booted (UEFI only) that something goes weird.

I’m not sure how much collecting that information is going to help. These partitions are NORMAL in every respect. I am creating them myself as part of my configuring the system before capturing it.

The partition is basically created after I sysprep my image and seal it. I use a rescue media to slide my operating system partition 10GB to the right (creating a gap between the operating system partition and all the partitions before it.) Then I create my partition, a normal Windows NTFS partition, copy my CD image to it, do some other magic so Windows can boot it as a recovery partition and run Windows setup directly.

So. It’s not really a defect in your partition detection scheme, in fact, I’d say that is working properly, since going back in and changing the partition types from normal NTFS to hidden NTFS tells FOG to leave it alone.

What we need is a way to specify which partitions to resize in the image spec. I’m not exactly sure how auto-resize would even work if more than one partition is being resized. How does it decide what size to make the partitions if there’s more than one?

What it should do, again, previous version (sorry, don’t have version # handy.), it would only attempt to resize the last partition. This is precisely why my weird process of sliding my operating system to the right to insert a partition BEFORE it, because that worked before.

I can collect the data requested, but I’m not sure it’s really going to tell you anything I haven’t already told you.

I am encountering an issue where FOG 1.5.6 is not fully overwriting the beginning of a target drive on deploy.

I’m not entire sure what’s going on, all I know is, sometimes my Windows 10 deployments are failing with strange errors.

To fix these machines, I have to boot up a linux rescue CD, use DD to zero the first 100MB of the target disk, then deployments work without issue. Incorrect, it’s just intermittently failing. Wiping the disk has no effect.

So FOG is leaving junk behind on the drives that is interfering with Windows 10 somehow. It would be nice to have an option in for deployment to zero a portion of the drive (I like to nuke the first 100MB, but making this flexible would be great.)

Basically, when using FOG to deploy Windows 10, I’m running into some issues with the partition resize mechanism.

On previous versions of FOG (Sorry don’t have version numbers handy.), the auto-resize would only go after the last partition on the machine. So for example if you have this layout:
partition 1: 500MB Windows Reserved
partition 2: 10GB Windows Recovery
partition 3: XXXGB Operating System

And you capture this, with a previous verison of FOG, it would automatically not touch the first two partitions, capturing them as is, no resize. And the final partition would be shrunk to minimum size before capture. On deploying this image to a new computer, the first two partitions are put back exactly as they were captured, while the last partition would be resized to fill the rest of the target disk.

In this version of FOG (1.5.6), this is not what happens. In the layout given, it would resize both partition 2 and 3 to minimum size and capture. When deploying this image, the result would be unpredictable. I have seen it leave the second partition at minimum size, or expand it to 30GB, why I have no idea. But the worst of it, is it doesn’t resize the final partition to fill the entire drive’s remaining space. Sometimes it does. Sometimes it doesn’t. It’s completely unpredictable.

Now I have discovered a work-around for this issue. By booting a linux rescue CD and flagging my recovery partition as either Hidden NTFS (MBR partition table) or Windows Reserverd (GPT partition table), the FOG capture will notice this and not attempt to resize my recovery partition. Under these conditions, it seems to properly resize the final partition to fill the remainder of the drive.

What would be best, is something in the image specification that allows us to control which partitions are resized.

It wasn’t something I wanted to do, it was something I did by mistake.

I was just pointing out it is a flaw in the software, it should be possible to get at the mac-address-less host to fix it or delete it.

So basically, do this:

Create at least two hosts with different MAC addresses. Save this stuff.

Now edit one of the hosts and add the MAC address from the other host to this one.

The original host will stop appearing in your host list after doing this. You cannot recreate or edit the host, it’s stuck in limbo, with no mac address. There’s no way to get it back. And you can’t use the same name because it’ll complain that host already exists.

The only way I could fix this was to jump on to my fog server, fire up mysql client and remove the record for that host by hand.

Might wanna fix that. Great software otherwise.

Also another suggestion: Make this stuff work on a multi-homed server. That would be really great.

I do not need support for this issue. This is a bug report. I will not be following this thread in any way shape or form.