@zedx First I suggest you check if there is an update of the firmware for those devices available. Installing a firmware update can help.

You can also try different iPXE binaries for UEFI to see if it make any difference. Instead of the default ipxe.efi try snponly.efi and snp.efi.

If that doesn’t help you can try compiling iPXE from the very latest source code in hope of those fixing the issue. See my post here on how to do that: https://forums.fogproject.org/post/143521

@artac From which version of FOG did you update? As well, which version of Ubuntu did you update from?

Please run dpkg -l | grep -e php -e apache and post the full output of the command here.

@wkratky Please run the following commands and post all output here:

ls -al /var/www grep docroot /opt/fog/.fogsettings find /etc -type f -exec grep DocumentRoot {} /dev/null \;

@george1421 said in Dell Optiplex 3080 - UEFI - PXE Boot E-21: Remote boot cancelled.:

Side note: If your network doesn’t have a dhcp server I would personally use isc-dhcp server on your fog server over dnsmasq. I would use dnsmasq if you have a dhcp server run by someone else and can’t update settings. In this case dnsmasq would supplement your unchangeable dhcp server.

THANK YOU!

I set up isc-dhcp and it’s working like a charm.

For any future people reading:
I modified /etc/dhcp/dhcp.conf with the below config.
I disabled dnsmasq. systemctl stop dnsmasq.service
I started isc-dhcp service dhcpd start
I tsuccessfully PXE booted with my Dell 3080 a few times.
I permanently disabled dnsmasq. systemctl disable dnsmasq
I set isc-dhcp to start automatically. systemctl enable dhcpd

option space PXE; option PXE.mtftp-ip code 1 = ip-address; option PXE.mtftp-cport code 2 = unsigned integer 16; option PXE.mtftp-sport code 3 = unsigned integer 16; option PXE.mtftp-tmout code 4 = unsigned integer 8; option PXE.mtftp-delay code 5 = unsigned integer 8; option arch code 93 = unsigned integer 16; # RFC4578 use-host-decl-names on; ddns-update-style interim; ignore client-updates; next-server 192.x.x.7; authoritative; subnet 192.x.x.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; range dynamic-bootp 192.x.x.200 192.x.x.254; default-lease-time 21600; max-lease-time 43200; option domain-name-servers 192.x.x.7; option routers 192.x.x.7; class "UEFI-32-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006"; filename "i386-efi/ipxe.efi"; } class "UEFI-32-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002"; filename "i386-efi/ipxe.efi"; } class "UEFI-64-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007"; filename "ipxe.efi"; } class "UEFI-64-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008"; filename "ipxe.efi"; } class "UEFI-64-3" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009"; filename "ipxe.efi"; } class "Legacy" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000"; filename "undionly.kkpxe"; } }

@julio I think we have two questions with your post.

Can I configure to boot into fog without changing the bios options each time? If you have dell computers, you can use the dell program “command and control” also known as CCTK to change bios settings. One that may help you is pxe boot at the next reboot. You would send this command as a FOG snapin to run the cctk program to tell bios on the next reboot, pxe boot. This way you can get to FOG.

I want to deploy an image without registering the computer in FOG. Can I do this? Yes. This is how I deploy my images today. I have a technician sit in front of computer and power it on, press F12 to get to the bios boot menu and then pick pxe boot. In the FOG iPXE menu I pick Deploy Image and select the image to send to the computer. I don’t use FOG to rename the computer or connect to AD so once the image has been pushed to the target computer, the windows installer does everything to connect and setup the machine. This process I call is “load and go”. System builders use this method because they build the computer once and sell it, there is no need to register in fog unless you need to manage the computer after imaging.

@kyl said in Multiple PXE Servers:

Currently I am using chain to point menu items to the pxe boot files residing on another server. I know that this isn’t what FOG is made for, but it’s working for me and that’s all I can ask for.

That is the beauty of FOG and open source software. FOG is flexible enough to support doing things that it was never designed to do. Case in point the articles related to pxe booting your fav OS installer. That’s not related to FOG, but can be done with a little skill.

@george1421 said in Deploying Image without Data Loss:

I think maybe the easiest solution is to capture your source computer with single disk resizable (yes that will capture that 5th partition too), then we can go into the raw data files and remove any reference to that 5th partition. So you will initially capture it but then remove it from the FOG server so all deployments will only have 4 partitions.

While it sounds interesting I am not sure this will work in this scenario. Though it’s worth a try. The partition layout cannot be stripped as FOS will always wipe and deploy the partition layout as a whole. The only chance I see is remove d1p5.img file and try a deployment.

@abuadal
Be aware that this is not how FOG is intended to be used and there might be drawbacks from this and loss of data is possible if something goes wrong. So make sure you don’t try this with systems where important data could be lost!!

@mmethe Not sure what’s wrong but you might try setting the ownership: chown fog:root /images/dev/postinitscripts/fog.postinit (note: the user fog exists in older versions only. After the update to 1.5.9 it will be called fogproject)

@sebastian-roth I’ll help whereever I can.

I’m a jack-of-all-trades SysAdmin, can write tutorials/documentation, and do some simple bash scripting.

@sebastian-roth Thanks for this reply.
I will try un inventory task to check bi-directional data exchange.
Luc.

@george1421 My apologies for the repeated posting. Just wanted to follow up to say that the FOG Client DID join my test machine to the domain as desired this morning. Not sure what the difference was (other than that the laptop had not previously had a power cord plugged in), but it looks like everything is behaving as I had hoped it would. Thank you again for your time and effort to help me out.

@mechalas yes, now it works perfectly. Cool

@novaholic Hi,
I am facing with the same problem.
Have you managed to fix it?

Thanks

@sebastian-roth said in Snapins Issue : Hash does not match:

@DARUN974 Are you in contact with the developers of EOLE?

Hello,
I am not “really” in contact with the EOLE developers.
We use a forum to ask our questions: scribe@listeseole.ac-dijon.fr
I will see if other users have encountered this problem.

@quinniedid I updated this article with the testing from today: https://forums.fogproject.org/topic/14791/feature-request-for-fog-1-6-x-configure-image-capture-to-use-nfsv4-instead-of-nfsv3

Changes needed on FOG server to support NFSv4

Build the nfsv4 virtual fs mount points mkdir -p /opt/fog/data/capture mkdir -p /opt/fog/data/images (optional) Provide the same ./postinitscript files for both capture and deploy. mkdir -p /images/dev/postinitscripts mkdir -p /images/postinitscripts Edit the /etc/fstab to bind mount the virtual NFSv4 file system to the physical fog directories /images/dev /opt/fog/data/capture none bind 0 0 /images /opt/fog/data/images none bind 0 0

If you included optional step #2 append this to the end of the /etc/fstab

/images/postinitscripts /images/dev/postinitscripts none bind 0 0 Connect the virtual fs to the physical fs mount -a

Now you should be able to run these commands to see if the mount works. Looking at /opt/fog/data/capture should give the same list as /images/dev and looking at /opt/fog/data/images should give the same list as /images. If that is valid then move on to the next step.

Now we need to get the gid and uid of the fog service account fogproject.
5.1 Run the following command to get fogproject’s uid: grep fogproject /etc/passwd | cut -d ":" -f3 note this value. It will most likely be 1000 or 1001 but could be anything, it depends on the host OS.
5.2 Run the following command to get fogproject's gid: grep fogproject /etc/passwd | cut -d ":" -f4 note this value. It will most likely be 1000 or 1001. You will need the uid and gid values in the next step.

Edit the /etc/exports file. In this case we are converting FOG to only operate in NFSv4 mode. So we will remove all of the FOG NFSv3 export lines and replace them with the NFSv4 export lines. Insert the following into the /etc/exports file.

/opt/fog/data/ *(fsid=0,no_subtree_check,insecure) /opt/fog/data/images *(ro,sync,nohide,no_subtree_check,all_squash,insecure,anonuid=1001,anongid=1001) /opt/fog/data/capture *(rw,sync,nohide,no_subtree_check,all_squash,insecure,insecure_locks,no_wdelay,anonuid=1001,anongid=1001)

Be sure to update the anonuid= and anongid= values above to match the values of the uid and gid you collected in the previous step.

The last step is FOG server linux OS dependant. We will need to enable NFSv4 and disable all other NFSvX support. For Debian variants you need to do this:
7.1 Edit /etc/default/nfs-common and make these adujustments NEED_STATD="no" NEED_IDMAPD="yes"

7.2 Edit /etc/default/nfs-kernel-server Note that RPCNFSDOPTS is typically not included by default. Please add that option if it is not present.

RPCNFSDOPTS="-N 2 -N 3" RPCMOUNTDOPTS="--manage-gids -N 2 -N 3"

7.3 For RHEL compatible linux OS, edit /etc/nfs.conf and make thest changes:

[nfsd] tcp=y vers2=n vers3=n vers4=y vers4.0=y vers4.1=y vers4.2=y

ref: https://wiki.debian.org/NFSServerSetup

Reboot the FOG server. This will check your edits as well as restart the NFS server in v4 mode.

@sebastian-roth as you suspected, this ISO image did boot both legacy and EFI. Which has been a boon.

I have used this ISO four times this week, and it has been a huge time-saver.

@sebastian-roth
I figured such. The usb method on my offline imaging switch is redundant since pxe works fine on that. Just would have been nice to be able to image remotely booting via USB, kind of like Acronis+mapping to an SMB share that stores the images. If only my network team would enable tftp/pxe on their dhcp servers. We have it only on our hq subnet but it is being used by SCCM, and SCCM takes a very, very long time to image a PC. We only use it to get a base Windows 10 image and work on it from there, then capture/upload our custom dept images to the FOG server.