In case anyone else has this question, the Reports tab serves this purpose. Once an AD user logs into FOG and starts doing things, the history report will log it.
Best posts made by DBCountMan
-
RE: Set up LDAP for FOG, but FOG activites aren't tracking AD users
-
RE: Boot FOG on client PC using a special partition?
Got it working! This worked for me after making sure the drive was changed to GPT and I also labeled the efi parition as “EFI”:
menuentry “Windows” {
insmod chain
insmod ntfs
insmod part_gpt
set root=(hd1,gpt2)
chainloader (hd1,gpt2)/efi/microsoft/boot/bootmgfw.efi
}Just realized that the set root part is redundant. I am partitoning the drive now to copy the files from the FOG USB key then tell the UEFI on the PC to boot from this new GRUB partition first. Looking good!
-
RE: Use http instead of tftp for fetching kernel and initrd
@londonfog as long as you don’t put any custom files in /var/www/fog you should be good. I have pmagic on my fog ipxe menu and put the files in /var/www/pm11_winpe and the permissions for the files are correct.
This is what my ipxe menu item parameters look like:
set tftp-path tftp://${fog-ip}
set web-path http://${fog-ip}
set pe-path ${web-path}/pm11_winpe
kernel ${tftp-path}/wimboot gui
imgfetch --name BCD ${pe-path}/BCD BCD
imgfetch --name boot.sdi ${pe-path}/boot.sdi boot.sdi
imgfetch --name bootmgr ${pe-path}/bootmgr bootmgr
imgfetch --name boot.wim ${pe-path}/boot.wim boot.wim
boot || goto MENU -
RE: Boot UEFI mode slow
Try updating the Kernel drivers? I’ve seen varying ipxe performance from different hardware. For example, I’ve seen ipxe boot faster on an Optiplex 7020 vs 3020 which is a newer model.
-
RE: Use HTTP instead of TFTP for fetching WIM files
Success! Dropped the files into /var/www and used set web-path to ${fog-ip}. In case anyone else has this issue this is my iPXE menu item parameters:
set tftp-path tftp://${fog-ip}/os
set web-path http://${fog-ip}
set pe-path ${web-path}/pm11_winpe
kernel ${tftp-path}/wimboot gui
imgfetch --name BCD ${pe-path}/BCD BCD
imgfetch --name boot.sdi ${pe-path}/boot.sdi boot.sdi
imgfetch --name bootmgr ${pe-path}/bootmgr bootmgr
imgfetch --name boot.wim ${pe-path}/boot.wim boot.wim
boot || goto MENU -
RE: Quick Registration Hostname Variability?
@george1421 There wasn’t any doubt on my end…but I can imagine you read that and said to yourself “of course it did…”.
-
RE: Install FOG on Ubuntu Server 21.10 issues
@sebastian-roth Sounds good. My NEW secondary FOG server is up and running on 20.04.
-
RE: USB Boot method: Make FOG serve ipxe files via http instead of tftp
@george1421 I just tested it out on a PC outside of our IT vlan with success. I hard coded it already, but I have a habit of not disclosing our IP addresses even if they’re private. I get the Press ESC to show the menu option for one second, then it boots to the hard drive. Now I took the modified bootx64.efi from my usb drive and copied it to the Windows EFI partition, replacing the existing one (renamed the old to bootx64.efi.bak), made sure that the UEFI is pointing to the file, and now the PC boots the fog process without USB.
-
RE: Cannot boot through PXE Menu timeout
@mcana66 What I did was create a file in /tftproot called autoexec.ipxe and put this in:
#!ipxe ifopen net0 dhcp net0 chain ${boot-url}/scripts/menu_EFI.ipxe
This is for my FreeNAS box that I use for other projects and testing. You can chain any ipxe script (or any boot script like boot.php on the fog server) you want from there. The ${boot-url} variable is set in the default.ipxe file also located in /tftproot.
-
RE: UEFI PXE Boot - Pain
@rogerbrowntdl dnsmasq runs on the FOG server to detect architecture and boot type then serve the boot files over tftp. This is my understanding of how it all works:
PC sends DHCP server a request for an IP address with a pxe packet.
DHCP assigns an IP address then directs (relays) the PC to the FOG server.
FOG Server handles this request by sending either undionly.kpxe or ipxe.efi depending on the architecture of the PC (dnsmasq tftp service).
PC downloads and executes the correct file.
After that FOG loads the boot menus.
Latest posts made by DBCountMan
-
RE: FOG speed problem
@george1421 said in FOG speed problem:
The FOG server only moves disk blocks from its local storage and sends them out the network adapter. The fog server does monitor the imaging process but does not perform heavy computational load
What about in the case of using storage nodes? Does the Fog server tell the target where the data blocks are then the target only talks to the storage node?
-
RE: kernel panic - not syncing: VFS: Unable to mount root fs when booting EFI
@Sebastian-Roth Sorry I didnt see your first question. This is what I downloaded:
https://github.com/FOGProject/fos/releases/download/20230331/init.xzI put my backup file back into the original place, /var/www/fog/service/ipxe, file perms identical, init.xz doesn’t load after download. So far on physical PCs and VirtualBox vms I saw the kernel panic error, but on my Hyper-v VM after init.xz downloads to 100% I see that EFI Stub message then black screen. Nothing happens after that.
EDIT: Here’s a screenshot from a physical PC
-
kernel panic - not syncing: VFS: Unable to mount root fs when booting EFI
I’m receiving this error as soon as init.xz loads after selecting any item on the FOG boot menu booting a device via UEFI. Legacy boot loads just fine. I downloaded init.xz from github and set permissions accordingly but the issue persists.
-
RE: ipxe chain boot.php permission denied on pxe but not autoboot
@george1421 That would be the next step. When I said “replicate” I meant that I have a cron sync from primary to secondary every night, not instantly. So lets say I set up both servers to accept ipxe req’s and a field tech loads a new image on the primary at 10am and wants to deploy them to 20 PCs in the field. Primary FOG server takes a dump. The secondary FOG server won’t have the image until midnight. So there’s one issue. Unless I set cron to sync every hour or 30min. Another issue I found with rsync as much as I love it, is that if the primary server goes offline, the secondary, which has the /images nfs share from FOG1 mounted, will appear empty, and rsync will sync an empty dir to its own /images, thus wiping out that folder. I read that rsync can be tuned to not sync if a directory is empty but I have to research and test.
-
RE: ipxe chain boot.php permission denied on pxe but not autoboot
@Sebastian-Roth @george1421
Guess what? The key ID of 5e…c9 belongs to my secondary FOG server. Somehow it was getting mixed into the pxe request chain. My DHCP server is configured to send pxe requests to my primary FOG server only. I have no reference to my secondary server anywhere in the tftp configuration. Very strange. I use dnsmasq because for some reason tftpd didn’t play nice with our DHCP server. I had dnsmasq running on the secondary server and thus is somehow received pxe requests.Disabled the service on the secondary FOG server and now pxe works flawlessly.
The only reason I left dnsmasq running on the secondary is for redundancy. I replicate my primary to my secondary. Since any time I use the USB boot method outside the subnet of any FOG server, the ipxe boot process will ask for an IP. What I thought I could have is the option to boot from the secondary in case the primary was out of service. I also incorrectly thought that dnsmasq is required but since the USB boot method takes care of ipxe, its just an HTTPS connection from there.
So again I thank you guys for helping me figure this out.
-
RE: ipxe chain boot.php permission denied on pxe but not autoboot
Found something interesting. When I first boot the vm and get the initial error, then drop to prompt, I run certstat. The first certstat shows this:
The addressing in .59 is the fog server. Now look at certstat after a successful chain of boot.php:
So I don’t know where that “5e…c9” CA key is from or why it appears initially. Could explain the initial permission denied because the key doesn’t match? BTW the “81…0c” is the SHA key of the cert that is actually being used, I matched it with the cert issued to my browser.
-
RE: ipxe chain boot.php permission denied on pxe but not autoboot
@george1421 I probably shouldn’t have re-run the installer but I wanted to see if that would fix it.
ls /tftpboot -lah total 6.5M drwxr-xr-x 5 fogproject root 4.0K Aug 23 09:13 . drwxr-xr-x 29 root root 4.0K Aug 23 08:24 .. drwxr-xr-x 4 fogproject root 4.0K Mar 16 2021 10secdelay drwxr-xr-x 2 fogproject root 4.0K Mar 16 2021 arm64-efi -rw-r-xr-x 1 fogproject root 39 Aug 23 09:13 autoexec.ipxe -rw-r-xr-x 1 fogproject root 868 Apr 27 2022 boot.txt -rw-r-xr-x 1 fogproject root 459 Aug 23 08:36 default.ipxe -rw-r-xr-x 1 fogproject root 454 Mar 16 2021 default.ipxe.bak -rw-r-xr-x 1 fogproject root 458 Jun 10 2021 default_usb.ipxe drwxr-xr-x 2 fogproject root 4.0K Mar 16 2021 i386-efi -rw-r-xr-x 1 fogproject root 270K Aug 23 08:36 intel.efi -rw-r-xr-x 1 fogproject root 103K Aug 23 08:36 intel.kkpxe -rw-r-xr-x 1 fogproject root 103K Aug 23 08:36 intel.kpxe -rw-r-xr-x 1 fogproject root 103K Aug 23 08:36 intel.pxe -rw-r-xr-x 1 fogproject root 1.1M Aug 23 08:36 ipxe.efi -rw-r-xr-x 1 fogproject root 888K Aug 23 08:36 ipxe.iso -rw-r-xr-x 1 fogproject root 363K Aug 23 08:36 ipxe.kkpxe -rw-r-xr-x 1 fogproject root 363K Aug 23 08:36 ipxe.kpxe -rw-r-xr-x 1 fogproject root 362K Aug 23 08:36 ipxe.krn -rw-r-xr-x 1 fogproject root 362K Aug 23 08:36 ipxe.lkrn -rw-r-xr-x 1 fogproject root 363K Aug 23 08:36 ipxe.pxe -rw-r-xr-x 1 fogproject root 400K Aug 23 08:36 ipxe.usb -rw-r-xr-x 1 fogproject root 26K Aug 23 08:36 memdisk -rw-r-xr-x 1 fogproject root 301K Aug 23 08:36 ncm--ecm--axge.efi -rw-r-xr-x 1 fogproject root 268K Aug 23 08:36 realtek.efi -rw-r-xr-x 1 fogproject root 104K Aug 23 08:36 realtek.kkpxe -rw-r-xr-x 1 fogproject root 104K Aug 23 08:36 realtek.kpxe -rw-r-xr-x 1 fogproject root 104K Aug 23 08:36 realtek.pxe -rw-r-xr-x 1 fogproject root 268K Aug 23 08:36 snp.efi -rw-r-xr-x 1 fogproject root 268K Aug 23 08:36 snponly.efi -rw-r-xr-x 1 fogproject root 102K Aug 23 08:36 undionly.kkpxe -rw-r-xr-x 1 fogproject root 102K Aug 23 08:36 undionly.kpxe -rw-r-xr-x 1 fogproject root 102K Aug 23 08:36 undionly.pxe -rw-r-xr-x 1 fogproject root 51K Mar 17 2021 wimboot
-
RE: ipxe chain boot.php permission denied on pxe but not autoboot
@george1421 Since I re-ran the fog installer using the -S switch, it rebuilt ipxe and the corresponding certs were regenerated. The file dates themselves are marked with today’s date when they were recreated.
openssl x509 -in /var/www/fog//management/other/ssl/srvpublic.crt -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: *redacted* Signature Algorithm: sha256WithRSAEncryption Issuer: CN = FOG Server CA Validity Not Before: Aug 23 12:18:57 2023 GMT Not After : Aug 20 12:18:57 2033 GMT Subject: CN = <fogserverip>
openssl x509 -in /var/www/fog//management/other/ca.cert.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: *redacted* Signature Algorithm: sha512WithRSAEncryption Issuer: CN = FOG Server CA Validity Not Before: Apr 27 20:15:47 2022 GMT Not After : Apr 24 20:15:47 2032 GMT Subject: CN = FOG Server CA
-
RE: ipxe chain boot.php permission denied on pxe but not autoboot
@george1421 As far as the part of the environment I have control over, no. Not sure if there was a network change. However that being said nothing changed with apache. I ran the installer again using the -S option and it completed but the issue persists. Just seems odd that it won’t chain during the first attempt but works after running the autoboot command. Can I PM you a webm video recording of the vm I’m testing with? It is about 400KB.
EDIT: I added the fog server ip to the apache2.conf file at the bottom of the file as “ServerName <fogip>” and got rid of that AH00558 error message, but it didn’t fix the issue. Also autoboot doesn’t always work the first try, eventually it does though.
apache2ctl -S AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using <fogserverhostname>. Set the 'ServerName' directive globally to suppress this message VirtualHost configuration: *:80 <fogserverip> (/etc/apache2/sites-enabled/001-fog.conf:1) *:443 <fogserverip> (/etc/apache2/sites-enabled/001-fog.conf:16) ServerRoot: "/etc/apache2" Main DocumentRoot: "/var/www/html" Main ErrorLog: "/var/log/apache2/error.log" Mutex watchdog-callback: using_defaults Mutex rewrite-map: using_defaults Mutex ssl-stapling-refresh: using_defaults Mutex ssl-stapling: using_defaults Mutex proxy: using_defaults Mutex ssl-cache: using_defaults Mutex default: dir="/var/run/apache2/" mechanism=default Mutex mpm-accept: using_defaults PidFile: "/var/run/apache2/apache2.pid" Define: DUMP_VHOSTS Define: DUMP_RUN_CFG User: name="www-data" id=33 Group: name="www-data" id=33
/etc/apache2/sites-enabled/001-fog.conf
<VirtualHost *:80> <FilesMatch "\.php$"> SetHandler "proxy:fcgi://127.0.0.1:9000/" </FilesMatch> KeepAlive Off ServerName <fogserverip> ServerAlias <fogserverhostname> DocumentRoot /var/www/ RewriteEngine On RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] RewriteRule /management/other/ca.cert.der$ - [L] RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L] </VirtualHost> <VirtualHost *:443> KeepAlive Off <FilesMatch "\.php$"> SetHandler "proxy:fcgi://127.0.0.1:9000/" </FilesMatch> ServerName <fogserverip> ServerAlias <fogserverhostname> DocumentRoot /var/www/ SSLEngine On SSLProtocol all -SSLv3 -SSLv2 SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GC> SSLHonorCipherOrder On SSLCertificateFile /var/www/fog//management/other/ssl/srvpublic.crt SSLCertificateKeyFile /opt/fog/snapins/ssl//.srvprivate.key SSLCACertificateFile /var/www/fog//management/other/ca.cert.pem <Directory /var/www/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>
-
RE: ipxe chain boot.php permission denied on pxe but not autoboot
@george1421 I did run the fog installer using https and it had been working up until yesterday. If ipxe doesn’t have the correct cert then why would the ipxe still loaded properly after running the autoboot command at the ipxe shell? Should I re-run the installer anyway?
I used wireshark and this is the result right after the ipxe.efi file is downloaded. .138 is the client device, .59 is the fog server.