I would like this as well, for my schools that I administer.
Posts made by lukebarone
-
RE: Security Request: Integrated Fail2Ban for login window
-
RE: Changed FOG's IP address, system won't boot
Sorry for the late reply… Tried on another computer, and I cannot get the FOG menu to appear (this computer has never registered on that FOG server).
-
RE: Changed FOG's IP address, system won't boot
@george1421 Yes I have. I found that document the first time I ran into the Netboot issue (posted above). I followed it, and the web interface loads (so I thought it was fine). It also let the computers that were stuck in a PXE boot-loop start up and boot into Windows. The current issue is that I can’t image this laptop, or even see the menu. Tomorrow when I’m back on site, I’ll test with another computer as well.
-
Changed FOG's IP address, system won't boot
Possibly related to my old problem, but this is on a separate server.
Running Debian Jessie, I updated the IP address, and systems will boot into Windows if they boot from the NIC. That part is good.
I have a Dell laptop that will not load the menu. When I attempt to boot from the NIC, in BIOS mode (no UEFI), it presents me with a GRUB prompt after downloading the iPXE items (not sure what to call it). It will not launch FOG.
I log into the web interface, find this PC in the list, and start a Deploy (Debug) task, and it will boot me into the Fog OS. It looks good to me, so I type
fog
and press Enter, then it complains it can’t find thefog.postinit
file.It was running 1.3.0. I updated to the latest stable release from GIT, updated the MySQL tables in the web interface, and tried again - no change. I cannot load the FOG menu to select anything. I ran the tftp tests from another computer on the same switch, but no change.
Thoughts?
-
RE: Cannot log in after running Install script again
@Sebastian-Roth I added the new lines to my
/etc/apache2/sites-enabled/001-fog
file, entered my credentials and waited 10 minutes… No change, still getting an HTTP/503 response.I downloaded the script to the FOG server, ran
./updateIP.sh
, and got the following results:Updating the IP Settings server-wide. A password was not set in /opt/fog/.fogsettings for mysql use. Updating the IP in /tftpboot/default.ipxe Backing up /var/www/html//fog/lib/fog/config.class.php Updating the IP inside /var/www/html//fog/lib/fog/config.class.php Updating the fields inside of /opt/fog/.fogsettings All done.
I tried to log in again, and it’s still spinning around (although, it’s only been 2 minutes since I ran the script and tried to log in).
EDIT: It’s working now! After running the script, I also restarted Apache, PHP and MySQL, then tried again:
systemctl restart php7.0-fpm.service apache2.service mysql.service
-
RE: Cannot log in after running Install script again
@Sebastian-Roth Output below:
# ss -antul | grep 9000 tcp LISTEN 0 128 127.0.0.1:9000 *:* # cat /etc/apache2/sites-available/001-fog.conf <VirtualHost *:80> <FilesMatch "\.php$"> SetHandler "proxy:fcgi://127.0.0.1:9000/" </FilesMatch> KeepAlive Off ServerName 10.32.10.2 DocumentRoot /var/www/html/ <Directory /var/www/html/fog/> DirectoryIndex index.php index.html index.htm </Directory> RewriteEngine On RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d RewriteRule ^/fog/(.*)$ /fog/api/index.php [QSA,L] </VirtualHost>
And the config.class.php file looks normal to me.
-
Cannot log in after running Install script again
My network address space changed from 192.168.0.0/23 to 10.32.10.0/23. I did nothing in the FOG config, but noticed PCs that were set to boot from the network first failed.
While searching for fixing it, I came across this page about changing the FOG server IP address. It was 1.5.5 before, so I expected the 1.3.0 instructions to work. I updated the
ipaddress=
parameter, and ran the installation. It completes successfully, and tells me to log in to the Management Interface in my web browser.I type in my FOG username and password, and it hangs. I eventually get it to time out with a 503 error. When I check the Apache Error Log (
/var/log/apache2/error.log
), I see the following line:[proxy_fcgi:error] [pid 597] (70007)The timeout specified has expired: [client 10.32.10.115:50251] AH01075: Error dispatching request to : (polling), referer: http://10.32.10.2/fog/management/
I have tried rebooting the server (Debian 9.8), but no change. I have checked the following as well:
- No firewall is running (
iptables -L
shows everything is Accept) - Lots of free space on all partitions
- 250 MB of used memory, with 2.5 GB free
- No
selinux
installed or activated apt
is updated, and all packages available are installed- Checked
/var/log/php7.0-fpm.log
- the same four lines keep repeated:[25-Mar-2019 09:20:42] NOTICE: fpm is running, pid 6223 [25-Mar-2019 09:20:42] NOTICE: ready to handle connections [25-Mar-2019 09:20:42] NOTICE: systemd monitor interval set to 10000ms [25-Mar-2019 09:25:27] NOTICE: Terminating ... [25-Mar-2019 09:25:27] NOTICE: exiting, bye-bye!
- Restarted
apache2.service
,mysql
, andphp7.0-fpm
, no change. nginx
is not installed, and has never been installed on this server.- Attempted to run the latest stable installfog.sh script from Git Hub - no change
Where can I look next?
- No firewall is running (
-
RE: Win10 1607 LTSB not finding drivers
This worked! Thanks!
I’m disappointed Microsoft’s method doesn’t work anymore, it was super helpful when we were testing Windows 10 at my previous site…
-
RE: Win10 1607 LTSB not finding drivers
@george1421 OK, I’m re-capturing my image, and then I’ll deploy it. I added the commands for PNPUTIL before turning on the Fog Service, as I know it took quite a while to run after I logged in. I’ll report back once I know whether or not this works.
-
Win10 1607 LTSB not finding drivers
I created an image based on the LTSB 1607 Windows 10. I can deploy it fine to the first of a fleet of new machines - Dell Latitude 5590’s.
I have the
fog.drivers
script running after imaging, and theC:\Drivers
folder is populated, so I know FOG is copying the drivers.However, Windows is not looking in that folder during the first boot up, and installing the drivers it needs.
unattend.xml (the part that mentions the Driver path):
... <settings pass="offlineServicing"> <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DriverPaths> <PathAndCredentials wcm:action="add" wcm:keyValue="1"> <Path>C:\Drivers</Path> </PathAndCredentials> </DriverPaths> </component> </settings> ...
The tree of files created (trimmed):
C:\ Drivers\ x64\ audio\ chipset\ ... storage\ video\
fog.drivers Script:
#!/bin/bash ceol=`tput el`; manu=`dmidecode -s system-manufacturer`; case $manu in [Ll][Ee][Nn][Oo][Vv][Oo]) machine=$(dmidecode -s system-version) ;; *[Dd][Ee][Ll][Ll]*) machine=$(dmidecode -s system-product-name) #pruduct is typo, just realized sorry :( ;; *) machine=$(dmidecode -s system-product-name) # Technically, we can remove the dell one as it's the "default" ;; esac [[ -z $machine ]] && return #assuming you want it to break if it is not lenovo or dell? machine="${machine%"${machine##*[![:space:]]}"}" #Removes Trailing Spaces ############################################# # Quick hack to find out if the installed OS image is a x86 or x64 system64="/ntfs/Windows/SysWOW64/regedit.exe" # sloppy detect if 64bit or not [[ ! -f $system64 ]] && arch="x86" || arch="x64" ############################################# #this section has been updated to bring the osn names in line # with how the Dell CABs are defined case $osid in 5) osn="win7" ;; 6) osn="win8" ;; 7) osn="win8.1" ;; 9) osn="win10" ;; esac ############################################# dots "Preparing Drivers" # below creates local folder on imaged pc # this can be anywhere you want just remember # to make sure it matches throughout! (case IS important here) if [ $osid -eq 9 ] then clientdriverpath="/ntfs/Drivers" else clientdriverpath="/ntfs/Windows/inf/Drivers" fi remotedriverpath="/images/drivers/$machine/$osn/$arch" [[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1 echo -n "In Progress" #there's 3 ways you could handle this, #driver cab file, extracted driver files or both #so on the server put extracted driver files to match below folder tree #i.e. Model Latitude E5410, Windows 7 x86 image would be: #/fog/Drivers/Latitude E5410/win7/x86 rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1 [[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]" #this next bit adds driver location on pc to devicepath in registry (so sysprep uses it to reference) # remember to make devicepath= match the path you've used locally #also do not remove %SystemRoot%\inf #and to add more locations just use ; in between each location regfile="/ntfs/Windows/System32/config/SOFTWARE" key="\Microsoft\Windows\CurrentVersion\DevicePath" devpath="%SystemRoot%\DRV;%SystemRoot%\inf;"; reged -e "$regfile" &>/dev/null <<EOFREG ed $key $devpath q y EOFREG echo -e "\b\b\b\b\b\b\b\b\b\b\b${ceol}Done"; # this just removes "In Progress and replaces it with done :-)"
What can I do to get my new images to detect the drivers, and automatically install them correctly?
-
RE: Hyper V and Pxe boot to Fog problems
@paulman9 Can you post the link of how you built that from source?
-
RE: Hyper V and Pxe boot to Fog problems
@jkoos101 I dropped the file into my
/tftpboot
folder on the FOG server. In my DHCP server, I made sure thefilename
attribute matched the filename to server. -
RE: Hyper V and Pxe boot to Fog problems
@paulman9 This worked for me! I could boot to do a Quick Registration, and I’m currently capturing my golden image!
Thank you very much!
-
RE: Hyper V and Pxe boot to Fog problems
@george1421 said in Hyper V and Pxe boot to Fog problems:
Note these are not official iPXE boot loaders, these are tests to see if the certificate code offered by the iPXE developers are causing problems with 1709 based Hyper-V virtual machines
Here is the rom-o-matic build image url for undionly.kpxe and ipxe.kpxe without
#undefine DOWNLOAD_PROTO_HTTPS #undefine IMAGE_TRUST_CMD #undefine CERT_CMD
The following link will create undionly.kpxe (you will need to rename the output of this script to undionly.kpxe since it will default to ipxe.kpxe.
https://rom-o-matic.eu/build.fcgi?BINARY=ipxe.kpxe&BINDIR=bin&REVISION=master&DEBUG=&EMBED.00script.ipxe=%23%21ipxe%0Aisset%20%24%7Bnet0/mac%7D%20%26%26%20ifopen%20net0%20%26%26%20dhcp%20net0%20%7C%7C%20goto%20dhcpnet1%0Aecho%20Received%20DHCP%20answer%20on%20interface%20net0%20%26%26%20goto%20proxycheck%0A%0A%3Adhcpnet1%0Aisset%20%24%7Bnet1/mac%7D%20%26%26%20ifopen%20net1%20%26%26%20dhcp%20net1%20%7C%7C%20goto%20dhcpnet2%0Aecho%20Received%20DHCP%20answer%20on%20interface%20net1%20%26%26%20goto%20proxycheck%0A%0A%3Adhcpnet2%0Aisset%20%24%7Bnet2/mac%7D%20%26%26%20ifopen%20net2%20%26%26%20dhcp%20net2%20%7C%7C%20goto%20dhcpall%0Aecho%20Received%20DHCP%20anser%20on%20infterface%20net2%20%26%26%20goto%20proxycheck%0A%0A%3Adhcpall%0Adhcp%20%26%26%20goto%20proxycheck%20%7C%7C%20goto%20dhcperror%0A%0A%3Adhcperror%0Aprompt%20--key%20s%20--timeout%2010000%20DHCP%20failed%2C%20hit%20%27s%27%20for%20the%20iPXE%20shell%3B%20reboot%20in%2010%20seconds%20%26%26%20shell%20%7C%7C%20reboot%0A%0A%3Aproxycheck%0Aisset%20%24%7Bproxydhcp/next-server%7D%20%26%26%20set%20next-server%20%24%7Bproxydhcp/next-server%7D%20%7C%7C%20goto%20nextservercheck%0A%0A%3Anextservercheck%0Aisset%20%24%7Bnext-server%7D%20%26%26%20goto%20netboot%20%7C%7C%20goto%20setserv%0A%0A%3Asetserv%0Aecho%20-n%20Please%20enter%20tftp%20server%3A%20%26%26%20read%20next-server%20%26%26%20goto%20netboot%20%7C%7C%20goto%20setserv%0A%0A%3Anetboot%0Achain%20tftp%3A//%24%7Bnext-server%7D/default.ipxe%20%7C%7C%0Aprompt%20--key%20s%20--timeout%2010000%20Chainloading%20failed%2C%20hit%20%27s%27%20for%20the%20iPXE%20shell%3B%20reboot%20in%2010%20seconds%20%26%26%20shell%20%7C%7C%20reboot&settings.h/VMWARE_SETTINGS:=1&general.h/PXE_STACK:=1&general.h/PXE_MENU:=1&general.h/DOWNLOAD_PROTO_NFS:=1&general.h/IMAGE_PXE:=1&general.h/IMAGE_SCRIPT:=1&general.h/IMAGE_BZIMAGE:=1&general.h/IMAGE_PNM:=1&general.h/IWMGMT_CMD:=0&general.h/NSLOOKUP_CMD:=1&general.h/TIME_CMD:=1&general.h/DIGEST_CMD:=1&general.h/LOTEST_CMD:=1&general.h/VLAN_CMD:=1&general.h/PXE_CMD:=1&general.h/REBOOT_CMD:=1&general.h/POWEROFF_CMD:=1&general.h/PCI_CMD:=1&general.h/PARAM_CMD:=1&general.h/NEIGHBOUR_CMD:=1&general.h/PING_CMD:=1&general.h/CONSOLE_CMD:=1&general.h/IPSTAT_CMD:=1&general.h/NTP_CMD:=1&console.h/CONSOLE_FRAMEBUFFER:=1&console.h/CONSOLE_VMWARE:=1&general.h/ROM_BANNER_TIMEOUT=40&branding.h/PRODUCT_NAME=FOG%20iPXE&branding.h/PRODUCT_TAG_LINE=FOG%20Network%20Boot%20Firmware&
This produces the error message:
iPXE initialising devices...WARNING: Using legacy NIC wrapper on <MAC Address>
The following link will create the ipxe.kpxe file (all drivers)
https://rom-o-matic.eu/build.fcgi?BINARY=ipxe.kpxe&BINDIR=bin&REVISION=master&DEBUG=&EMBED.00script.ipxe=%23%21ipxe%0Aisset%20%24%7Bnet0/mac%7D%20%26%26%20ifopen%20net0%20%26%26%20dhcp%20net0%20%7C%7C%20goto%20dhcpnet1%0Aecho%20Received%20DHCP%20answer%20on%20interface%20net0%20%26%26%20goto%20proxycheck%0A%0A%3Adhcpnet1%0Aisset%20%24%7Bnet1/mac%7D%20%26%26%20ifopen%20net1%20%26%26%20dhcp%20net1%20%7C%7C%20goto%20dhcpnet2%0Aecho%20Received%20DHCP%20answer%20on%20interface%20net1%20%26%26%20goto%20proxycheck%0A%0A%3Adhcpnet2%0Aisset%20%24%7Bnet2/mac%7D%20%26%26%20ifopen%20net2%20%26%26%20dhcp%20net2%20%7C%7C%20goto%20dhcpall%0Aecho%20Received%20DHCP%20anser%20on%20infterface%20net2%20%26%26%20goto%20proxycheck%0A%0A%3Adhcpall%0Adhcp%20%26%26%20goto%20proxycheck%20%7C%7C%20goto%20dhcperror%0A%0A%3Adhcperror%0Aprompt%20--key%20s%20--timeout%2010000%20DHCP%20failed%2C%20hit%20%27s%27%20for%20the%20iPXE%20shell%3B%20reboot%20in%2010%20seconds%20%26%26%20shell%20%7C%7C%20reboot%0A%0A%3Aproxycheck%0Aisset%20%24%7Bproxydhcp/next-server%7D%20%26%26%20set%20next-server%20%24%7Bproxydhcp/next-server%7D%20%7C%7C%20goto%20nextservercheck%0A%0A%3Anextservercheck%0Aisset%20%24%7Bnext-server%7D%20%26%26%20goto%20netboot%20%7C%7C%20goto%20setserv%0A%0A%3Asetserv%0Aecho%20-n%20Please%20enter%20tftp%20server%3A%20%26%26%20read%20next-server%20%26%26%20goto%20netboot%20%7C%7C%20goto%20setserv%0A%0A%3Anetboot%0Achain%20tftp%3A//%24%7Bnext-server%7D/default.ipxe%20%7C%7C%0Aprompt%20--key%20s%20--timeout%2010000%20Chainloading%20failed%2C%20hit%20%27s%27%20for%20the%20iPXE%20shell%3B%20reboot%20in%2010%20seconds%20%26%26%20shell%20%7C%7C%20reboot&settings.h/VMWARE_SETTINGS:=1&general.h/PXE_STACK:=1&general.h/PXE_MENU:=1&general.h/DOWNLOAD_PROTO_NFS:=1&general.h/IMAGE_PXE:=1&general.h/IMAGE_SCRIPT:=1&general.h/IMAGE_BZIMAGE:=1&general.h/IMAGE_PNM:=1&general.h/IWMGMT_CMD:=0&general.h/NSLOOKUP_CMD:=1&general.h/TIME_CMD:=1&general.h/DIGEST_CMD:=1&general.h/LOTEST_CMD:=1&general.h/VLAN_CMD:=1&general.h/PXE_CMD:=1&general.h/REBOOT_CMD:=1&general.h/POWEROFF_CMD:=1&general.h/PCI_CMD:=1&general.h/PARAM_CMD:=1&general.h/NEIGHBOUR_CMD:=1&general.h/PING_CMD:=1&general.h/CONSOLE_CMD:=1&general.h/IPSTAT_CMD:=1&general.h/NTP_CMD:=1&console.h/CONSOLE_FRAMEBUFFER:=1&console.h/CONSOLE_VMWARE:=1&general.h/ROM_BANNER_TIMEOUT=40&branding.h/PRODUCT_NAME=FOG%20iPXE&branding.h/PRODUCT_TAG_LINE=FOG%20Network%20Boot%20Firmware&
Same screen with the second file as well. Still stalls out, so it does not go past that.
-
RE: Hyper V and Pxe boot to Fog problems
@george1421 said in Hyper V and Pxe boot to Fog problems:
@paulman9 OK great, that means that the currently shipping version of iPXE does resolve your issue. I suspected that it would not work 100%, but what did work was getting past the initializing devices. I’ll take a look at creating the full undionly.kpxe boot kernel in a while for you to test. But for now it looks like we have a path forward.
@Developers be aware that the current version of iPXE addresses hyper-v booting. I’ve seen this in a few threads lately.
I’m at this stage. The
params: command not found
issue. I saw earlier in the thread that people were trying on Gen 1 VMs, which would be BIOS-compatible. If you need, I can start a new thread?I’m using the custom
undionly_546dd.kpxe
file you uploaded on your Google Drive to get this far. -
RE: Hyper V and Pxe boot to Fog problems
@george1421 I get “PXE-E79: NBP is too big to fit in free base memory”. The VM is Windows 7, on Gen 1 Hyper-V.
-
RE: Hyper V and Pxe boot to Fog problems
Is there any update on this? Or are we waiting on the iPXE crew to fix it?
-
RE: Black screen when attempting to Perform full registration and inventory on Dell Latitude 5580
@george1421 I’m 99% sure it was the suggestion of something I found on the forums a long time ago, but simply forgot.
Like I said, once everything calms down, I’m planning on rebuilding my FOG machine anyways, and blast away old images, especially since I can drop driver packs in now
-
RE: Black screen when attempting to Perform full registration and inventory on Dell Latitude 5580
@tom-elliott Me are stupid -.-
Under the Fog Configuration -> iPXE Menu Configuration -> fog.reginput -> Boot Options:, I had " pci=noacpi" added for some reason. I removed it (after seeing that it wasn’t there on Quick Registration), and I can now boot directly to the Registration screen!
I can’t wait for the spare time to just rebuild a FOG server from scratch and copy over the machines I need… -.- Sorry to have wasted so much time with everyone on this issue
-
RE: Black screen when attempting to Perform full registration and inventory on Dell Latitude 5580
@sebastian-roth I guess the other question is, can I just simply delete one of the FOG folders, and it would be “uninstalled”?