Posts made by george1421

@wayne-workman Ideally that would be the best solution. Practically it would be pretty tough to program because some times the dhcp server and pxe client do different things. There is not a clear cut way to pxe boot. Sometimes the dhcp server will reply with the next server in the header, and the boot file in dhcp option 67 instead of the boot file in the header. Yes you could code for that, with a skilled tech you can look at the pcap file and understand what is going on pretty quickly even with the variations. I know that we do get a lot of tickets over pxe booting not specifically related to FOG, but more about the environment the FOG Admin is trying to pxe boot in.

I guess in the end I don’t know if it would be a useful tool or not.

@taspharel Well to fully understand what is going on using the fog server or wireshark you can capture the dhcp pxe booting process: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

The above works best if you have the fog server, pxe client and dhcp server on the same subnet. I would put your dhcp policy back in place as they are listed in the wiki. I’d be interested in what the client is sending in the dhcp discover packet as well as the response from the dhcp server.

If you are not familiar with reviewing a pcap file, upload it to a google drive and post the link here or send me an IM and I will look it over.

@zingaro TBH I have never tried in uefi mode.

As for your note: if these are dell computers, when in uefi mode you need to enable the uefi network stack (on the network page) in the firmware. I assume other OS will have similar options. On the boot options, it will only show valid uefi boot sources so you do need to enable the uefi network stack for that option to show up.

Your MDT boot image should contain the uefi boot kernel. In my case we use VMWare and boot our target computers directly from the mdt iso in uefi mode. They boot without an issue, but again I’m not sending the iso image across the network with pxe.

I can confirm uefi booting via pxe works with these instructions tomorrow since I’m out of the office today for training.

@tywyn In your PS script, add a text literal to the computer name (to just change it slightly as a test) when you create the user account. See if that works. That test will give you an idea if the computer name and user name can be the same.

Right now you need to basically take the approach of divide and concur. (find out where the problem isn’t so you can narrow down where it is).

If you run this PS script outside of the context of a snapin (i.e. run it locally on the target computer by hand) does it run correctly? Right now we need to isolate the issue. Is it a FOG Snapin issue vs a PS script issue.

@ntalbert If your fog server, dhcp server and pxe booting client are on the same subnet please try to do this: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

I suspect you have a second dhcp server or proxy dhcp server on your network issuing IP addresses. Upload the pcap file to a google drive and post the link here or IM either Sebastian or myself and we will take a look at it.

The confusing bit is that according to the picture iPXE is getting to the target computer some how, and then getting the wrong IP address when it requeries for the next server. As well as why is it using tftp to get default.ipxe? At this point it should be using http. Are you trying to boot a virtual box vm in the pictures? Virtual box uses iPXE as its boot roms. One last bit, I’ve seen many home routers send its IP address out as a next server for some reason and the ip address of 192.168.1.1 makes me thing someone might have plugged in a home internet router into your network as a rouge device.

@jim-graczyk There is not currently an option for that, but (in my limited experience it might be trivial to include that feature). The developers might include a new setting in FOG Settings->Login Settings to allow the FOG admin to change their login landing page. If you look in the url the only difference between the dashboard and any other page is just the node reference.

But then might raise the question, if not the dashboard, then what should be the default landing page? And might that landing page be different on a per user bases? (just thinking of reasons why we might not want this feature). Either way, I would surely make a feature request out of this idea. I fell it does have a moderate amount of merit.

@csa It would be interesting to see what FOG is telling iPXE when this freeze happens. With a browser what output does this command give you? http://10.10.34.98/fog/service/ipxe/boot.php?mac=00:1e:c9:7a:36:48

Post the results here, please. Quite frankly the image shows a normal boot, what we don’t see is the rest of the ipxe commands that are being executed.

@Sebastian-Roth

'kernel ${boot-url}${path}/images/pxeboot/vmlinuz

Is this impacted by the http / https issue that also impacted the usb booting of FOS? I agree the code looks good and the boot-url variable was the only thing that jumped out at me.

Do you happen to have any custom iPXE menus because you should not see that command/response normally from FOG.

@weaponode There are ways to debug a failed unattend.xml file install. Its not easy but can be done. There are log files created when oobe runs, if something in the unattend.xml file causes oobe to stop that will be logged in these files. Getting to these files is a bit of a trick, but FOG can help us there too.

First before I get going here, make sure your unattend.xml file in only in c:\windows\panther directory and not in the sysprep directory.

actually now that I think about it, I had a similar discussion a few days ago about the same topic: https://forums.fogproject.org/topic/10861/error-when-capturing-image/16

The idea is you can pxe boot into FOG debug console, connect to the windows “C:” drive and the vi linux command prompt view the contents of these error logs. It may be just as easy to pop the hard drive out of the failed computer and add it as a second hard drive on another computer and then view the log files that way. But if OOBE stops, it should be logged in one of the error log files. It will tell you what went wrong.

Please understand that persistent groups are not part of FOG. This “hack” called persistent groups is intended to give the appearance of real persistent groups. This document describes how to use it: https://forums.fogproject.org/topic/8836/basic-persistent-groups-and-1-3-0rc16 Read the entire thread not all of my posts are adjacent to each other because of the way the fog forums work. There is more info at the bottom of the thread.

The developers took the hard part out of adding the concept of persistent groups to FOG by wrapping the hard stuff inside a plugin.

I can speak for dban (it should work). I do have to give the caveat here. You are doing things (i.e. pxe booting third party applications) using fog, that fog was not designed to do. Can it be done with fog, probably. Just understand it should not reflect bad on fog, just because it doesn’t work the way you think it should. I’m not suggesting you are saying anything to that matter. I just want to remind people that might find this thread later of the fact.

As I said I can’t speak for deban, but I do have a tutorial on how to pxe boot into windows 7 setup (I might suspect that it will work for other MS Window’s OS too, but haven’t tried). https://forums.fogproject.org/topic/7765/pxe-booting-into-ms-windows-7-setup

If you want to pxe boot into a WinPE environment there is some info here: https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog

@msi Replication management happens on the master node. Also realize that replication manager continues to poll remote storage nodes to see if anything has changed. This is done by quickly creating a md5 hash of a bit of the file to create a fingerprint that is compared against the master node’s copy.

It would be interesting to see if you stopped the replicator service, if the network bandwidth pattern you posted changes over time.

@msi how many fog clients on your network?

Also understand that a GbE network has a theoretical max of 125Mb/s. Six Mb/s is almost background noise.

I’m not seeing the error in that post.

I would inspect this file /opt/fog/log/fogreplicator…transfer.NJED45.log to see if there is anything wrong with the specific replication element. This log entry (posted above) just says that fog is in the process of replicating the /images/dev/postinitscripts directory.

@msi Also, fog inventory pulls motherboard asset tag from target device when inventory is run. So if you by design assign an asset tag to the hardware in the firmware FOG will see it.

I’ve done work with ZPL before and its not hard to setup a label, its just interfacing it with FOG and getting the label to the printer is the issue. Can a plugin be developed for FOG to take one of the fiends and create a zpl formatted label? Yes. The issue is still getting the fog output to the physical printer. Then what happens if someone doesn’t want to use a zebra printer, but a datamax or intermec instead?? All of the zpl programming is of no good on an intermec printer.

@rabus The client communicates with the server over http for command and control functions and then NFS and FTP during imaging .

The client uses http and tftp during pxe booting process.

I feel there are some undisclosed meaning in your questions. If you were clearer with what you need, we may be able to provide a better quality answer for you.

@robtitian16 Tutorial most appropriately names: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Post the pcap to a google drive/dropbox/etc and then share the link, either in a forum or IM me the link and that will tell us what is going on. It really helps to have the fog server, dhcp server, and pxe booting client on the same vlan to see the entire conversation. If that’s not possible, you can use wireshark on a notebook on the same vlan as the pxe target computer to capture at least the dhcp process. That is where the process is failing.

What would you expect in this barcode?

We use a barcode scanner when registering systems with FOG. Our machine names are a composite of country, location, hardware type, dell asstag. For example US,NYC,D,<asset_tag> would be a desktop in New York, USA. So on a poster in our build up room we have a poster with the prefixes for the location with 3 bar codes on it. One is for the laptops, one for tablets, and one for desktops for that location. On the Dell units they all have a bar code on them with the asset tag.

Our workflow is to use the full registration, when we get to the computer name, we “zap” the barcode for the device type on the poster and then “zap” the Dell bar code compter’s chassis.

Now in regards to barcodes themselves. You can create your own barcode stickers pretty easy if you need just uppercase letters, numbers, and limited punctuation by using a code 3 or 9 (code 39) bar code. https://en.wikipedia.org/wiki/Code_39

The first step is to install a code 39 font. They have both code 39 and 39 extended available free for windows computers, just google for it. Use either Excel or MS Word and make a label sheet. Key in what you want on the bar code sticker using the bar code font. With code 39 the only thing special you need to do is include a start and stop character around the text you want to scan. For example lets say you want the characters 123 on your label, you need to key in * 123 * “<star>123<star>” note: there shouldn't be a space between the star and the text. I had to do that here because the star means something special to the forum editor into Excel or MS Word. If you use a bar code font you should see the bar code on the screen. I have been able in the past to actually scan the bar code directly from laptop screen for testing. You just need to get the angle right and the screens need to be a matte stile not shinny.

The last bit of this is you can either print to a laser printer for your bar code stickers, or use a bar code printer driver like from seagull scientific to print directly to a bar code printer.