@george1421 Just thinking outside the box as it makes 0 sense for it to be “just these network cards”

I suppose the “real” test would be seeing if outside of this room if the same problem happens?

I know not simple, but if you can move the whole room to an area where we know this issue doesn’t currently exist, and it shows, then it’s likely specific to this equipment. If it doesnt’ show up, it’s likely something specific to that particular room.

@Tom-Elliott
Habit, simply habit. I looked back at the wiki documentation and it definitely does not say to use sh. I do apologize for the confusion and hopefully this helps someone in the future.

@boros

I want to transfer the “Gold” Images from the server in the other site. Can I just copy and paste the Images Folder from from the other Linux Machine?

The short answer is yes, but there is something you need to know.

FOG Images are made up of two components. The first is the raw data files that are kept in /images directory on your fog server. The second part is the metadata kept in the database. You need both to make the image functional. You can copy the files over by hand, but you will need to either recreate the metadata on the target system by hand (not a difficult task) or export the the image definitions from the source computer and import them on the destination computer

Now one other tidbit that is not supported by the developers, but it works. If on your master server you add the remote fog server as a storage node. The main fog server will be a master node and the remote server is a storage node (just in the context of this configuration), the master node will copy any image marked as exportable all storage nodes in its storage group. This will get the raw images over to the target system using the standard fog image replication. But the thing it doesn’t do is copy over the image definitions. You will need to do this using the export and import method, or by manually creating the image definitions by hand. Using this method you can have golden images pushed out by HQ and each site will still be able to create their own golden images too.

@skyborne98 Thanks for testing and sharing you insights here!

I just added this info to the wiki: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Installing_-_Linux

@george1421 That was it. Thanks

details:
I had named the menu item HD Wipe
The config file said HD_Wipe
I used the GUI to rename HD Wipe to HD_Wipe and all worked well.

@Enigma I asked a few questions in chat, but I’ll reask them here.

Is this your fog server’s IP address? 192.168.107.200 Your dhcp server isn’t sending dhcp option values, what device is your dhcp server? Your dhcp server needs to be configured to support both bootp (values in the ethernet header that are present in the pcal) and dhcp (missing dhcp options 66 and 67).

@ArtemZ I would check to make sure your dhcp server has the fog server’s IP address in dhcp option 66. The error message is kind of telling me that.

@ryanlewis2010 Do I get this right? You say the printer assignment done in the FOG web UI magically vanishes after a random time (1-30 minutes)?? Sounds really strange. I don’t think I have ever seen this happen.

The assignments are simple database entries and there is no specific FOG log you can look at I think. But you can enable MySQL/MariaDB logging and try to figure out why this is happening. Will still be hard to find out what is causing this even if you see it in the logs.

Do you use the FOG API by any chance? Some kind of scripting to automate FOG stuff?

If not it’s probably best to manually check the database tables on your FOG server:

shell> mysql -u root mysql> use fog; mysql> SELECT * FROM printerAssoc WHERE paPrinterID NOT IN (SELECT pID FROM printers); mysql> SELECT * FROM printerAssoc WHERE paHostID NOT IN (SELECT hostID FROM hosts);

The later two (select) queries should return an empty result set. If you get results it means that there are assignments still in the database for hosts or printers that do not exist anymore. While this is not a problem in general it would still be wise to clean that up.

Now you can start looking a a certain host having printers assigned by: SELECT * FROM printerAssoc WHERE paHostID=123456 (put in the host ID you see in the FOG web UI (parameter in the URL when editing this host)

See if the assignment is in the database compared to what you see in the web UI.

@Alan-Lim @jfernandz The message Starting sshd: touch: cannot touch '/var/lock/sshd' : No such file or directory is normal with the buildroot version currently used for the FOS inits. While it’s not nice it’s not causing any kind of issue and can be ignored.

The mount error seen after that is probably caused due to a router or firewall now allowing all the traffic needed to mount an NFS share.

@professorb24 said in Can't get pxe boot on my VM (FOG):

me to give out “fake” IP addresses

I think we have a language conflict here.

To use fog, the target computers (the devices where you will deploy your image), must use dhcp to get the pxe boot information. If you don’t have dhcp available for the client computers you will have a difficult time booting over the network. With that said, we do have a method to boot the computes into FOG via a usb boot stick. In this case you will need to take the usb boot drive around to the computers to start the imaging process.

The second issue you have is WDS. Right now FOG and WDS can not both occupy the same IP subnet since they will fight each other for network booting.

@DBCountMan If I recall correctly, this is on purpose. It’s been a while since I looked at it, but we set LDAP users to a specific set of identifiers and filter those out of the view because things you can do with local users (change password, etc…) you should not be able to do with LDAP based users.

@af-pw I’ve reread your OP several times and its not clicking in my head to what the problem is.

I can tell you that its possible to have 2 standalone fog servers and have the images from server A replicated to server B using the fog UI. All of the images from server A can be replicated to server B and then server B can add its own images to its own server only. But there is a caveat with this solution and its not supported by the Developers. Let me explain.

For a fog “image” there are two components. The first is the raw data files stored in /images. The second is the data base record (meta data).

You can do this by on server A going into the storage nodes and add server B as a slave storage node. Then add server B to the storage group for storage A. This will start to replicate the images from FOG server A to FOG server B. If there are images you don’t want replicated to server B, on server A go into the image definition and disable replication for that image.

Now for the caveat. The process above will replicate the raw data to server B. What it will not do is copy over the meta data. You will have to do that manually. on FOG server A go into the image definitions and export them as csv. Edit the csv with your favorite editor removing image definitions you don’t want to appear on server B. Then on server B’s web ui import the image definitions from server A. This step really only needs to be done if/when you add new images to server A that you want to see on server B.

@george1421 The PXE boot option only shows up if I remove the hard drive. Once I insert the drive, the PXE boot option disappears. Cant force boot or change boot order.

@skyborne98 Lets see if this document will answer your questions: https://docs.fogproject.org/en/latest/management/web/storage-node/

@kier056 What values do you have defined for dhcp option 66 and 67 on your dhcp server?

I am facing the some problem.
I Got it working …
i Changed the Indle Power Savings to Normal , under Powe Section in Bios

@herman Debugging this may be difficult. What changed between 5GB/min and now 270MB/min?

I’m going to suspect network issues, but what specifically changed?

The problem is solved.
I disabled DMA protection on the HP ProBook.
Good day.

Yes, that worked, thank you very much!