@john-l-clark I would start by running through this process to resync the user account fog uses as a service account.
https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

@paul-0 As Sebastian mentioned FOG can’t support secure boot at this time so you will need to disable that if you want to boot into FOG.

Switched back to legacy mode should not be required to work with FOG. FOG supports UEFI booting no problem. You must make sure your image that contains the testing software must support UEFI booting. You can not deploy a BIOS based image to a UEFI computer and make it work. You can only deploy a BIOS captured image to a BIOS based computer and a UEFI captured image to a UEFI based computer.

I should ask what version of FOG is your server? FOG servers since 1.2.0 support uefi booting, you just need to update your dhcp server to send the uefi boot file name of ipxe.efi

If you need to boot both uefi and bios computers and you have a linux or windows 2012 or later dhcp server then its possible to make a dynamic boot so both uefi and bios computers will boot happy into FOG.

@acsand0199 There is a hidden file in /opt/fog called .fogsettings (yes it starts with a dot, that inidicates the file is hidden) So you wan to edit /opt/fog/.fogsettngs replace all references to eno1.

If you are using the FOG server as the dhcp server for your imaging network then you should look through the isc-dhcp config file to make sure its binding to the right interface.

Then in the web ui in FOG Configuration->FOG Settings hit the Expand All button and then search the page for eno1 and replace its instances with eno2.

Then again in the web ui look at the default storage node settings confirm there it references the correct network interface.

Finally back in the linux console rerun the FOG installer script. It will pickup the settings stored in the .fogsettings file and fix up the rest of the FOG environment.

@emreonder Do you have the fog client installed on the ubuntu target computer’s golden image? The fog client is responsible to set the target computer’s name post imaging.

If you want to do this without the fog client installed, you will need to write a bash script to rename the host. You will do this via the FOG PostInstall script process.

@roc1479-0 That is what I figured. If the update didn’t go as planned then you would not have 5.6.18.

You can manually download the kernels from here
https://fogproject.org/kernels/Kernel.TomElliott.5.6.18.64 save as bzImage

and
https://fogproject.org/kernels/Kernel.TomElliott.5.6.18.32 save as bzImage32 (note case is important)

Move those files to /var/www/html/fog/service/ipxe on the fog server.

You can confirm that you have the right files by running this command file /var/www/html/fog/service/ipxe/bzImage If it returns 5.6.18 in the resultant string then you have the right kernel in place.

One last tidbit if your fog server has internet access you can use the wget command like this wget https://fogproject.org/kernels/Kernel.TomElliott.5.6.18.64 and it will download the kernel to the current directory. Then just move it to the right location.

@roc1479-0 said in Dell Optiplex 5080- Network Interface not found:

8086:0D4C

Was first supported in linux kernel 5.5, so 5.6.18 should support that hardware.

What I want you to do is stop any currently running capture/deploy task.

Then schedule a new task but before you hit the schedule task button, tick the debug checkbox then schedule the task.

PXE boot the target computer. After a few screens of text that you need to clear with the enter key you will be dropped to a linux command prompt. At that command prompt key in the following commands. Snap a clear picture of the results with a mobile phone and post it here.
uname -r
ip a s

The uname command should return 5.6.18 if you are running the updated kernel. If its any value less than 5.6.18 then you don’t have the proper kernel downloaded (we can address that later).

The ip command should return the found network adapters. It should find the loopback adapter as well as the physical network adapter. If it doesn’t find the physical network adapter then run this command.
lspci -nn | grep -i net and post the results.

@wayne-workman said in Fedora 33 and Ubuntu 16:

wants to get everything OS agnostic by replacing PHP components with NodeJS ones, getting the UI and API away from making native OS calls, so on.

I agree with this too. Node.js opens the door to running the FOG server on a lot more platforms than just linux. It WILL be a long road to get there (if ever). We do need 3-4 node.js new developers to step up and restart the FOG-too project to get things moving.

@wayne-workman I think there is surely a value in creating a supported operating system list for the FOG project. While its technically possible to support all 31 flavors of OS, there are reasons for leave some OS behind on the floor especially ones that are no longer supported by their distro vendor. The work you have done with the demographics collection shows the FOG Developers where they need to spend their time with support and testing FOG. So well done there too.

@nerdstburns Yes you can.

In the image definition just configure these options

Image Type: Multiple Partitions Single disk non-resizable
Partitions: Partition 1 only

The only warning is to be sure you know the physical partition you want so that you select the partition you need.

@kylian Well the simple answer is yes you can. In the host management page of the target computer there is a filed to identify the disk you want to send the image to.

The bit longer answer is the format of the disk is dependent on how the disk is connected to the computer. If its over a sata cable then disk 1 will be /dev/sda, disk 2 will be /dev/sdb and so on. So if you wanted to deploy to the 3rd disk on the computer you would enter /dev/sdc into that field.

@seppim The last link you provided would be my instructions.

@seppim So the question would be if you were to boot this iso image which menu item would you pick? The answer you need IS in the config file, I just need to know the question.

Translating between syslinux and iPXE is pretty straight forward.

Using your example in syslinux format

LINUX boot/x86_64/vmlinuz
INITRD boot/intel_ucode.img,boot/amd_ucode.img,boot/x86_64/sysresccd.img
APPEND archisobasedir=sysresccd archisolabel=RESCUE701

that would translate to in iPXE

kernel boot/x86_64/vmlinuz
initrd boot/intel_ucode.img,boot/amd_ucode.img,boot/x86_64/sysresccd.img
imgargs vmlinuz archisobasedir=sysresccd archisolabel=RESCUE701

Then to normalize this with the others from my tutorial

kernel tftp://${fog-ip}/os/RescueCd/7.1/vmlinuz
initrd tftp://${fog-ip}/os/RescueCd/7.1/sysresccd.img
imgargs vmlinuz archisobasedir=sysresccd archisolabel=RESCUE701

Menu Item: os.SystemRescueCd.7.1
Description: SystemRescueCd 7.1
Parameters:
kernel tftp://${fog-ip}/os/RescueCd/7.1/vmlinuz
initrd tftp://${fog-ip}/os/RescueCd/7.1/sysresccd.img
imgargs vmlinuz archisobasedir=sysresccd archisolabel=RESCUE701
boot || goto MENU
Menu Show with: All Hosts

@colossalfalafel Acutally I’m working on this issue in this thread: https://forums.fogproject.org/post/140103 I have positive success with a precision 5510, but I have doubts that its actually working. Would you test both bzImages from the above post? I don’t know if it works on my wife’s 5510, because the linux kernel developers fixed it or there is something strange with the configuration her company puts on her computer (I didn’t want to make any adjustments to it because its protected by bitlocker). The computer is in uefi raid-on mode and I can see the storage disk when I pxe boot into FOG. This is a driver compatibility between the hardware and linux kernel itself (bzImage) in FOG’s case.

The issue is that the intel sata controller changes its personality based on raid-on mode vs ahci mode. It actually presents itself as a different device with a different hardware ID based on what mode it is running in.

Edit: Ignore this request, the 5510 I have has a sata disk in it. I just tested the kernel with a 7280 with an NVMe disk and the linux kernel does not work with this disk structure. So we are still no where in regards to a solution to this.

@cyril Looking up the disk controller 8086:06d6 support for this adapter was first added to linux kernel 5.7. So the 5.6.18 kernel doesn’t support this controller. In the picture of the 5.10.2 (which should have the driver for this raid controller) lsblk is not showing the disks either. This is disappointing. I can tell you the raid controller in your device is very new so linux support may lag a bit. I know that is a different controller than I have in that 5510 which is a few years older.

@cyril I guess I should have asked, what is the manufacturer and model of this computer? (edit its in the subject line of the thread) I tested on a Dell Precision 5510 I have here at home and it worked. I was able to see the disks with the firmware in raid-on mode.

@jj-fullmer As long as you have that bzImage5618RT3 kernel queued up could you test what we are talking about in this thread: https://forums.fogproject.org/post/140103 I may have inadvertently fixed the requreiment to switch the computers from Raid-on mode to ahci to image with FOG. I know this might be a Dell specific setting, but its related to the Intel RST disk controller in raid mode. I think the lenovo systems should also have a similar setting because its an INTEL thing not a computer manufacturer thing.

Edit: Ignore this request, the 5510 I have has a sata disk in it. I just tested the kernel with a 7280 with an NVMe disk and the linux kernel does not work with this disk structure. So we are still no where in regards to a solution to this.

@cyril I might have a solution here, but I need your help to test it.

I have 2 one-off kernels I would like you to test. These are not mainstream FOG kernels but ones that are purpose built for a specific task (such as for custom hardware).

Here is bzImage5618RT3. This kernel is based on the FOG official release 5.6.18 but has additional hardware turned on plus a patch for the realtek network drivers (not related to your issue). Download this file and place it in /var/www/html/fog/service/ipxe directory on the fog server as the name above. Remember for FOG case is important.
https://drive.google.com/file/d/1vSu5L-DAZYK7VYiJtFfCYrrqJb963cMg/view?usp=sharing

The next one is bzImage5102. Same as above download this file to your fog server in the path above.
https://drive.google.com/file/d/1-4HyQD8ttz_GCE_vKrvuydFVqcPUMqzU/view?usp=sharing

Now on to testing. I want you to register one of these computers and have the disk mode set to raid-on.

Go into the fog webui and then FOG Configuration -> FOG Settings -> Expand All -> TFTP PXE KERNEL and change that field to read bzImage5618RT3 and update the settings on the fog server.

Now I want you to go and schedule a deploy task to this computer, but before you hit the schedule task button tick the debug checkbox. Then schedule the task.

PXE boot the target computer. After a few screens of text you will be dropped to the FOS Linux command prompt. At the fos linux command prompt I want you to key in the following commands.
uname -a (this should have 5.6.18 as the version)
lsblk
lspci -nn | grep -i sata
Take a picture with a mobile phone and posts the results here.
Power off the target computer.

Now repeat the same steps with the bzImage5102 kernel. Make sure you update the FOG Settings value to bzImage5102 and save the results. In this case you will NOT need to schedule a new task because the task will already be running. Power on the computer and pxe boot it. Once at the FOS Linux command prompt key in.
uname -a (this should have 5.10.2 as the version)
lsblk
lspci -nn | grep -i sata

Take a picture with a mobile phone and posts the results here.
Power off the target computer.

Kill the running deploy task on the FOG server using the WebUI.

If the lsblk command returns (something like this) then the FOS Linux OS can see the disk and should image now. Note the structure may look different based on the OS, but the key is the OS seeing sda or the nvme disk with raid-on mode enabled in the firmware.

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 238.5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0   238G  0 part /
sr0     11:0    1  1024M  0 rom  

If all of these tests pass then reset the TFTP PXE KERNEL field back to bzImage5618RT3 (most closest kernel to the FOG supported kernel) and try to image that computer normally.

@foggymind You need to capture the pxe booting process not the dhcp release /renew. This is release/renew is handled by windows where the pxe booting process is handled by the uefi/pxe rom. The process is to start wireshark with a capture filter of port 67 or port 68 to capture the dhcp process. If your fog server and target computers are on the same subnet then you can use tcpdump on the fog server to get the best details into what is not working.

Again are your clients that you are trying to pxe boot beyond a router? I have see (and again just recently) that if your MTU of the link is set below the block size for tftp the file will not transfer because the packets will be fragmented. tftp doesn’t handle fragmented packets. So everything will look like its working up to the point where it tries to send the file to the target computer. If everything is on a LAN and your mtu is the default of 1500 then we should look elsewhere.

@tom-elliott said in Unit nfs.service could not be found:

To understand:
/dev/sdb = /images
/dev/sdc = /opt/fog/snapins

I 100% agree with this route AND to add create the partitions on the disk as standard partitions and not LVM volumes. If they are standard partitions you can expand them easier than a LVM volume (debatable) if you are running the fog server on a V and need to grow your storage.

@foggymind

It could be interperted as you said this:

Just started randomly receiving this error while attempting to UEFI boot

That is where we made a left turn in the discussion(right out of the gate).

Is the remote pxe booting client on the same subnet or beyond a router? IF beyond a router what is your MTU of the link?