Posts made by need2

Do backup. Please. Just always do backups before you do such things.

Always been more of a Netgear guy myself… what models are the Ciscos?

Yep, I just recently did a Fog deploy to ~30 machines our organization was getting rid of and giving to the public. I made a hardware independent XP image and pushed it to those machines all in one go, and it took a while for me too. I had an old 3COM 10/100 switch with all of them plugged into it. I knew I had taken that switch offline for a reason lol. Later when I had another machine that I needed to add to the group I imaged it alone, and the speed was much higher. My guess is there is a combination of what the switch can actually throughput and the switch’s onboard memory. Now I know this isn’t too much of a thing for switches, but later I sent another image operation through a newer 10/100 switch and it went even faster (differences in host hardware aside).

So clearly we should always have the fastest switches we can afford in our network’s backbone, and only allow for a 10/100 (if we have to) if it is only supporting a couple of workstations. But I wonder if there are any other specifics we can pick up on such as brand, model series, or other specifications that tend to choke Fog up?

It will be best if you can back up your images, groups, and host lists, then do a complete uninstall. From what I’ve seen even if you get an ‘upgrade’ install to work from 0.32 to 0.33 at this stage, it will be a mess and have a lot of leftovers. After you install 0.33 you should be able to port your images back in, and import your lists. You will also have to recreate your PXE menu. Perhaps before 0.33 goes release Tom will add a built in upgrade, but considering how different the new system is, it might be better for everyone to only grab what they need themselves.

And as for your OS, it should still work, but I would strongly urge your to use a newer release if at all possible.

Unless you are manually copying over the new files and updating the settings files yourself, rerunning the installer will be your best bet. Elliot had the foresight to make the installer script detect an existing installation and attempt to update it. I have only had a couple of issues with this, and it was most likely the faults of dependencies like Clam.

I never like to be this guy, but the search function in the forum and the wiki on the main site are both your friend in this. And Google.

If you are wanting a production (useful for doing work) server, I would highly recommend using 0.32 . While the 0.33 branch is getting more and more awesome, there are things that can be breaky when the dev is still neck deep in rewrites. If you are wanting to play around with beta stuff and test for future production, then read the patch notes and see what revisions make a difference for you.

At the moment the furthest a UEFI Network boot seems to get is downloading the NBP file. Afterwards the screen goes black and dumps back to the boot medium select (assuming you prompted to select boot device).

Hello

I am glad to see that FOG is making progress towards full support of UEFI booting options. At the moment, a default install still does not seem to properly support a UEFI network boot however. If there are others out there who have made progress on implementing a UEFI network boot, I would love to hear from you. UEFI is quickly taking over our domain, and I want to be able to use FOG to its full potential.

You don’t happen to have an official Github repo do you?

I ran into issues when first attempting to test FOG on my network because my Windows WDS server was still running. WDS is the service that Windows Server uses to serve PXE responses. If you do not want to remove the role from the server yet (in case you need to use it again soon), then you can go into Services and change WDSServer (Windows Deployment Services Server) to Disabled. That will stop the Windows server from responding to PXE requests, which is what is happening now. When you have two PXE servers on the network, even if only one is declared in the DHCP, they can be stuck in a ‘quick draw’ situation, where the first one to respond gets to fulfill the request.

North Bend, OR

[quote=“Tom Elliott, post: 22181, member: 7271”]need2,

If you want help, let me know.[/quote]

I may take you up on that in the near future. Involving FOG in my department’s three year plan, and I need to have full UEFI support. Long story short I would love to start experimenting with the 0.33 branch and UEFI. I’ve got other projects I need to finish first though.

I personally have not yet gotten FOG working in a UEFI environment, so I would definitely say disable UEFI if you are having troubles. Not to step on Tom’s toes… do the 'fdisk" thing too.

I know this is not an answer but it really is ideal to have VOIP phones and their server on at least a different VLAN, if not an entirely separated network.

I have heard a few cases of the Lenovos causing problems with all partition imaging. Something with their diag/restore partition. Those are your bane when it comes to unified imaging.

I have been running FOG in a number of test cases for our organization, and training myself in it preparing for what looks like will be a complete refactoring in how we handle OS deployment. I have been very happy with the options and usability that FOG has offered. But I have noticed that with the newer kernel (3.13.1), when a computer is uploading and image it appears to be a bit sluggish on the network transfer. I end up seeing the kernel fill the RAM cache with the image, then have to pause while the network transfers the information. Maybe its just that the newer kernel is that much more optimized on the drive imaging and caching side that the network just can’t keep up. But around that time I also moved the FOG server to more robust hardware (from a Dell Vostro 420 to a Dell PowerEdge 2900). I am still doing what I consider baby steps with Linux, so I was wanting some community input on what I could do to track where any of my performance bottlenecks would be. Drive Array R/W Speed? Motherboard bandwidth? RAM limitations? CPU load? Network Ux/Tx? Unoptimized software or kernels?

Obviously there are a lot of variables there, so any and all recommendations on what you all use to check out the speed of the various parts of your Linux servers would be appreciated.

A little background on my current rig:
Dell PowerEdge 2900
2x Intel Xeon E5205 @1.86GHz
4 GB RAM
BIOS 2.50.00
Storage Controller - PERC 6/i
Firmware 6.3.3.0002
OS Array: RAID1 2x250GB 7.2K RPM WRITE-BACK ADAPTIVE-READ-AHEAD
Image Storage Array: RAID10 4x1TB 7.2K RPM WRITE-TRU ADAPTIVE-READ-AHEAD
2x Gigabit Ethernet Controllers

OS: Debian 7.3 x32 (fully updated).
All known proprietary kernels installed.
No other softwares installed other than FOG.
No other storage nodes in use or set up yet.
No modifications made to OS or FOG other than those critical to Debian 7.3 FOG install.

I am also curious about the hardware this Windows 7 is running on. I know a couple of Dell installs have given me headaches due to their weird diagnostics partitions.

What FOG version and kernel are you using?

I will give it a shot once I can take that system down again. No screenshots since this is on baremetal, but I will take a photo and transcribe.