Posts made by george1421

When you install the FOG Client on the target computers you define the IP address of the FOG server. The fog client will always communicate to the fog server over the defined ip address. When the client moves to another subnet and that subnet doesn’t have full connectivity back to the fog server that is where things fall down.

So what can you do?

1. Change the IP address saved in the fog client configuration file to point to the production network interface on the fog server. You could do this via a fog snapin too.
2. Run a split horizon DNS where you might register fog.domain.com on the build network to point to the fog server interface on the build network and then on the production network register fog.domain.com to point to the business network interface on the fog server. To do this, when you install the fog client you will define fog.domain.com instead of the IP address of the fog server.

The fog client speaks to the FOG server over the http protocol. The http web server does bind to both network interfaces so it will work as long as you can tell the fog client how to get there.

@ckasdf said in USB Boot UEFI client into FOG menu (easy way):

I understand that PXE requires drivers built into the computer’s firmware, which aren’t available for generic USB > Ethernet adapters. Is it possible to create the USB-booting PXE launcher, with a driver for a particular adapter wrapped into it?

On UEFI systems if you use a usb ethernet adapter, that usb ethernet adapter must be supported by the uefi firmware or the uefi firmware won’t see the usb ethernet adapter. This is why you can’t use any random/generic network adapter.

Now if you can boot another OS beyond the uefi firmware that OS needs its own network drivers. In the case of what you are mentioning here, iPXE is in itself its own OS. So any network driver that iPXE has a driver for it will use. The same applies a bit later on in the FOS booting process, FOS (linux) needs to have the network driver built in to be able to access the network. SO as long as you have an ethernet network adapter supported by both iPXE and FOS then you are good to go. Its not necessary for UEFI to support that network adapter. Most mainstream usb ethernet adapters are supported by iPXE as well as FOG linux.

I have seen people take one of those mini usb hubs and install a usb stick (like sandisk fit) and usb ethernet adapter and image that way. They just move the usb hub between computers.

The only other gotcha that you need to think about is usb3 network ports (blue jacks). iPXE as well as FOG needs to have drivers for the usb3 ports. They are more common now but there was a time where some of the usb3 controllers were unique and linux drivers were not available.

After all that rambling, yes you can use iPXE and FOS to get aroound not having built in uefi support for network booting.

@pdit what I want you to do is manually register this E73 host with the fog server. Then schedule a capture/deploy (don’t care) but before you hit the schedule task button, tick the debug checkbox then schedule the task.

PXE boot the target computer. After a few enter key presses you will be dropped to a linux command prompt.

1. Key in ip addr show. Look to see if the target computer has an IP address. If not record the name of the ethernet adapter (like eth0 or eno33, or what ever) go to the next step.

2. Key in /sbin/udhcpc -i $iface --now were $iface is the name of the ethernet adapter found in step one. Does this now pickup an IP address. If not then go to step 3

3. Key in lspci -nn |grep -i net and post the results here.

@jhalbert So its still not seeing the nvme disk? What do you get if you run grep nvme /var/log/messages ?

Is this m.2 nvme that is installed in the slot on the mobo, or is there an expansion card in a PCI slot used?

As for images, 1MB should be ok as long as its in a jpg format. Otherwise upload the picture to pastebin or a google drive/dropbox, share it public and post the link here.

There is a couple of things that could be the problem/solution.

First, while its not a problem here, ensure that secure boot is disabled

In regards to raid.
In fog configuration -> fog settings click on the expand all button. Search for kernel args and add in mdraid=true. Save the settings.

What this does it tells FOS linux to enable the raid management drivers in the kernel. If you are using the built in, intel rapid store raid you will need this kernel arg enabled. The intel raid, is a hardware assisted software raid. To linux it will present both the physical drives as well as the logical array. Since you are not seeing the nvme disks, this is probably not your current issue but there is no harm to have this feature enabled.

What I want you to do next is manually register this 3420 and schedule a capture or a deploy (doesn’t matter) but before you schedule the task tick the debug check box then schedule the task. Next power up the target computer but hit F12 a couple of times as soon as you see the dell logo, we want the boot menu to appear so we can do the next test. When the boot menu appears select from the bios menu (not uefi) network boot (if no bios boot options go into the firmware settings and enable legacy roms then reboot). We want to pxe boot the target computer in bios (legacy) mode. There is a known issue with Dell computers with the disk controller set to Raid-On and uefi mode. By booting in bios (legacy) mode we will be able to bypass this known issue.

When booting in debug mode you should see several screens of text that can be cleared by pressing the enter key. After pressing enter a few times you will be dropped to a linux command prompt. At the linux command prompt I want you to key in
lsblk and post the results here. This will show us the disks (block devices) that linux sees in this computer. You can either key in what you see here or take a clear picture of the output of that command with a mobile phone and post it here.

Once we know what we see in bios mode we can guide you to the next steps.

FWIW I imaged a Dell Precision 3630 last week (with sata drives) with the disks in a raid configuration and I had to switch to bios mode for imaging but the windows image and final firmware settings are uefi. Meaning you can image a uefi computer just fine in bios (legacy) mode even if the final operating mode is uefi.

@processor Its something you can do, but I don’t remember the exact file to change. Its a simple change, but if you make the wrong one its not good. That is why I sent a note to the devs.

@kafluke So unless I’m missing something you have 16 vCPUs allocated to the FOG vm with 12 cores in the host system? Yeah, I’d drop that back to 2 vCPUs with 8GB of ram to start with. Over provisioning the VM is counter productive.

4 x CPU Sockets
4 x CPU Cores
8 GB RAM

And really the FOG server doesn’t do much for imaging. It just moves the image from disk to the network adapter. There is no calculations done on the fog server, the target computer does all of the real work. Much more than 2 cores is a bit of a waste unless you have a lot of client computers checking into the fog server, then I’d probably go to 4 vCPUs.

@processor said in Wrong Image Size indicated in the image manager.:

list item there any way make FOG not detect them as reserved?

Lets start by removing this one from the list. The word “reserved” is a special word. If you look at the drive with windows running in the computer management applet. Does that partition say “Reserved”. If it label say OS or something else then we can remove the “reserved” line from your issue. Then its down to FOG treating the first partition as unsizable.

is there any way for this image to be compliant with FOG?

Its just not the matter of making it compliant with FOG, it’s not Microsoft best practices compliant. We probably can make fog do what we want, but you will have issues in the future with Microsoft upgrades. So the question is do you make it right now or latter. It really isn’t a fog question.

@Developers if its the first partition thing, can we just mark the image as resizable in the image config files?

@Junkhacker said in Wrong Image Size indicated in the image manager.:

single partition setups since NT

FWIW: I believe NT and Win2000 use the same kernel. But I could be wrong there too, that was almost 20 years ago you know.

@Junkhacker Right, but windows 10 should never do that. I’m not even sure I can make it create just one big partition. I know bitlocker as well as uefi system’s can’t boot from that disk structure.

My intuition is telling me to start over and do it right because this structure will bite you in the backside in the future like with a feature upgrade.

@neiliob1973 As for licensing when you build your golden image you use your VLK key (mak or kms) and then put the activation command into your setupcomplete.cmd file so its called just after winsetup is completed or if the fog client is installed the fog client can activate the computer for you.

Just for clarity Windows 10 Pro OEM EULA does not support reimaging. Meaning you are only allowed to install Windows OEM from the original OEM media and not construct a golden image based on Win10 OEM then redeploy it using any method. This is against the MS EULA. You can get past this issue by purchasing 1 Windows 10 Pro volume license seat to get you access to deploy a reasonable amount of Win10 Pro seats in your organizational as long as the Windows OEM version is the same (Win10Pro OEM -> Win10Pro VLK). You can not use this method to do a version upgrade (Win10Home OEM -> Win10Pro VLK). For this method you will need to purchase 1 seat for every computer you do a version upgrade on.

@processor While I see it, I don’t believe it. I’ve never seen a windows install with just a single partition (after Windows NT). Is there another disk in the system because the boot partition is missing or this is a strange MBR disk.
The fact that there is only one partition may be confusing FOG’s logic because the first partition of a windows disk is always fixed in size. How did you create this disk layout?

@tripleh said in How to create a fog iPXE menu entry that deploys a specific image?:

params
param mac0 ${net0/mac}
param arch ${arch}
param qihost 1

FWIW: This information is not necessary in your ipxe menu since these are iPXE parameters and not something FOS uses.

Can you explain having 2 drives in the computer? Was your image captured in multiple disk mode or single disk where you want to select which disk to deploy to?

@neiliob1973 Understand the unattend.xml and sysprep have nothing to do with FOG. This is a MS Windows thing.

The unattend.xml script goes in c:\windows\panther directory. Another recommendation I can make is to use an online unattend.xml generator to get you started with the configuration. Just don’t include any private information in the generator. This way you can see the structure of the file. http://www.windowsafg.com/

@kafluke said in FOG slow to image when on VM:

I can copy an image from the old physical server over to the VM at the OS level (centos) using SSH with no bottleneck whatsoever (Full 1Gbs)

How about in the other direction new fog server to old fog server? That is actually the direction the image will be traveling during deployment.

Also the other thought is that the old fog server to new fog server is probably happening on the same network switch, whereas going to a target computer would probably be switch to switch communication.

@kafluke said in FOG slow to image when on VM:

4 x CPU Sockets
4 x CPU Cores
8 GB RAM

Just to be clear this is the physical vm host machine info right? 8GB of ram is super low.

Also how is the esxi box connected to your network?

@kafluke I’m pretty sure its not FOG that is the bottle neck here, but more your virtualization infrastructure you have in place. Remember a virtualization environment is shared, where a physical server is typically dedicated to the service.

Tell use about the virtualization host.
How many cores (not hyperthreads, but real cores)
How much memory
How is the disk subsystem designed (raid level + number of disks)
How does the host interface with the network infrastructure? (1GbE, 1GbEx2, 10GbE, ?)
How many other VMs run on this vm host?
How many vCPUs do you have dedicated to the FOG server?
How much ram do you have dedicated to the FOG server?

I can tell you that FOG running as a VM with 2 vCPU 3GB of ram on a 28 core server ,with a Raid 10 array, and (2) 10GbE interfaces to the network. I can push a unicast image out to current tech desktop at 13.4 GB/min (according to Partclone)

@tripleh As much as I don’t like this route this method is also possible if the Deploy image route (preferred) doesn’t fit your need.

Here is the kernel parameters you can key in to a custom fog iPXE menu. You will need to decode what your desired image has and substitute in these parameters.

kernel bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 web=http://${fog-ip}/fog/ consoleblank=0 rootfstype=ext4 mac= ftp=${fog-ip} storage=${fog-ip}:/images/ storageip=${fog-ip} irqpoll chkdsk=0 capone=1 type=down img=Dell3630Base imgType=n imgPartitionType=all imgid=39 osid=9 imgFormat=5 
imgfetch init.xz

The image unique parameters that must be changed are below and where to get them from in the web ui.

img=Dell3630Base
imgType=n
imgPartitionType=all
osid=9
imgFormat=5

imgid=39

@tripleh There isn’t an easy way, but see if this route will work.

On the iPXE menu there is an option to Deploy Image. In this option it lets you select any one of a list of images on the fog server you can deploy. Out of the box it works this way. But there is an option to only display the image that is registered to that computer. So instead of a list of images displayed, FOG will only display the image associated with the host.
Will that work?

We can address (bypass) the password issue in a bit.

@processor said in Wrong Image Size indicated in the image manager.:

I can tell you there is no sda2, only sda1

There is only one partition on that disk? This is a windows computer right? If there is no sda2 then just run the other commands, that will give us a better picture of your disk layout.