Posting a bug from a previous thread: https://forums.fogproject.org/topic/8333/wipe-and-image-from-pxe

What we ended up finding was that the Normal wipe procedures take about 30 minutes to run on a VM. I’m not sure if this is typical behavior, but it takes about 15 minutes for a Full wipe to run and it shows the progress along the way. I would assume that the Normal wipe would be about 1/4th the amount of time.

When doing a normal wipe, the boot process hangs here:

It does wipe the drive ultimately.

So it could be that the Normal wipe is messed up in two regards (taking a super long time and showing no progress) OR the Full wipe which does show progress is much faster than it should be and isn’t doing an actual full wipe. Happy to help where I can, thanks for looking into this.

@Tom-Elliott Ah ok cool, I wasn’t sure if that other person had the same thing. Glad you were able to catch this, great work!

Any chance we can tie this into defaulting the hostname change during full registration rather than ticking a checkbox on the host under AD settings? Just a thought - thanks again!

@lukebarone I am having the same issue after an install to RC-9 today. I can’t do the full registration either. Here is what I am seeing:

When selecting full registration, the machine scrolls through the following new messages, and then prompts to enter in the computer information (just like usual) then instead of immediately imaging after taking inventory, it reboots, and registers the computers under a different name than what I provided in the registration (sometimes the MAC, sometimes random characters). Then it boots back to the PXE after the registration and never actually deploys the image.

If I select the iPXE menu item to Deploy Image, it prompts for username and password, I can select the image, it shows the same new messages below, but then actually deploys the image successfully.

Happy to help troubleshoot or provide logs, etc.

Thanks for the tip @george1421 I’m not sure it works for the scenario I am working on, but none the less, good idea for future items too, more than just name changes.

@Wayne-Workman hey, thanks for the information back. Sorry, I am certainly not trying to be a PITA for you guys, this product is awesome

I do like the idea of having it automatically enabled during the full registration, or maybe allowing a setting that would make it automatic during full registration in case not everyone likes it. Also, totally understand the instantaneous name change part. That explains the reboot just fine and you are right, it would be normal to reboot at that time, just making sure that is what it was.

Thanks again, happy to help test certain features out.

@Wayne-Workman Yes, sorry, I thought I had this in my notes. Not adding these machines to a Domain, just imaging on a workgroup. But yes, we have the same issue at my company, +/- 5 minutes of the DC’s time or else Kerberos authentication will block domain activity. Sadly, not joining one here.

So I tested that checkbox and it looks like it worked. But, it didn’t work during the initial setup. Also, its a little tricky because that checkbox isn’t available until the host is registered with the server. So in my example, I am doing a full registration, which means it isn’t on the server at all. When I do the full registration, then I would need to go in and check that box for all of my devices, and if I’m doing a bunch of machines, it would be a little annoying. That’s why I wasn’t sure if there was a way around this.

Something new that happened during this deployment, with that checkbox ticked, was it booted to the OS, I was able to work in there for about 2 minutes, and then the computer randomly rebooted. I can’t remember if it changed the name during that time, or if it had done it earlier. I’ll test this a bit, but would love to know if there was a way to get it to do the hostname change without having a domain or without having to check that box on each machine on the server.

Thanks all, this product is awesome!

Thanks, yes, I saw the client setup with sysprep. I confirmed it is disabled before I take the sysprep, and enable it in setupcomplete. I know this is working, because the windows 7 key is activating.

I just checked the FOG settings and saw the experimental feature that changes the hostname early. I unchecked this and deployed an image, but that didn’t change the issue.

The Administrative username I use for the computers is DRSAdmin. The computer names are: DRSAdmi-xxxxxx (perhaps some sort of serial), but those are all random.

Below are the logs, you can see in my most recent test (not 1:55 am, its a VM and the time is off which I don’t think is the issue because it happens on laptops too)
You can see the computer name: DRSADMI-FTJ0QC3

Then below in the “Hostname Changer” log section, that same log repeats itself every 2 minutes, along with a few other items, but this is the one I’m most interested in. Curious to see if others have this issue.

------------------------------------------------------------------------------
----------------------------------UserTracker---------------------------------
------------------------------------------------------------------------------
 9/3/2016 1:54 AM Client-Info Client Version: 0.11.5
 9/3/2016 1:54 AM Client-Info Client OS:      Windows
 9/3/2016 1:54 AM Client-Info Server Version: 1.3.0-RC-8
 9/3/2016 1:54 AM Middleware::Response Success
 9/3/2016 1:54 AM Middleware::Communication URL: http://fog/fog/service/usertracking.report.php?action=login&user=DRSADMI-FTJ0QC3\Student&mac=00:0C:29:CE:06:7A||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&newService&json
------------------------------------------------------------------------------

 9/3/2016 1:54 AM Middleware::Communication URL: http://fog/fog/management/index.php?sub=requestClientInfo&configure&newService&json
 9/3/2016 1:54 AM Middleware::Response Success
 9/3/2016 1:54 AM Service Sleeping for 81 seconds
 9/3/2016 1:55 AM Middleware::Communication URL: http://fog/fog/management/index.php?sub=requestClientInfo&mac=00:0C:29:CE:06:7A||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&newService&json
 9/3/2016 1:55 AM Middleware::Response Success
 9/3/2016 1:55 AM Middleware::Communication URL: http://fog/fog/service/getversion.php?clientver&newService&json
 9/3/2016 1:55 AM Middleware::Communication URL: http://fog/fog/service/getversion.php?newService&json

 9/3/2016 1:55 AM Service Creating user agent cache
 9/3/2016 1:55 AM Middleware::Response Invalid time
 9/3/2016 1:55 AM Middleware::Response No Printers
 9/3/2016 1:55 AM Middleware::Response Module is disabled globally on the FOG server





------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
 9/3/2016 1:55 AM Client-Info Client Version: 0.11.5
 9/3/2016 1:55 AM Client-Info Client OS:      Windows
 9/3/2016 1:55 AM Client-Info Server Version: 1.3.0-RC-8
 9/3/2016 1:55 AM Middleware::Response Success
 9/3/2016 1:55 AM HostnameChanger Users still logged in and enforce is disabled, delaying any further actions
------------------------------------------------------------------------------```

Hey all, minor issue but searched around and couldn’t find a fix from any recent thread.

I am booting a laptop to the iPXE and doing the full host registration step. Which is really nice because I can apply a lot of settings before imaging!

I give the computer a hostname, windows key, etc. When I deploy the image, it changes the key and activates no problem, but the hostname doesn’t change. The unattend file doesn’t specify a hostname either. The log for fog on the C drive says under the Hostname Changer section that the key is correct, activated and nothing else to do.

The host on the fog server sees the hostname that I give it during registration.

I checked the command: hostname, and the hostname in the registry and they all show the same thing that the System properties show (which is a randomly generated name).

Running Fog 1.3.0 RC8 on Centos 7.

Appreciate any help and support.

Thanks, yes, I didn’t even have it installed until last night, and I did disable it and have it re-enable in the new system. I like 1.3 because it shows up as a pending host automatically which is awesome. Just need to get name changing working from the Fog server and I’ll be set.

Thanks again everyone!

Ok, so I am about to shove rusted forks into my eyeballs. In short, this issue is resolved, but I don’t know what it is.

Whilst waiting and testing, I decided to take some time and work on polishing my reference image. I installed the fog client, a couple of other applications. I changed my unattend.xml to activate the built in administrator account, gave it a password, and did some other small adjustments to a SetupComplete file that didn’t exist in the first place, because I didn’t think it needed to be there if it didn’t serve much purpose at the time, especially for just a blank OS to be dropped.

Anyway, thank you all for your help and knowledge through this process. Feel free to mark solved, or at least solved (not a FOG issue).

@Avaryan Thank you, sometimes the simple answers are easiest to forget

http://pastebin.com/303D9uyj