@davido38 said in kernel panic:

After update fog from 1.5.6 to 1.5.7 i have kernel panic

As George just said this shouldn’t happen on an upgrade. The schema update should take care of this. Possibly you have not opened the web UI since upgrading??

@cammykool Is this topic still being discussed or done? From what I see in the PCAP the PXE boot cannot work. No servername (next server) given, two DHCP answers that might confuse the client…

@Jurgen-Goedbloed I am not exactly sure I get what you say. Has the SSL path option been wrong? What was it set to? Is this something the installer messed up?

Or do you mean the permissions were causing this issue? I have not messed with umask in a long time but I do remember this can cause quite some unexpected situations. I can imagine this could also cause trouble in other places where the FOG installer does not explicitly set permissions.

Just in case anyone comes across this. The version used here (0.11.0) had an issue with that. The most current version (0.11.16 as of now) is known to do rename/ad join, reboot, snapin properly (ref).

@Mr-Taco Here is an article from Chris at Microsoft that covers reimaging rights. https://community.spiceworks.com/how_to/124056-reimaging-rights-for-windows-10-licensing-how-to

I can tell you that if you have 100 Window 10 OEM licenses, you only need to purchase (1) Windows 10 Pro VLK key to deploy to all 100 of those Windows 10 Pro OEM machines. That rule only works for the same version. You can not purchase 1 Windows 10 Enterprise VLK key to do a version upgrade to those 100 Win10 Pro OEM machines. For a version upgrade you need a 1 for 1 volume key. So 100 OEM would require 100 Enterprise keys.

But back on the 1 Win10 Pro VLK key, you can purchase that key but you need to get a count of 5 so people will often purchase Win 10 Pro VLK key and 4 windows (4) server CALs (or something else cheap that you can’t get enough of anyway) to get to your count of 5.

@Quazz and @george1421 Thank you both. I appreciate the assistance. I tried ipxe.efi and it worked! I now have my Dell Optiplex models PXE booting using UEFI just the way I was hoping. Only oddities is the screens are a bit smaller, and the PXE boot shortcut is now “esc” instead of my custom shortcut. That is a small first world problem however. Thank you all again this community is fantastic!

@Arjenbulkens Any news on this?

@vanopstp15d try

mysqlcheck -r fog

There is a wiki page to reset the default fog admin’s password. Its here: https://wiki.fogproject.org/wiki/index.php/Reset_WebUI_FOG_password

I would also look at both the apache and php-fpm’s log files in /var/logs directory to see if there is any error messages listed in there.

Next Server IP address was wrong on DHCP server. TFTP is working now! Thank you @george1421

@rodluz said in 503 Error and stuck at "attempting to update database":

So I changed the pm.max_children setting to 150

Good catch on the max_children setting. If you would have had a current version of FOG that setting would be 35. I think 150 is a bit excessive since each child consumes ram. I think 50 might be a better choice to start with. Most people don’t start 20 simultaneous unicast streams so I can say we’ve not run into this issue before with the standard 35 max children. 5 IS a bit low.

So to recap you had 2 issues, one was the memory limit and the other was the max children setting.

Once you get past your image push crunch, you might consider upgrading to the latest version of FOG.

Well I can say, that is a VERY good question. FOG is only intended to clone local block level devices. iSCSI is not necessarily in scope. With that said, it would be interesting to see it work. 😉

So let me ask you this, if you manually register this VM and then schedule a debug deploy task (tick the debug checkbox before you hit the the schedule task button. Then pxe boot the VM. This will drop you to a linux command prompt on the VM. So to the question (since you seem to be familiar with iSCSI) can you mount the iSCSI lun from the FOS Linux client? If you can then we might have a solution. I don’t know off the top of my head if the iscsi tools are install in FOG Linux (they should be but I don’t know for absolute). If you can connect to the iSCSI LUN then document the process so we can create a bash script to do the same.

@Sebastian-Roth It’s worked ! I’ve done your solution three times in a row and it seems worked.
Thanks you for your job and your disponibility.

@Atton So now you can ping the workstation by their short windows names?

It did run as expected when I included the bash reference at the top of the copy script and changed the mode of the new fog.download script to 755.

You should see the script run right after FOS Linux picks up an IP address. The line will start out with * Running post init scripts.......

You should have a chance to see that message if you run the fog compatibility checker from the iPXE menu.

Just figure it out. I used dnsmasq and I changed its configuration file to my new ip address and my client computer could boot fog.

@Veerakumar Thanks for the update. I was wondering why you wanted to use that other field in the “FOG Boot settings”…

As always, the community comes through! Not sure how this got askew, but following these directions I was able to fix the issues. The image pulled correctly and at the end updated the database info. The image is good, I am all set. Thank you again this was awesome!

@nelsonnc Sounds a bit like STP issue to me as well. The quickest way to check is to connect a dumb mini switch between that client and your building switch. See if that makes a difference.

How do you know the client can reach the FOG server? When it’s booted to it’s OS from disk, can you open that exact URL in the browser on that client? http://dlk.fog.local/fog//index.php (double slash is not an issue)

Turns out someone was annoyed that our network went down and plugged in their personal router. Thank you for the advice.