@edv-schuster Actually RSTP is preferred over STP for a few reasons (forwarding right away is very helpful for pxe booting).
Can you provide a clear screen shot of where you are getting stuck? Also having an unmanaged switch (the most basic switch) for testing is also helpful if we need to test more.
@robertd At the moment if you want to use hyper-v on win10, then use 1703. Or use hyper-v on 2012 server.
@imagingmaster21 Then I would do the export and import from the web gui. Its quick and pretty painless.
What does the storage node configuration look like for the “Park City FOG VM Server”? Can the master fog server ping that server at the IP address listed in the storage node configuration?
Is the “Park City FOG VM Server” a real fog storage node or is it a NAS configured to look like a storage node? (I probably already know the answer, but it never hurts to ask).
At the point where it tries three times. It looks like its picking up an IP address. Where it appears to be failing (hint: we need to get a few extra echo statements in there to say trying to contact the fog server at IP address xxxx) is to contact the FOG server to prove it has a path. Now I don’t know if its the storage node it tries to connect to or the master FOG server. But I feel at this point its failing to communicate, so it tries 3 times and gives up.
@imagingmaster21 do you need your whole fog database or only the image information? If its only the image information, the quickest way is via the web gui. Go into the images on server A and export the image definitions, then log into the web gui on server B and import the image definitions. This will move over the image definitions without over writing (messing up) anything else in your server B FOG server.
If your end goal is actually migrating to a new server, then there is a wiki page that covers the migration: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
@kafluke Good centos 7 will handle network interfaces a bit differently. So that is a good thing.
@zacadams As long as the fog client is installed, you don’t need access to any domain. I was only commenting if you need to pull files from somewhere else. The self contained snapin packs are a much cleaner solution anyway.
@imagingmaster21 Let me make sure I didn’t miss something. Your response was not clear to me.
Your goal is to copy all of the images from fog server A to fog server B right? If that is the case you can use NFS as it mentioned to mount the /images share on server A over to a temp mount point on server B. Then copy everything in /images from server A to /images on server B.
What I posted will work for that as long as you confirm that file owner ship and permissions on server B matches server A.
@zacadams You can create a snapin pack (think zip file). That snapin pack will contain a batch file (to do the moves on the system locally) and the target file you want to install.
To do this your snap in pack will contain the file you want to move and a batch file similar to below.
Rem copy this file to that
copy "%~dp0\File_to_move.txt" "c:\Windows"
The thing you have to remember is that the snapins run as the local account SYSTEM. This account has no domain rights. If you need to reach out of the target system for a file, you will need to use this drive mapping command to connect as a user.
net use t: \\server\filepath /user:domain\user password
Understand there are risks with leaving a plain text password in your batch file. Bundling the file to move it a much cleaner and secure path to use. But either way does work.
@imagingmaster21 There are a few ways to go about this. But I take it you want to copy/replicate files to a new server?
If so a quick way would be on the new / blank server use nfs to mount the images directory on the legacy server. You will have to adapt this command for your environment. This shall be done on the new blank server.
sudo mount -t nfs <legacy_fog_server_ip>:/images /mnt
if that command executes successfully then
sudo cp -R /mnt/* /images
That will copy the mounted legacy fog server /images directory over to the new fog server /images directory/
And then finally when the copy is done, unmount the legacy fog server.
sudo umount /mnt
If you happen to throw the backup of the FOG database files in /images on the legacy server, those files will be copied over too.
The last thing you need to do on the new fog server is make sure the file permissions match on the new fog server to the legacy fog server. You need to ensure file permissions and ownership is correct.
@kafluke Ok that image looks like its based on Centos 6 (maybe 6.6). There should be a file in /etc that will tell you what release but I’m pretty sure its Centos 6.
cat /etc/centos-release
So in this case Sebastian’s guidance is spot on. You need to modify the udev naming rules. Or just remove the reference to the golden image network adapters in the udev rules. For example here is my udev naming rules from /etc/udev/rules.d/70-persistent-net.rules on one of my old FreePBX servers.
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:10:50:29", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:10:50:28", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x8086:0x1026 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:83:27:aa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
You need to remove these lines or just create a blank file.
Lastly in /etc/sysconfig/net-scripts you need to remove the mac address references (HWADDR=00:00:00:83:27:aa) from all of the ifcfg-ethX config files.
This is not a fog thing, but more a centos 6 thing.
@kafluke Yes, freepbx is centos based. Depending on what version of freebpx, you will have either centos 6 or centos 7. I can tell you Freepbx 14 is centos 7 based and Freepbx 12 is centos 6 based.
@magingmaster21
Please setup a debug capture (schedule a capture again, but tick the debug option) and then PXE boot the target computer. This will drop you to a linux command prompt on the target computer after a few Enter key presses. From the FOS comand prompt key in the following cat /proc/cmdline. Finally please post the output here. That kernel command line will tell us where the captured images are going.
I’d also like to know the target OS here. I can speak for Centos. In Centos 6.x here it is exactly as Sebastian says with udev rules and the network naming convention (eth0, eth1, etc). With Centos 7 and Linux Mint 18.x (which is based on Ubuntu 16.04) the kernel developers have switched from ethX naming convention to embedding the driver name into the network interface name. For example on my laptop the ethernet adapter is named eno1 and the wiifi adapter is named wlp2s0. It is my experience with at least Centos, it names the network adapters what the kernel calls them and then for the network config files in /etc/sysconfig/network-scripts the OS will rename eno1 as eno1.bak and creates a new eno1 config file if the mac addresses don’t match in the file.
If the udev rules are as Sebastian says with the older OS’ you can setup something similar to what I do for building a windows base image. I have a batch script that does some last minute clean up of the windows system then calls sysprep directly. This way I ensure all of the last minute stuff is done every time and then the computer is shutdown properly. You could do the same thing with a bash script to clean up any needed system settings and udev rules then shutdown the linux OS properly in preparation for image capture. This way you will have a consist image build if you need to reopen your golden image for any reason.
@tesparza What application are you trying to deploy? Searching on http://www.itninja.com/ usually gives me answers to silent application deployments.
Just for clarity here (because I’m a little confused on what you are asking). The .EXE’s you deploy may or may not take arguments. In regards to FOG the arguments you want to send still go into the “Snapin Pack Arguments” field. The developer of the .EXE has all of the control on what command line arguments they will accept. FOG can only pass what is in the “Snapin Pack Arguments” field when invoking the snapin.
For example if you have just a simple .exe that take parameters it would look something like this (using no preconstructed template)
If I misunderstood what you are asking, please clarify.
@sudburr The issue (as I understand it) is where he’s running hyper-v on top of Windows 10 1709. Where in Windows 10 1703 iPXE booted correctly, and now it doesn’t. As I’ve said before, while Win10 1709 flies the Win10 banner, it is very different operating system under the hood than is 1703.
@fernando-gietz If I can break some time free I’d like to look at it from a SQL database point of view. We may be missing an index that is causing such a bad performance.
@paulman9 said in Hyper V and Pxe boot to Fog problems:
IMAGE_TRUST_CMD
Interesting these all deal with certificates. As long as you are not doing anything with https on your FOG server, what you built should work OK.
This makes me wonder if the certificates may be related to secure boot being enabled on this win10 host system? I’m only guessing (TBH) but just trying to correlate why an upgrade to 1709 and certificates/image verify would be related. BUT this is excellent info to take back to the iPXE guys. I’m sure they will see this more often than the FOG project.