@huecuva That is an interesting update for sure. I believe graphics cards have a bios of some sort and sometimes there’s some option rom boot option related to the gpu in the computer’s bios setting. It would make some sense for the graphics drivers to also update the bios or boot option roms on gpus.
What GPU’s do you have? GPU’s of the gtx 10xx series and newer have a ‘studio’ driver option that’s supposed to be the sort of ‘stable’ branch option. If your cards can use that, maybe using that as a standard could help if it’s not something you’re already doing?

@kdmiller45 Sounds as if the database update at the end of the capture task failed. Please run ls -al /images/dev/ on your FOG server and post output here.

Ok, let’s call it quits. I just pushed a commit to the fos repo to add this patch to our build of partclone and add the ignore_crc parameter back to the scripts.

Marking as solved.

@kdmiller45
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Installing_-_Linux

@KenM I am sure it’s the fog-client trying to update but fails in every loop because of the run out code signing cert. Re-installing the new version should fix that.

@Pingolin It’s probably a good idea to follow the things George lined out. Just want to add one question: Did you say yes or no to the installer question “Would you like to use the FOG server for DHCP service”?

If yes was selected then we better take this DHCP offline again as it might mess with your home setup.

@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