@tprice said:

2. What is the best combination for installing FOG i.e. is Ubuntu better than Centos?

Just my personal preference, but I’ve always been happy with FOG on Ubuntu and formerly Fedora.

@Pascal-Gazaille said:

Hi,
I’m on Ubuntu 14.04.2 LTS with Fog 1.2.0. I’m trying to update to latest svn but during the fog installation I get :

• Addubg needed repository…Failed!

and everything stops

What can I do?

I had this issue and finally found my filter was blocking launchpad.net. After allow access to that page it updated like a charm.

Do you mean to make it so the image file(s) can’t be overwritten? There is a checkbox under the properties of the image in FOG for “protected” that makes it so this isn’t possible if so.

@THEMCV

I’d buy one.

@Wayne-Workman said:

@Scott-B Just get rid of those…

Backup your DB first. FOG Configuration -> Configuration Save -> Export

For an individual:

update inventory set iOtherTag='' where iID=1972;

For everything:

update inventory set iOtherTag='' where iOtherTag like '%\\\\\\\\\\\\\\%';

Thank you, that cleaned up the list very well.

What do the logs on the server suggest the issue could be?

Please provide some details of the server. Ubuntu? Fedora? Versions? Do the log files on the server point to anything?

@Tom-Elliott said:

@Scott-B Is it possible that the links are causing weird things?

Can you delete all webroot paths for fog?

rm -rf /var/www/fog
rm -rf /var/www/html/fog

Then rerun the fog installer?

Thanks Tom, that did the trick.

@Sebastian-Roth said:

Marking this solved for now as we didn’t hear back from anyone. If you have printer issues please follow the link Wayne posted below. If you still think there is an issue within FOG please let us know!

I apologize for the delay, been swamped. It does seem the issue has been resolved. I have not seen it after the past several SVNs. Thank you very much for your help.

With a lot of help from @Sebastian-Roth we did track down the issue. Someone must have been in our DHCP server and changed the case of the undionly.kpxe to all caps… thus not finding the file. Sometimes is those simple things you just don’t think to look for. Thanks again for your help Sebastian!

@Wayne-Workman said in Target partition is smaller than source:

@Scott-B Can you try a resizable image? If for no other purpose than to see the result?
@Scott-B Remember after changing that on the image you need to re-upload. Or just create a new image.

I made new images and made them realizable. They all seem to be working just fine that way so I’ll go with it.

@george1421 said in iPXE iso vs iPXE FOG:

Something isn’t working as we know it should.

I’m going to try and find a second PC with the same motherboard to test with but currently, they are all in service.

@george1421 said in iPXE iso vs iPXE FOG:

@scott-b So when you rerun the FOG installer and does the files in /tftpboot match the date of this list? If so you should be booting the latest version of iPXE

All the files that are in /root/fogproject/packages/tftp/ are the same in /tftpboot for date and time.

@george1421 said in iPXE iso vs iPXE FOG:

Will you look into the git repo you downloaded to install FOG in …/fogproject/packages/tftp and see if all of the file dates are current (as of when you ran the buildipxe.sh scripts)? You can view the file dates with ls -la in that tftp directory.

I ran through the build process again and here is the output. Most all the dates are from today.

drwxr-xr-x 5 root root    4096 Dec 11 18:20 .
drwxr-xr-x 8 root root    4096 Jun  1  2020 ..
drwxr-xr-x 4 root root    4096 Dec 11 18:20 10secdelay
drwxr-xr-x 2 root root    4096 Dec 11 18:20 arm64-efi
-rwxr-xr-x 1 root root     868 Jun  1  2020 boot.txt
drwxr-xr-x 2 root root    4096 Dec 11 18:20 i386-efi
-rw-r--r-- 1 root root  248896 Apr 28 13:43 intel.efi
-rw-r--r-- 1 root root   99833 Apr 28 13:42 intel.kkpxe
-rw-r--r-- 1 root root   99881 Apr 28 13:42 intel.kpxe
-rw-r--r-- 1 root root   99849 Apr 28 13:42 intel.pxe
-rw-r--r-- 1 root root 1047040 Apr 28 13:43 ipxe.efi
-rw-r--r-- 1 root root  892928 Apr 28 13:42 ipxe.iso
-rw-r--r-- 1 root root  359292 Apr 28 13:42 ipxe.kkpxe
-rw-r--r-- 1 root root  359340 Apr 28 13:42 ipxe.kpxe
-rw-r--r-- 1 root root  358889 Apr 28 13:42 ipxe.krn
-rw-r--r-- 1 root root  358889 Apr 28 13:42 ipxe.lkrn
-rw-r--r-- 1 root root  359438 Apr 28 13:42 ipxe.pxe
-rw-r--r-- 1 root root  376832 Apr 28 13:42 ipxe.usb
-rw-r--r-- 1 root root   26140 Jun  1  2020 memdisk
-rw-r--r-- 1 root root  278976 Apr 28 13:43 ncm--ecm--axge.efi
-rw-r--r-- 1 root root  247808 Apr 28 13:43 realtek.efi
-rw-r--r-- 1 root root  100572 Apr 28 13:42 realtek.kkpxe
-rw-r--r-- 1 root root  100620 Apr 28 13:42 realtek.kpxe
-rw-r--r-- 1 root root  100616 Apr 28 13:42 realtek.pxe
-rw-r--r-- 1 root root  247232 Apr 28 13:43 snp.efi
-rw-r--r-- 1 root root  247456 Apr 28 13:43 snponly.efi
-rw-r--r-- 1 root root   99305 Apr 28 13:42 undionly.kkpxe
-rw-r--r-- 1 root root   99353 Apr 28 13:42 undionly.kpxe
-rw-r--r-- 1 root root   99330 Apr 28 13:42 undionly.pxe

@george1421 said in iPXE iso vs iPXE FOG:

This part has me a bit confused. How is this hand-off taking place.

Here is a short video of booting from the ipxe iso. It will boot with (g85d17) then about the 7-second mark (g3efd) is loaded before successfully dropping me off at my fog menu.

https://youtu.be/wrkTdMxKQK4

@george1421 said in iPXE iso vs iPXE FOG:

Just for clarity you did not compile the iso, but just used rufus or such to burn the iso to the usb?
Last question, you have only been able to boot ipxe completely with what version of iPXE (numbers in the square brackets)?

Correct. I meant I used Rufus to burn the iso from ipxe’s website.

I was able to boot usb with (g85d17). But then that hands off to FOG which is using (g3efd)?

@sebastian-roth said in iPXE iso vs iPXE FOG:

Have you tried using a different iPXE binary like snponly.efi yet?

I have tried snponly.efi and realtek.efi with the same results.

I just remade a new iPXE USB from the iso file and it reports iPXE 1.21.1+ (g85d17) but then comes up again with the (g3efd). This is different than the fog server. So now I’m confused.

Screenshot from the PC with the issue, booting from iPXE iso on USB from iPXE site.

@george1421

Sorry I didn’t explain that well. The first picture is not from the PC in question that started this thread. It’s from a PC that works fine with FOG. The PC in question will not get far enough to show that iPXE information from the network booting to FOG. It hangs with the "iPXE initializing devices” but no further information. I just wanted to post the screenshot to show the iso and fog are the same numbers.

@george1421 said in iPXE iso vs iPXE FOG:

@scott-b on the version you have on the cdrom that works, I’m suspecting its pretty old. When ipxe first starts it displays a banner message. At the very start of the banner page there will be a version number AND a hex code in square brackets. What are both codes. I haven’t had to do this before but we should be able to look up the commit code to find out how old the ipxe kernel is. Also look at the date created of the ipxe.efi file.

Here is a screenshot from booting FOG after updating iPXE.

Here is the screen when I boot from the iPXE USB.

Hard to see in the second picture, but they are the same.

@sebastian-roth

Thanks for the tip. I didn’t know that was possible. I did perform those steps but I’m still seeing the issue.