@george1421 I think I follow, I’ll give it a bash and let you know, thank you :).

@jmvela2x Thanks very much for sticking with us on this and doing the tests!

Thank you for this information. I will have to come back to this at a later date though. I really do want to continue with this but our school district is in the middle of preparing machines and we’re relying on FOG heavily right now. I am not a Linux user so everything is new to me right now, so if we lose FOG, it will set us back a bit. Once projects are done I will come back to this. Thanks again.

@lebrun78 said in https, with home certificates and boot.php… No such file or directory (http://ipxe.org/2d0c613b):

./installfog.sh -C -K

I really hope you don’t use the fog-client software as re-generating the internal CA will break all communication to the fog-clients.

I modified /etc/httpd/conf.d/fog.conf with…

This will be overwritten as soon as you re-run the FOG installer. I know this part of FOG needs some more attention but I can’t find the time to get into all of this. So I lost track of the SSL stuff a few weeks ago. Will need to work on the wiki article about this again: https://wiki.fogproject.org/wiki/index.php?title=HTTPS (this is not ready-set-go yet)

I tried to generate a new ipxe configuration
cd /opt/fogproject-1.5.9-RC2/utils/FOGiPXE/
./buildipxe.sh

You will need to specify your CA cert on the command line when building and manually copy the binaries over after that, e.g.:

cd /opt/fogproject-1.5.9-RC2/utils/FOGiPXE/ ./buildipxe.sh /etc/httpd/cert/DigiCertCA.crt cd ../../packages/tftp/ find -type f -exec cp -Rfv {} /tftpboot/{} \;

@mhx Ok then lets extend a bit on what Sebastian suggested. Right now the main issue is PXE booting into FOG, and your firmware’s absence of a uefi network stack. So what we are going to attempt is to supplement your firmware by booting the iPXE boot loader directly from a uefi bootable memory stick using this process: https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

typically the PXE rom in your network adapter reaches out via bootp and downloads the iPXE boot loader from the network, in this case we are going to load it directly from the USB flash drive. That flash drive can be tiny in todays standards. The iPXE boot loader can easily fit on a 512MB flash device. There is no need for anything bigger since it will be just a waste of empty space.

Finally added the simple route of HTTP redirect via index.php (99a407e and ad2813ab).

Perfect @george1421! I’ll give it a whirl, thank you.

@foggystarz You might want to look through this thread for ideas for pxe booting recovery media with FOG: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/3?_=1590418175520

@Derek-Newbold As a very first step I may ask you to post a picture of the error that you see on screen when an image does not properly deploy “due to image size being set to 0”.

While I can’t be absolutely sure (there have been many changes and fixes since FOG 1.5.4) I am not aware of the image size playing any role when deploying an image to a host! It’s true that in FOG 1.5.4 the image size on client field is being updated and set to 0 if it fails deploying and that is something strange we fixed lately. It will only ever do this on captures now.

Nevertheless I don’t think the image size should influence the deployment process in any way. Please provide error messages.

@ITHand Have you read through this topic start to end? May I ask you to do the database queries mentioned below and see if you can find out if one of the MAC addresses is already in the DB and which one it is. Take a very close look at all the network interfaces you have in your network manager on Windows - also tunnel interfaces and such.

@wafflest1ck said in Install Issue:

the issue is that our network is pretty tight

What exactly do you mean by this?

@DennisRentAll Let’s take one step back here. Is this a fresh clean install of FOG showing this issue or has this worked before and the problem turned up just now?

What Linux OS is this running on? Firewall disabled? SELinux disabled?

@sbenson But the other location was fast at one time. Or the root of the issue is the location IS the difference that causes speed issues??

@zyzhang Yes you can delete an image through the web UI and it will delete it on disk as well. But you have to make sure you use the delete button in the image settings view - not the multi delete from the list view!

@zyzhang Yes you can delete an image through the web UI and it will delete it on disk as well. But you have to make sure you use the delete button in the image settings view - not the multi delete from the list view!

Hey rhromyko! Thank you for that information! I was having the same problem.

@fritoss007 said in LDAP authentication with userPrincipalName fill with email address:

Should I report it somewhere else

In this tread is good enough. Both Tom and Sebastian are in this thread so its the right place at the right time.

@george1421 so far it’s only 2 out of the 12 I’ve done. If I hit boot from hard disk it will go to the drive, but otherwise nothing happens. Tried it multiple times.

Yes, the Dell Latitude 3189 are laptops that do not have internet ports and we had to use USB adapters. At that time, the version of FOG didn’t like same MACs for multiple machines. So the way I got around that was deleting the hosts since it was tied to a MAC from a USB and I was more concerned with just getting them imaged. I guess I deleted them prematurely. Unless I just overlooked something completely and did something wrong.

As for the deploy task ones, I’m not sure why they were stuck in there. They may have been ones that seemed to be giving me imaging problems and I turned off the machine before canceling it in the task menu.

@jhumpf Any news on this? What sort of task is this? Capture, deploy, multicast, other?