Posts made by hancocza

@george1421 I’m working on getting an updated FOG server running using NFSv4 as well. I’ve just installed 1.5.10.10 on Ubuntu 22.04 LTS and have gone through the steps on configuring the OS and FOG for NFSv4. I’m a bit stumped on the FOS changes, so I tried using this kernel for the server. When trying to boot a client to the FOG server with a bootable USB, the client kernel panics. I’m assuming it’s because the kernel here is for a previous version of FOG. Any ideas?

@sebastian-roth I was able to test on both an M83 and a 7010. I’ll be doing more widespread testing once we get back after the holidays, but everything seems to be fine!

@sebastian-roth Back tracking on this a bit…

I was able to get it to work by following George’s instructions at the start of this thread, with making a USB the easy way (using the latest iPXE version directly on the USB drive). My other test this morning was using an older version of iPXE on the USB drive that then boots to the iPXE version on the server. That does mean though that their latest version fixed the issue, since I tried the easy method USB drive at the start of this thread with the same error. My thought is that it exits fine on the server, but then when it tries to exit the older iPXE version on the flash drive that it encounters the error.

@sebastian-roth

1. Yep, use the iPXE on USB to boot to the iPXE on the fogserver, then use that to chainload.

2. I think it’s the latest: g47098 matches the 47098 start of the commit id

@sebastian-roth Just reran the test with the latest ipxe version. Still has the same issue on a 7010.

@sebastian-roth As long as I can remember, I haven’t had an issue with iPXE on an EFI usb drive on an Optiplex 7010. I have had the issue where it gets stuck on “Initializing iPXE…” on 790s when using the EFI usb drive. I can’t speak to the built in iPXE booting on those machines since our network structure doesn’t allow for direct pxe booting.

@sebastian-roth Finished this. Ended up with “c70b3e04e86cefca335e36f883829d89583a6921 is the first bad commit”.

@sebastian-roth Can do. Feel free to post the instructions and I’ll get working.

@sebastian-roth Yeah I can do that. Give me till next week, gotta get a few imaged while it’s up and running.

@sebastian-roth That seems to have worked. Was able to boot to to a task on an Optiplex 7010. Will test on a few others tomorrow to be sure.

@sebastian-roth I was able to test out the kernel this morning. I swapped in the ones from the 1.5.9.BACKUP folder as well as the 1.5.8.BACKUP folder, both of them had the same error. Thinking this might then be an iPXE error?

@sebastian-roth May be an issue with the tftpboot.prev folder… When I first updated to 1.5.9, I thought that the issues I was seeing were from some file not installing correctly… so I ran the installer again after I ran into the issue. So I might not have the actual previous tftpboot folder.

Heres the output from ls -al /home | grep fog_web:

drwxr-xr-x 10 root root 4096 Feb 26 2020 fog_web_1.5.8.BACKUP
drwxr-xr-x 10 root root 4096 Nov 20 12:12 fog_web_1.5.9.BACKUP
drwxr-xr-x 11 root root 4096 Jun 22 10:22 fog_web_1.5.9-RC2.9.BACKUP

I’ll have to test the older bzimage kernel next Wednesday, I’m on vacation until then. I will get back to you with the results that morning.

@sebastian-roth I never change kernels, so I’m assuming that it was the standard one packaged in to 1.5.7, and then if updated it was the latest one from 1.5.9.

Output from ls -al / | grep tftp

drwxr-xr-x   5 fogproject root       4096 Jun 22 10:09 tftpboot
drwxr-xr-x   5 root       root       4096 Nov 20 12:12 tftpboot.prev

Output from ls -al /home/fogproject

total 44
drwxr-xr-x 3 fogproject fogproject 4096 Feb 26  2020 .
drwxr-xr-x 9 root       root       4096 Nov 20 12:12 ..
-rw-r--r-- 1 fogproject fogproject  220 Apr  4  2018 .bash_logout
-rw-r--r-- 1 fogproject fogproject 4144 Feb 26  2020 .bashrc
drwxr-xr-x 3 fogproject fogproject 4096 Feb 26  2020 .config
-rw-r--r-- 1 fogproject fogproject 8980 Apr 16  2018 examples.desktop
-rw-r--r-- 1 fogproject fogproject  807 Apr  4  2018 .profile
-rwxr-xr-x 1 fogproject fogproject  681 Nov 20 12:11 warnfogaccount.sh

There was no output from the last command.

My current kernel versions:

bzImage Version: 4.19.145
bzImage32 Version: 4.19.145

@sebastian-roth secure boot is disabled, only thing security-wise that is enabled is the TPM, but that was enabled previously as well and was able to boot then.

@sebastian-roth A bit more interesting information…

I’ve tried it on a few different models that we have here. I get this error on every Dell Optiplex 7010 and Lenovo M83 that I try. I also tried a Dell Latitude E6320 and a Dell Optiplex 5040. Both of those were able to get past that part and image.

@sebastian-roth Here is an output of the process when scheduling a hardware inventory update task.

The exit_boot() and efi_main() both show up when choosing the Full Inventory option when a host isn’t registered, when trying to deploy an image from the menu, and when I schedule either of those tasks. It seems to boot fine to the hard drive, update product key, etc from the menu.

This only occurs with the uefi boot process. Legacy works fine, but it won’t be an option for our newer computers that are UEFI only.

@george1421 I created the uefi usb drive using the steps for the harder way in: https://wiki.fogproject.org/wiki/index.php?title=USB_Bootable_Media#USB_Boot_UEFI_client_into_FOG_menu_.28harder_way.29

This way has it so that it always uses the ipxe.efi file that is created in the installation process to actually boot the fog menu, from what I gather. So I assume it’s using the recompiled ipxe binaries that are made with the certificate that is created at installation.

I can try redoing this method and see if it changes things, but I’m not sure if it will since it’s leveraging that ipxe file.

Hello,

I recently upgraded from FOG 1.5.7 to 1.5.9. After upgrading, I tried to boot up a computer for imaging, using a uefi ipxe usb drive. It makes it to the FOG menu, but any option I choose from there ends with an efi_exit…failed! message.

The server is running on Ubuntu 18.04, and when I installed it I used the -S option for https. Also, if I boot using an MBR ipxe usb drive, it works fine. Both the uefi and mbr drives TFTP to the respective ipxe files on the server (ipxe.efi and ipxe.pxe), and then go to the FOG menu ( I do this to ensure I’m using the latest ipxe versions that FOG uses instead of having to update my drives every time).

Any help is appreciated!

Curious if anyone else is running into or has ran into this problem. I have a powershell script snapin that makes a samba share connection using the New-PSDrive command. In the past, this worked fine and I was able to connect to the drive and pull down the install files that were needed to install my programs. Recently (not sure what changed), the snapin script still runs, but it cannot make a connection to the drive using the SYSTEM account that the FOG client uses. I tested to make sure it wasn’t a share issue by using a few of the local accounts on a computer to run the script. I also used SysInternals to leverage the SYSTEM account to try and run the script that way. When doing that, the script fails at the New-PSDrive step with an error: “A specified logon session does not exist. It may already have been terminated.”

Things I’ve tried/checked:

• Script runs under local accounts and connects to the network drive, as both normal user and Admin user.

• Snapins that don’t involve mapping a network drive work fine.

• I thought it might have been an issue with Windows 10’s new feature update, but it occurred on the latest feature update and the previous one that worked before.

Like i said, i don’t think this is a FOG issue, but just curious if anyone else maps network drives through scripting, and if anyone else has came across this issue.

Here’s an example of what my snapins look like for mapping network drives:
Snapin Example.txt

@Sebastian-Roth that’s good news! I can test it out once it’s wrapped in. I tried what John did, but didn’t have any luck. Also tried following the wiki post on HTTPs/custom certificates that you shared in the other thread, but was still getting the overlength error. I decided to just use the certificate that FOG creates on install instead of my custom one for now.