@dustindizzle11 Thanks for the heads up. Possibly I need to revisit what I said. Possibly there is a huge difference and it does make FOG run much faster in your case (and possibly for others as well). What I could think of is the php-fpm issue we still have in FOG 1.5.4 (see George’s post here). What is yours set to on Debian?

Auto logon values are stored in the registry. Run the following PowerShell script to determine your current AutoLogon settings.

$path = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' $AutoAdminLogon = (Get-ItemProperty -Path $path).AutoAdminLogon $DefaultUserName = (Get-ItemProperty -Path $path).DefaultUserName $DefaultPassword = (Get-ItemProperty -Path $path).DefaultPassword $AutoLogonCount = (Get-ItemProperty -Path $path).AutoLogonCount Write-Host "Current AutoLogon Settings:" -ForegroundColor Yellow Write-Host "AutoAdminLogon: $AutoAdminLogon" Write-Host "DefaultUserName: $DefaultUserName" Write-Host "DefaultPassword: $DefaultPassword" Write-Host "AutoLogonCount: $AutoLogonCount"

Output from my Windows 10 1607 laptop:

Current AutoLogon Settings: AutoAdminLogon: 0 DefaultUserName: Administrator DefaultPassword: AutoLogonCount:

AutoAdminLogon has two states. If it’s 0, then it’s disabled. If it’s 1, then it’s turned on.
AutoLogonCount indicates the remaining number of automatic logons. This number decreases by one every time the computer restarts, until it reaches 0. When it reaches 0, it changes AutoAdminLogon to 0 and clears the DefaultPassword. Setting this to any number below 0 will effectively set your computer to automatically logon forever.

@dustindizzle11 Great you got this hacked… 🕶 Thanks for letting us know! Marking this solved for now. Let us know if you run into another issue with this.

@Tom-Elliott I see. Ya it should have at least told me what interface after the “from”, didn’t realize that until now. Thanks Tom!

If you upgraded your main fog server to 1.4.0RCx without issue then your storage nodes will update without issue. The storage nodes use a subset of the features of the master node. In that they do not have a local database (mysql and ftp) seem to cause us the most issues during the upgrade.

With that said, expect issues (we are here to help). When it works successfully be happy and move onto the next issue.

@dustindizzle11 Thank you for sharing what you’ve learned> I’m sure it will help others as they find this thread in the future. Well done!!

@dustindizzle11 Sorry for my late reply. There is a side way you could go with this now that you know how to modify the init.xz image. Grep yourself a copy of the current script and exchange the one you posted with this new one. See if you can make it work with this. Just an idea for a quick dirty fix.

@dustindizzle11 It would be nice, and this has been asked for several times. In order to implement it, I believe a lot of code would need edited and rewritten. It would include changes in the database, the inits, the web interface - we would likely need an entire new management page just for domains.

I would even like the feature. But I would rather put it off till 2.0 in order to get 1.3.0 out faster.

Right now, if you want to be able to have the right domain info inserted for a host during a full-registration via the boot menu, the way to do this currently is to set your AD defaults to what you would want them to be.

@Wayne-Workman Ubuntu Server 14.04

@Wayne-Workman While that is true, it’s not always a possibility.

I would highly recommend upgrading if that was an option, but from the sounds of it, this is not necessarily the case. I’d really highly recommend going to trunk rather than 1.2 as well, if only so I can get more feedback on bugs and what not.

@dustindizzle11

We are requesting that all community members who have Surface Pros to please do a packet capture, to capture the DHCP conversation the client sends out at boot time via the ethernet dock, and upload the capture here. The intent is to gather more information about the Surface Pro, so fog can better support network booting it.

Thanks,
Wayne

Sure you followed this part of Tom’s suggestion: “cd to your fog web directory”?
If not the command might have tried to search through all the files on your whole system. That’s not a real problem bust usually does not come to an end because it hangs when trying to read pipe files (stuff mostly sitting in /var …).

The string is found in those files:

./management/index.php:ob_start('ob_gzhandler'); ./management/static/help.php:ob_start('ob_gzhandler'); ./lib/fog/ProcessLogin.class.php: ob_start('ob_gzhandler'); ./lib/fog/ProcessLogin.class.php: ob_start('ob_gzhandler');

See if you can fix things for you.

@dustindizzle11 This is a well known issue with 1.2. I fixed it almost two revs after releasing 1.2.0, but had many other bits that made it unfeasible to come out with another fix (and it was mid imaging season.)

if you’re still having issues with the “vista” setting, your best bet would be to upgrade to a trunk version of fog where it’s already fixed.

It’s not a pain at all.

If anything it points out a potential issue, though why it didn’t send the image down I don’t know. My guess, ftp user/pass incorrect for those three problematic nodes.

@crosser said:

@Wayne-Workman

Possible? Yes. Practical? Not really, since we have quite a few legacy models.

What I think I might do though is leave our old FOG 0.32 server running in case we need to use it for these specific legacy images.

Thanks again to everyone on the FOG team for all of the development and support you all do!

That’s a good choice. Sorry we couldn’t help more, but this issue is pretty bizarre.

@Tom-Elliott
Makes perfect sense. Thanks again Tom!😃

@Trevelyan Yes, I just restarted it to test, and it came right back up and I was able to login. So it looks good so far! Thanks for trying to help so much btw, I really appreciate it.