@Detoss So your goal is to reset the web ui password for the fog system admin?

If yes then there is a wiki page for this: https://wiki.fogproject.org/wiki/index.php/Reset_WebUI_FOG_password

@george1421 Ahhh, missed that part. But nonetheless I think it doesn’t hurt to have it added even now so we don’t forget as soon as we update the kernel to 5.9 and later.

@Goll420 said in Multicasting:

I’ve set the remaining 8 going now, but I omitted the WOL part and started them manually. See if it makes any difference.
I never said before that this was a RAW image as the drive was encrypted with Bit Locker. I noticed an error on the end of the deployment on the hosts and then the reboot.
The tasks still show spinning and the hosts have all gone back to the deployment screen amd sitting there waiting for it to begin.
Logs show that the Multicast has finished, but I believe it’s this error that is stopping it progressing any further.

Sorry for the long delay. Time is sparse at the moment and digging into such things usually takes a bit. I just tested multicasting several times and they all worked perfectly fine finishing the task. I am fairly sure that what you describe is caused by some kind of “checkout” issue where hosts are don’t properly report back to the FOG server when finishing the multicast session. So it would be helpful to know what error message you see at the end. If you see this happening again you might want to take a look at the Apache and PHP logs (see my signature) on the FOG server to see if errors are reported there as well.

Image type being RAW shouldn’t play a role. As far as I can test and know the code this does not seem to be a general issue in the multicast code I reckon.

@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