Posts made by george1421

@msi said in PXE can't find correct bootfile size:

192.168.134.230

And on the above ip address in /tftboot directory you have the ipxe.efi file? If everything looks good then on the remote fog server we will need to setup tcpdump and grab a pcap file of the booting process because something is going wrong here. All of the bits appear to be in place.

https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If you have questions on the pcap file, upload it to a google drive and either post the link here or IM me and I will take a look at it. I need to go off-line for a few hours, but I will be back later tonight.

@msi So this is at the remote location and you have the dhcp server sending out dhcp option 66 for the remote site’s storage node, and you are trying to pxe boot a uefi system?

@msi Is this at the main site or the remote site?

Ok so since it references to NBP, you are booting a uefi system? What do you have configured for dhcp option 67? ipxe.efi?

At this point it is still a pxe issue and not related to FOG or location plugins.

@m144 This IS really strange. Without knowing what you went through, I would say this is a spanning tree issue, where one of the fast protocols isn’t being used. But at the same time I’m confused why the wireless adapter is being displayed, unless the wireless and ethernet adapter are one and the same.

Are you sure that unmanged switch is really dumb? If its a business class unmanaged switch it may have spanning tree enabled by default. I also may be trying to apply logic to where there is none.

With default spanning tree the port will start forwarding data after 27 seconds from the last transition of the link light if that has any bearing on the success of the ip addr show command or not.

@george1421
4. From here key in ip addr show and see if the FOS engine picked up an IP address.
5. If no IP address is collected then key in lspci -nn|grep net and post a screen shot of the data.

@m144 Ah, OK. This is in FOS not iPXE. Well that gets my head screwed on right now.

OK so you can ignore any of the iPXE (ipxe.efi) issues.

This is an issue with the FOS kernel, not supporting the hardware.

What device are you using for the network adapter? Exact mfg and model?

Also, I need you to collect some info for us.

1. Manually register this computer and network adapter (you will need the mac address of the adapter for this).
2. In the FOG Webgui schedule a capture or deploy, at this point we don’t care. Before you hit the submit button, check the debug check box and then submit the task.
3. PXE boot the target computer after a few screens of text on the target computer it should dump you to a linux command prompt.

@m144 said in UEFI booting with Surface book 4:

“Starting eth0 interface and waiting for the link to come up”

Just for clarity, you are seeing this message before the FOG iPXE menu is displayed?

@rabus Hello Rabus. I’m not sure I understand your questions completely.

1. When you start capture or deploy FOG creates a task for that computer. When target computer is pxe booted, it will see the task and then start the task listed in FOG server. When imaging is done the target computer tells fog server, I’m done then reboots.

2. You can use the fog client to do things for you during FOG imaging, or you can choose to not use FOG Client. If you choose no fog client then you must do the Microsoft way and use the unattend.xml file to connect target computer to domain, activate windows… Just like you do with WDS today.

3. FOG does have a RESTful API like API, but I’m not sure that is your question.

4. FOG is not like WDS. FOG moves reference image from source to FOG server and then from FOG server to target computer. It does not care that image is MS Windows, Linux, or anything else. It only moves images on a hard drive level. You CAN support having a single golden image for many hardwares. You must copy the drivers to the target computer after FOG copies the hard drive to the target computer. The solution may not be clear to you but I do have a few tutorials that show what is possible.

https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog

https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection

https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script

https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins

@jgallo What host OS is your fog server running?

@dpotesta50 Look back at Sebastian’s post. It contains links to information on how to do this.

@quazz said in Update Installation Files Within An Image:

large changes to resizable images as well

This is a great point, if we just mount the image file and change it will it throw off the numbers collected for single disk resizable?

@dpotesta50 IMO this is a bad way to manage this process altogether. You can leverage FOG snapins or even better PDQ Deploy to send images to remote computers. You don’t have to login to the remote computer at all.

With that said there are ways to connect to the captured image on the fog server, make changes to the disk image and then reseal it without ever transferring the image or needing to recompile it.

@msi Well there isn’t a clean way to control replication based on time of day. But there is a way…

There are two elements to this.

1. In each image definition you can control what images replicate. For you to send only two a night, just enable the images for replication you want to replicate on that day.
2. You can setup a cron task to enable and disable the fog replicator service based on time of day. Using the same concept you can change the bandwidth consumption by updating the record in the database then restarting the fog replicator service.

Depending on your image size, you might be better off seeding the remote locations via a usb flash drive then enabling replication on the master node once the images have been seeded on the remote storage nodes.

@wayne-workman ref: https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

@jj-fullmer said in mp500 nvme drive not recognized but it was recognized before:

Intel Optane storage controller configuration majigger.

What model computer was/is this from (for future reference).

@jgallo I’m not seeing any value in adding vCPUs to this VM. And this VM is about 10% utilized.

It looks like the system was rebooted in the last 5 minutes?? That will skew the load values, but so far the system looks normal. It would be interesting to see what the stats are running during the day time under normal load.

@jgallo Can you post the header section of top here?

I’m not sure I understand how your setup is, it sounds a bit unique.

But If you deploy an image to a target hard drive, then move that hard drive and add it as a second hard drive on a functioning computer, you can add/remove files from that installation folder. Once you update the files, move that hard drive back to the target computer then recapture the image.

For fog 1.4.4 and the surface pros please try this pxe boot file: ipxe7156.efi With the kernels included with FOG 1.5.0 (not out yet) the iPXE guys (different open source project) addressed the issue where ipxe.efi wasn’t working with the surface pros.