Posts made by Scott B

@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.

I’m working on getting a batch of some order PCs reloaded and I can’t seem to get them to image via network boot with FOG. They hang at “iPXE initializing devices”. I can get them to image if I use the ipxe iso directly from ipxe’s website on a USB drive. Is there a way to update/change FOG to use what I’m guessing is an updated or just a different version of ipxe?

The server is running Ubuntu 18.x with FOG 1.5.9. Also with that, I downloaded the newest kernels from within the FOG web GUI. bzImage 5.10.19 and bzImage32 5.10.19. PCs in question use an Asus P8H61-M motherboard.

@mmoore5553 said in drive not expanding fog 1.5.9:

@scott-b yes it is . Windows 20h2 . I finally got it resolved by the moderator. I had to go into my image and delete the recovery drive. Then it acted correctly.

Just wanted to put that out there if someone else had the same issue

Thank you for letting me know. I’m having the same issue so I’ll give that a shot.

@mmoore5553 said in drive not expanding fog 1.5.9:

It just shows the other space as unallocated
i did have to update to newest kernal for me to image the co

Any chance this is a Sysprep image with the most current version of Windows?

@fry_p

This is good information. It’s how I automate the FOG client install after my sysprep images have been restored.

@Daniel-Miller @Sebastian-Roth

Thanks for the explanation. I always wondered since I have always done the MSI.

Other than the file type what is the difference between the fog client MSI installer and the smart installer?

@Sebastian-Roth

I’ll have to brush up on the commands for replacing the certs on the clients. Been a long time.

@Sebastian-Roth

We were not able to bring his setup back online and reconnect the client. I ended up building a new fresh FOG install and we will reimport the machines as we go around. It’s not to big a deal as we needed an excuse to clean up the database anyway.

@Sebastian-Roth said in Migrated FOG, Clients Not Happy:

@Scott-B Did you find what was causing this?

No, I have not. My backup, clients, and current running server all have different thumbprints. I have no idea how that’s happened. Is it possible to take the cert from a client and add it to the server?

@Sebastian-Roth said in Migrated FOG, Clients Not Happy:

@Scott-B Can you get the thumbprints on the old server?

The tumbprint from srvpublic.crt in /var/fog/management/other/ssl on the older server is
88901133f4640b294ec5f4538e3f098eccadca45