@george1421 Remember that during a capture, the $storage variable is defined, usually:

IPAddress:/images/dev

In the case of a deplooy the $storage variable is defined, usually:

IPAddress:/images

That’s why the checking.

If somebody wants to move the postinit into /images, then it should be symlinked, but that’s beyond our scope. That’s more of a preference .

@vemoya said in Cannot find disk on system:

develop something to remedy this issue with RAID BIOS configs

This is beyond the capabilities of the FOG Project. The FOG Project relies on the linux kernel developers to interface with the hardware. Intel will not release the drivers for their RST Raid controller. In tern the linux kernel developers can’t create a driver to see the disks behind the intel raid controller. This is an issue that impacts the entire linux community. The trifecta is uefi + intel RST Raid-On + linux. If you change any one of the elements FOG will be able to see the disks behind the controller.

Sorry, I’ll post a new topic.

After lots of trying I’ve been able to deploy printers. The main problem was the name of the printer, which is not clear what it should be.

I’ve put the details in a new topic: https://forums.fogproject.org/topic/14891/problems-deploying-printers

Thanks for your help!

@Detoss Multicasting can be easy and hard at the same time. Here is a wiki page you can review: https://wiki.fogproject.org/wiki/index.php/Multicasting

I can tell you if your fog server and client computers on the same subnet and you enable igmp snooping on your switches it will be easy. If you are trying to multicast across subnets you just hit hard straight on, but not impossible.

Ok, I don’t what happened, but it’s working now.

Thanks!

FOG.png

@danieln Ohhh yes, didn’t even think about this. Sure if you deploy straight without registering then it’s a totally different story.

@Sebastian-Roth Thank you, this worked beautifully.

@george1421 said in problem boot ipxe with usb nic after update FOG 1.5.8 -> 1.5.9:

@Sebastian-Roth Just circling back on this.

I took 3 of the dell systems here that have thunderbolt/usb-c ports and use the WD15 (mainly), WD19 and the Dell usb-c to ethernet adapter.

I downloaded the ipxe.efi from the github site: https://github.com/FOGProject/fogproject/blob/master/packages/tftp/ipxe.efi and installed it on my production 1.5.7 server. I confirmed the iPXE build number is [g4bd0].

It works with usbc->ethernet dongle.

I was able to pxe boot into the FOG iPXE menu with a Dell 7400, 7389, 3520 laptops with the WD15 and usb-c to ethernet dongle. The 7389 pxe booted with the WD19 dock OK. I did not test the others.

I can confirm that the version if ipxe.efi from FOG 1.5.7 is [990f4]. So as far as I can tell there is no impact of updating from 1.5.7 to 1.5.9 on network booting.

Thanks you very much.

@george1421
Thanks, Ill give it another try with the Debian instructions and get back to you on if it works.

@zaccx32 said in Pxe-Boot gets hung up on TFTP:

I did find a way to identify which machines are being affected by looking for extremely slow copy speeds when deploying files with PDQ. 4MB files will take over an hour to copy on machines that are being affected.

This here kind of tells me its network infrastructure. What I would do is look at the network switch port (hopefully you have a managed switch) and look at the port counters. See if you are having a lot of crc errors. Can you generalize and say all computers from area A have a problem but not from area B. If this is the case then the troubles may be on an uplink port between the area A switch and the next switch in line. Again the port counters might give you a clue to what is not right. IMO if you can duplicate the error with 2 different servers then its probably not the FOG server at fault.

I did notice something in your dhcp screen shot. Its not a problem with fog, but in your polycom scope, you should probably remove the undionly.kpxe boot file name. Its not relevant to a voip phone and may cause problems.

The other thing since your dhcp server supports profiles you might want to take a look at this wiki page to setup profiles for both bios and uefi booting: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@george1421 Hello, sorry for the late. This is what I get without the Kernel Argument:

alt text

And this is what I get with the Kernel Argument:

alt text

@george1421 said in Issues with inventory and uploading image:

That isn’t the response from the file command I expected.

Some older Linux systems do not provide the great output using file that we see with up to date systems.

As the OP reported the issue is solved, we don’t need to worry.

@DylanG I provided a database query and requested you to post a picture of the error you see on screen. If you don’t provide that information I won’t be able to help you.

@VlanFlex said in FOG won't deploy properly.:

https://ibb.co/D1wd4cs
Any idea why it would show up as an SATA device?

Can’t see enough information on the picture as it’s not clear enough. M.2 does not mean the disk is NVMe in general! So I can imagine this to be a M.2 SSD drive showing up as sdX in Linux. You can run hdparm -i /dev/sdX (put in a and b instead of the X) to get some more information about the disk drives.

@Pere-Pozo-Miro You are probably using a dock for network connection, right? Some of the docks do a pass through of the device’s MAC address or hand out the dock’s MAC address either.

Which exact model of dock do you use?

How do you register the device? Through the PXE menu or manually in the web UI? What MAC do you see in the web UI for it after registration? Please post the full MAC address or at least the first three blocks here in the forums so we know which vendor it belongs to.

@george1421 Thank you so much! It works now!

These laptops are coming with M2 Nvme disks, i used diskpart in windows 10 with “clean all” option to fix the problem.

Yes all laptops are UEFI only

I am building fresh windows 10 using one of the new Microsoft ISO files.
I will try to capture an image from one of the laptops and try to deploy it to other.

If this will not work we will raise a ticket with dell

@wmw509 Disabling CSM makes sense. I’ve seen a lot of bioses that if CSM is enabled it only lets you use the legacy/bios pxe boot. I’ve had that disabled on all my hardware for so long I forgot it was a thing.

@FOG38640 said in DHCP option 67:

Is there an option for FOG to automatically choose between BIOS and UEFI?

For what? For the network boot file?

If so that is done by your dhcp server. What is your dhcp server? (its been a few days so I don’t remember, a quick scan of the thread didn’t answer that question either)

Edit: found it way at the bottom Windows 2019 server. So there is instructions for windows 2012 and later. Hopefully it translates to 2019 dhcp servers. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@Sebastian-Roth
Hello, Sebastian,
I believe the reason for why hostnames were not updating was due to the client not being up to date, however, after a name change, AD is still not updating, causing a trust relationship error when logging in and the domain does not change. Also, we a running 0.12.0 client version. Any other ideas on why AD is not communicating correctly? Thanks!