Posts made by george1421

(default placeholder)

(default placeholder)

Why do you need this you may ask?

I can think of two/three situations where you may not be possible to PXE boot computers into the FOG PXE menu.

1. The computer is so old or has a really broken PXE boot loader
2. Some third party manages your DHCP server or the DHCP server you use doesn’t have the ability to set dhcp options 66 and 67
3. Your build in network device (or USB dongle) doesn’t support PXE booting.

The process steps are not hard at all. You will need to acquire these things.

1. A 2GB (min) flash drive
2. A pxe boot image from https://rom-o-matic.eu/
3. Win32 Disk Imager from sourceforge http://sourceforge.net/projects/win32diskimager/

I do have to add this caveat, in that the rom-o-matic servers include the most of the common network drivers. They may not have every possible driver built into this kernel. If you know how to build kernels you may have to download the ipxe source code and build a custom kernel with the specific drivers for your application. In general this method will work for most applications

One time actions for this process

1. Download and install the Win32 Disk Imager.

Image creation Process

1. From a browser access the rom-o-matic web site at https://rom-o-matic.eu/
2. Ensure that “Standard, for most common use” is selected (default)
3. Set the “Choose an output format” to “USB Keychain disk image (.usb)”
4. Set the “Embedded script” to (in the past your script section).
   Be sure to change the ip address of **192.168.1.88** to the actual IP address of your FOG server.

#!ipxe

dhcp
set next-server 192.168.1.88
set filename undionly.kpxe
chain tftp://${next-server}/${filename}

5. Set “Which Revision” to “Master” (default)
6. Press the Proceed button at the bottom of the page. It may take up to 2 minutes to build this kernel depending on how busy the rom-o-matic servers are at the time you submit your request.
7. When your kernel build is done the system should prompt you to download the “ipxe.usb” file. Go ahead and download that file to a known location.

(continued below)

The only issue I can see for dnsmasq is that the fog server is not on a subnet by itself. From what I think I understand the fog server is on the same network as the clients and the dhcp settings are coming from a remote location. Unless I’m off on this you can not run dnsmasq and dhcp-relay for the same subnet since both will respond to the dhcp request

@Wayne-Workman I though you would know of a wiki for that.

Just off the top of your head, do you know of a wiki that talks about pxe booting from usb flash. I know how to do it for uefi, but not bios. If not I can work on a process tomorrow.

@bacelo said:

@george1421 and the thing that bugs me more is that they have this working in other schools. They say that they don’t have a firewall. And I don’t think that they will let me manege the dhcp

Are they unable to update the dhcp settings for you? All they need to do is to change dhcp settings 66 to point to the ip address of your fog server and dhcp option 67 to point to the boot file. That is all the action they need to do for your dhcp scope. Nothing else needs to be managed.

Unfortunately, if your DHCP IP addresses are coming from this cisco device you are at the mercy of the owner of that dhcp server. No configuration that you can do with fog will help since the cisco dhcp server tells the client what to do next. Now if you want to pxe boot from a usb flash drive then you can regain some level of control and not need to make any dhcp server setting changes, but this will also require a special boot drive any time you want to boot into the pxe menu.

The other option is to shut off the dhcp relay between the network where the FOG server is and this other network, Then you will need to ensure that fog is setup to issue IP addresses for your local network. I see this as being a risky step because now FOG will supply all IP addresses for your side of the firewall.

@Atech Thank you for the feedback. So the ultimate solution was to update to the latest trunk version.

If that is accurate and the issue is resolved, can I mark this issue resolved?

@Matthew-Bostdorff If you have time to test this. See if removing the FOG client, reboot, do the in place upgrade, reinstall client resolves the issue. Also if you could sanitize and post that log file that jbob mentioned that will help trying to diagnose the issue. But the days of that old client are numbered. As soon as FOG 1.3.0 is stabilized, I’d recommend that you update so you can take advantage of the new client.

@Matthew-Bostdorff Thanks for the clarification and the additional info.

Just so I understand. If you had the RTM release in place and then fog client installed, then you did the in place upgrade to v1511 the FOG client stops responding to FOG tasks. But if you install RTM clean, install v1511 then install fog client everything works as expected.

If that is the case it sounds like the in place upgrade is stepping all over the fog client (I won’t go into how I think MS made a mistake with these in place upgrades). One thing that comes to mind is that the firewall settings has been reset blocking communication or the dlls the fog client registers to are no longer valid after v1511 is installed. BTW, did I mention how this new MS process is going to bite.

I wonder if @Jbob can give a little insight to what the 1.2.0 stable fog client hooks into when it installs. We need to drive a solution here because you are only the first one to come across this issue. More will follow.

@Tom-Elliott The new client was under my suggestion.

If I understand the OP he was running fog 1.2.0 stable with the client at that time. Something through windows update has now broken the older client. I asked what version of the client the OP was using because I knew the client was just updated, but not aware that it wasn’t backwards compatible to 1.2.0 stable. My mistake.

Is this issue solved? I see the thread is marked solved, but I don’t see a clear solution for you.

What version of the fog client are you using?

And for clarity, are you having an issue with the first release of windows 10 or is it the new release from November (v1511)?

I don’t have an answer for you on your problem, right now just trying to collect some additional details.

I know that they just updated the fog client to 0.9.8 or 0.9.9 to address several issues.

@Tom-Elliott You know I’ve been using the trunk version for so long I forgot all about the default file size limitation/setting in php. When I did the import / export test on the 1.2.0 instance I spun up so I could help with 1.2.0 questions. I downloaded, deleted a host reference and uploaded the saved copy and the host came back. But this system only has 2 images and 5 hosts. So the exported database wasn’t very big at all. If the OP has many systems or images I could see how it might reject the import as you stated. Good catch, I think you are spot on.

@Wayne-Workman said:

For me - a 6TB drive is awful cheap, and I can update an existing image before lunch. We have 22 images, one or two for each model. Keeping an image per model is simple to me, and deployment is more simple for both myself and co-workers. We can afford the drive-space and we have the time to make images.

See the key/trick to this is that there is only one or two images for all systems. I don’t have to keep track of what the target computer is, because there is only one image. In our case we release a new golden image every quarter with all of the latest windows and application updates. If you have 22 images that would be almost impossible to do. In my situation I can tell you that a Dell 790 or 9020 have the same image on it as a e7404 or e7550 (sans the model specific driver). If there is an issue impacting a 790 I’m almost assured that it will impact all models, so I fix it one, I fix it for all (in theory).

@Wayne-Workman said:

This thread has given me the idea to create a migration article. We already have an article for changing the IP address of a FOG Server (in the works). In my opinion, that should just be a sub-section. There should be another section in the same article that talks about moving images and other data over to another server.

The one thing you have to be aware of when you migrate, you have to have the same version of FOG on both sides of the migration. For example if you try to migrate from 1.2.0 stable to 1.2.0 stable, you are pretty assured that the data will migrate without issue. But if you try to migrate from 0.32 to 1.2.0 the migration will fail without question. The same holds true if you try to migrate from 1.2.0 stable to 1.2.0 trunk 5676. (understand this is only used to prove a point). The database has changed quite a bit from 1.2.0 to any one of the trunk builds.

In the case of the OP, I think we need to look into why the database is not exporting and importing as expected. Something is not right here. At the very least we can use the process outlined by Arrowhead-IT to migrate the data. But I have a strong belief that this should be done from within the GUI to keep people out of the underlying OS whenever possible.

This is very, very strange everything should come across except for the physical media. I guess we need to check the apache error log. If you were on rhel it would be /var/log/httpd/error_log. Try the data import and then right away tail the error log and see if the import threw a silent error.

@JDnoble18 said:

@jmeyer What do you mean by remaking images on GUI? Doesn’t import/export take care of this? I’ve already got the images copied over from the old server to the new one, do you suggest deleting the images folder and starting over?

OK, just a second here. You did the export using the FOG configuration right. It should have downloaded a config file (fog_backup.sql) right? Of so open that with notepad++ and look at it. You will see database drops and creates, but there should also be insert into lines. This is placing your data back into the new FOG server. The images and snapin files are different but you should be able to copy the database no problem.

… Just thinking. I wonder if you need to restart the fog service so that it sees the updated data? I’m not sure how much fog caches in memory.

One thing we found is that the default compression for image capture and deploy on the older versions of FOG is level 9 (high compression) Under 1.2.0 (trunk build) is 6 (faster decompression but larger image size on FOG disk).

I did tweak the fog boot menu for fog 1.2.0. My tweak added the pxe menu entry but selecting the quick image just causes the pxe menu to reboot. So no joy for my hacking skills.

2-3 GB/s is not bad, I think I’m getting in the 3GB/s (maybe 4GB/s) for a virtualized server. So what you have today is not bad.

From a performance wise there is not a lot you can do, since the fog server it self is not that busy during OS deployment. It is just moving data between the disk array and the network adapter. Having multiple spindles (disks) on your FOG storage array will help to speed up the disk part of the operation. Using SSD drives for the image and snapin storage would be better, if you wanted to use spinning disk for the OS. The client is doing the heavy processing by decompressing the target image as it is put onto disk. Having a fast disk subsystem and a fast network (LAG group if you will be imaging more than one at a time) .

BUT if you will image more than one machine at a time and they are all the same OS you can use multicasting and upgrade 25 machines at once, only consuming the network bandwidth of deploying 1 unicast image. Moving to 1.2.0 opens new doors for you.