Posts made by Haz

Hi all,

I promised an update with our new Precision T3500 server, however I’m experiencing a few little niggles that have distracted me from the overall performance of the server so far, and I’m hoping somebody here can shed some light on them.

These queries are now completely different to the original post title, so please let me know if you would like me to create a new topic.

The first thing I have come across which is rather strange, is that a Full Host Registration and Inventory will not create a deploy task when asked to. So I type in the Host name, and the image ID I want assoiating with the host, I skip all other parts by hitting enter as they don’t apply to us, and then when asked if I want to deploy now I hit “y” and then enter the username and password. I notice it saying, “Done, with imaging”, and it also says
“Attempting to register host…
Host already registered as %Host name I just specified%”. (I’m not sure if it always says this or not even when working normally)
It definitely hasn’t already been registered, I even cleared all the hosts off the server and tried again. This also happens when trying the Quick Host Registration and Inventory (Yes, I have ticked the box to autopopulate and selected a default image on the Web UI).
The only way I can get a host to image is by selecting the “Deploy Now” function on the PXE boot menu. This is of course a very quick and useful way of deploying an image to a machine, however the inventory report is extremley useful to us in cases of future technical support issues with that machine.
Does anybody know what could be causing this? It worked fine on the Optiplex 380 server I mentioned previously on this thread, and I am extremely confident I have set up the Precision identically.

The second issue prevents us from doing a memtest on the host machine. It has only happened on 2 or 3 laptops so far (all of them HP), and one of them was eventually able to boot memtest after a BIOS reset.
I have provided a picture of the screen with the error message on below -

Does this make sense to anyone?

Mod Note: This topic has been forked from here:
https://forums.fogproject.org/topic/9039/very-slow-unicast-deploy-when-imaging-2-or-more-machines

@george1421 said in Very slow unicast deploy when imaging 2 or more machines:

Was the image recorded with FOG 1.2.0 or newer or is this an old 0.3x image?

The image I have been using for these tests was captured using the new 1.3.0. I was thinking of transferring our old images to the new server, however I didn’t have much faith in it actually working or at best there would be issues somewhere down the line so I just captured from fresh.
Using an SSD was discussed, and I noticed an old thread here where somebody was thinking about using one, but I don’t think the results were actually shared. Now that you have clarified this for me I believe I will be going down the SSD route. Thanks.

@Wayne-Workman said in Very slow unicast deploy when imaging 2 or more machines:

That speed is not transfer rate, it’s write rate, the speed at which partclone is writing to disk.

Thanks for confirming this. I was getting rather confused after the server was continuing to display this speed after you stated it was not possible!

@Wayne-Workman said in Very slow unicast deploy when imaging 2 or more machines:

I’d recommend you limit your max clients to 2 or 3

That is a good idea. It will be a much better option for hosts to simply wait in line so that they can image at full speed rather than pull the rest of the hosts down. Considering the vast speed increase of 1.3.0 on just 1 or 2 hosts, this will be just as fast, if not faster than our old method on 0.32 anyway.

Many thanks to all of you for your input and suggestions, great help as usual.
Keep up the good work!

Harrison

Thank you again for the replies.

@Tom-Elliott said in Very slow unicast deploy when imaging 2 or more machines:

I’m assuming you’re using “Partimage” for the images then?

As far as I can remember, it is Partimage. I am out of the office now and will not be back until tomorrow (UK time) so will confirm it then. It is just the default imaging software that came with my installation (I installed FOG 1.2 from scratch and then used git pull to update to the latest version). If it does turn out to be this, would somebody be able to point me towards some instructions on how to install it to work with FOG?

@george1421 said in Very slow unicast deploy when imaging 2 or more machines:

I’m still thinking it could be that single sata disk that is causing a problem.

I am also starting to think the same thing. I’ll get the model number for you tomorrow but I can tell you it’s a 160GB Western Digital. Sometimes the performance on these drive can be pretty horrible, and simply running the WD Drive Utilities on the HDD in question can work wonders for drive performance - even when the drive is completely unreadable.

Yes, unit 2 does slowly increase in speed after unit one has finished imaging. Very slowly.

Just to add some confusion to this matter, I am actually going to be building a brand new FOG server for when we move premises in a weeks time. The current one was just a test run really, and wanted to try and iron out any potential problems before we get into our new office. I’ll be using a Precision T3500 with at least 1x Xeon processor in and I’m pretty sure the board is SATA3 too. I’ll be very mindful of the HDD I choose this time around…

I’ll obviously update everyone on progress of the current server and will let you know how the Precision compares once it is built.

Thank you both for your replies, your input on this is very appreciated on this.
So I think maybe I should have done a little more testing on this before posting my original question, as Wayne has suggested.

I have found that these speed issues only occur when “staggering” deployments on multiple machines. Let me explain from the start -

I have tested deploy of a Windows 7 multiple partition non resizeable image to an Optiplex 780 SFF on all deploy stations that we have, just to eliminate a possible faulty Ethernet cable. All stations were fine with speeds hovering around 5.5GB/m - 6GB/m. Also, no pesky 100Mbps switches anywhere on the network - all are 1000Mbps.
I then used 2 identical machines to the one above and used station 1 and 2 to deploy the same image to each machine, one at a time. All results fine, same as the above.
I then imaged them both at the same time on the same stations. While the initial start speed was slightly slower (3.6Gb/m) they eventually got back up to speed by the time the second partition was deploying, topping around 6.3GB/m.
I then added a 3rd machine to station 3, all same specs, same image etc. Again, slightly slow start to begin with but gradually gathering speed up to about 4.7GB/m in the end.

I repeated the process above with all 3 machines, however I “staggered” the deploy task to give around 1 minute between each one before the deploy starts.
This is where the speed issues began.
The first started normally around 6GB/m, but when the second machine started roughly 1 minute later, it was getting no more than 500MB/m for the first 15 minutes of deploying. The third machine started a minute after again, with no more than 350MB/m for the WHOLE deploy.

You both may be thinking this is a rather strange method of imaging and using FOG, but that is just how our routine has always been; air compressor in the machine to remove all dirt/dust, fit the required RAM, HDD, add-in cards etc for the customers requirements, begin image through FOG, then onto the next machine. Rinse and repeat. So by the time you have built the next system and want to image it, the first system is only around half way through its deploy.

I am not sure if FOG was designed to meet requirements of this nature, It’s just odd that our old 0.32 version could handle this routine quite happily.

Now, onto the FOG server specs -
Optiplex 380 SFF
Intel Core 2 Duo E7500 2.93Ghz
6GB RAM
I’m pretty sure it’s SATA2 on that board (correct me if I’m wrong)
I’m not running VM, it’s dedicated.

The old 0.32 server is an ancient Dell Precision 470 workstation, and I’m pretty sure this would have been SATA2 as well, if not lower.

@george1421 said in Very slow unicast deploy when imaging 2 or more machines:

Also how much free RAM does the FOG server have when its fully running (top) will give you an idea here.

I’m not sure how to check this, and I think you may have tried giving me a link here to find out but it hasn’t displayed properly?

Thanks again for your input so far on this.

Server

• FOG Version: 1.3.0-RC-25
• OS: Ubuntu 16.04 LTS

We have recently upgraded our Fog server to the latest version 1.3.0 (previously running 0.32 on Ubuntu 12.04! Old I know, but it worked fine for what we needed) and I am experiencing extremely slow deploy speeds when I image more than 1 machine at a time (between 300MB/M and 800MB/M). I understand that if I add the hosts to a group and assign a Multicast task to the group, then the speeds will be much better, but this doesn’t really tie in well with how we work, and separate unicast deploys on our old Fog server used to work fine with no bottlenecking.

I am just wondering - is this normal? A few factors I suspect could be affecting this:

• Could it be something to do with my current Kernel? I am using the default one at the moment, but maybe somebody knows of a different Kernel which copes better with a few unicast deploys at roughly the same time?

• The image it is affecting most currently is a Windows 7 build with a bit of extra software, and also a recovery partition; so the image type is a "Single disk, multiple partition (non resizeable). It is quite an old image now (around 20GB), and was captured from a deploy from our old Fog server. Perhaps the image is a bit messy and needs re-building?

• Could it be related to the image compression option when initially creating the image? This is a completely new feature to me, so I have been leaving it at the default “6”. Space is not really an issue with our new Fog server, so if I need to pull this value down to “1”, it wouldn’t be a problem.

When the new server was first set and working, I tested a Windows 10 image capture and deploy (the main reason I upgraded to Fog 1.3.0 is for the Windows 10 support as it is becoming much more popular with our customers now) and I was blown away with how quick it was! The capture speed was hovering around 6GB/M and when it was deploying it was topping around 9GB/M. The 10GB Windows 10 image was deployed in 1 minute 12 seconds - that’s crazy fast compared to the old server!

Any ideas or suggestions on this would be greatly appreciated.

I would just like to send a big thank you to @Jaymes-Driver @Tom-Elliott for a previous discussion on setting up DNSMASQ on an (very) old thread. Although I never got around to setting it up 100% on the old server, I am happy to say it’s working perfectly on my new server. I revisited the old thread a few times recently, and with your guidance and suggestions I was able to get it going. Many thanks once again!

Well I promised an update so here it is.

Unfortunately after following your precise instructions and steps from the wiki you linked me, it is still giving me the same grief

I think it’s time to give up trying to fix this issue and just do a reinstall.

Many thanks to you both for your time and help, it is much appreciated!

Kind regards
Harrison

Hi Jaymes, thanks for the info.

I did have a look at DNSMASQ last night when researching into what Tom had said on his previous post. Time was getting on a bit, and just reading the word DHCP was making my eyes ache so I gave up in the end. I got as far as installing DNSMASQ through the terminal and creating the ltsp.conf file, but was having difficulty getting the ltsp.conf file in the correct directory due to the permissions on Ubuntu (I have managed to successfully do this kind of thing before in Ubuntu, but time was taking its toll on me and I was starting to get restless whilst trying to figure out/remember the sudo command to do this).

I am currently at work, and life experience is telling me not to touch the work Fog server yet until I have sorted my home server out and am confident in doing it. I’ll have another look at mine tonight and update you on how I get on.

Thank you both for your time patience with me

Hi Tom,

Thank you again for your response. Your advice is very appreciated but unfortunately my network skills/knowledge have hit a brick wall, and although I have read into what you have suggested I still can’t seem to get my head around it
Setting my main DHCP server (which is my router) to know where to get the PXE boot files, I imagine is either logging into my router and doing something in there, or using Ubuntu to tell my router where to look for the PXE boot files (presumably the Fog server IP address).

I may not be making much sense here so how about this -

If I back up my image files now and decide to upgrade to a more up to date Fog version, can I choose “no” for the DHCP server on Fog, and my main DHCP will be configured automatically? (I have a feeling this is wishful thinking).

Am I right in thinking it’s better to go for an earlier version than 1.2.0. as this is still a “work in progress”?

Many thanks

Hi Tom,

Thank you for the sudo command, you were very close too! I found that you had to add “-server” to the end of it, so in full it was -

sudo apt-get remove --purge isc-dhcp-server dhcp3-server

This seems to have done something, as my Fog server at home never used to be able to get internet access and now it works!
The only issue now, is that when I try to PXE boot a machine I get the “no boot filename not received” error. I get the feeling that Fog is still trying to use it’s own DHCP server which is now not there anymore, so it is timing out and giving that error message.

I could be completely wrong though…

Thanks again for your reply Tom,

Looking back at it now, it does seem pretty obvious about the DHCP server and that I should have selected “no” during the installation. This is what you get for blindly following a tutorial without concentrating fully on what it was asking me to do.

OK, so my solution for this would have been to backup my image files and format/reinstall the Fog server and selecting “no” to the DHCP during the install, but you mention uninstalling the DHCP server instead. How would I go about doing this? Can I do it though the Fog dashboard interface, or will I have to go through the Ubuntu Terminal using sudo commands etc?

I am most appreciative of your time and information so far Tom, so if I have just opened up a can of worms asking how to uninstall Fogs DHCP please just tell me and I will just go through format/reinstall route instead - I honestly don’t mind.

Thanks again

Hi Tom, thank you for your quick response

Yes, the tutorial that I followed did say to install the DHCP server with Fog. I did wonder whether it was to do with this too, but seeing as it has only started affecting our work network after roughly 1 year of it being installed I was slightly confused.
So, this might be a silly question -

If I reinstall Fog now and select “no” during the installation when it asks about the DHCP server, will I have to manually put one in for hosts when doing the “Full Host Registration and Inventory”, or will it just be allocated one from our router instead?

Thanks again

Just recently, our Fog server has started to interfere with the internet connection on our work network. We are running Fog 0.32 on Ubuntu 12.04. I also have a Fog server at home which has had this problem since day one, but assumed it had something to do with my awful Virgin SuperHub DHCP conflicting with Fog. But now it has started happening at work and I really need to get to the bottom of it.
As soon as Fog is switched on, various devices on the same network will begin to have “Internet Connectivity Issues” (Wired + Wireless), and when I switch Fog off, they all eventually regain internet access again.

I am by no means a Fog/Ubuntu expert. I have edited my PXE boot menu a bit, and I know my way around the Fog directory to change the Kernal when facing stubborn systems. The only way I have ever installed Fog is by following strict instructions from a forum or video tutorial. Without this I would be absolutely lost in Ubuntu.

Is it time for me to upgrade to a later version of Fog? Does anybody know what the cause of this might be?

Please let me know if I need to provide any further information.

Thanks in advance

Old thread I know but hoping someone can help me here.

I have edited the PXE boot menu before a few times (all thanks to this guide - thanks a lot ssx ;)) and never had a problem, however on this latest fog server I have set up I cannot seem to get it to work. I can edit the default file fine to display the menu options and also dropped the ISO files into the correct directory, but when ever I select one of them from the menu it only gets so far and then just says “loading boot sector… booting…”. It would appear that fog has found the iso and started to load it, but a problem lies somewhere else maybe? I have tried a few different memdisk versions, and this still happens on various ISOs such as Ultimate boot CD, Dell Diags, WinPE tools etc…

Any ideas on this would be greatly appreciated

OK, so the lack of response on this thread leads me to believe there is nobody else out there that is having this problem and nobody who has a clue how to fix it. However, this problem still persists for me but I have had a bit of a break-through today (!) and thought I would share it with the community on the off chance that it’ll be useful to somebody one day, and if not that then just for bragging rights!
So I had another biggish order to process today (10 machines) and they were all Dell GX620s, PDs, 2GB and Win 7 Pro. I set up the fist machine, registered it on Fog and renamed the Host to “Gems 1”. (I always rename the Host name from the mac address to a reference of the customer) Selected the image I wanted to deploy and clicked update. Decided to do a quick image as I will probably just use this one machine to load all of the HDDs for the order so I didn’t create a task for it. Selected Quick Image from the PXE boot menu and I got an error saying “Quick Image Failed… Invalid Host Information”. So went back onto Fog Management and created a task for it instead. I get the DREADED HASH AGAIN! :mad:

Getting a bit fed up of this now I went back to the host information on Fog Management and decided to tweak it a little. First thing I did was rename the host from “Gems 1” to “Gems0”. Then I deleted all of the “Host Description” (Usually Fog will put in the date and time the host was created by default) so it was completely blank. Then in the Host Kernel, I pointed it to an old Kernel that we used on an old Fog server that never had this problem (Kitchen Sink 2.6.31.1) and finally in Host Arguments I typed in “nomodeset”.
Now, the last two things I mentioned (Alternative Kernel and nomodeset) I have tried many times before and it got me nowhere but I thought I’d try them with the other things I did just for good measure. Clicked update on the Host, killed the previous task for it and then created another one. PXE booted the machine and it imaged fine!!

YES!!!

Now I’m not completely sure which variable actually did the trick but it worked. It could have been the name change, deleting the Host Description, or it could have been a combination of the whole lot. The next time I get this problem with a machine though I will try one method at a time and try to figure out what is actually causing this.

Will post as soon as I get answers!

Anybody have any ideas on this at all? I was thinking of running the latest Ubuntu updates, but can anyone confirm that they are all stable with the latest version of FOG? (I tried updating an earlier version of Ubuntu with an earlier version of FOG before and it stopped working :/)

Thanks

Hi everyone

This is my first post here so apologies for my n00bness. I am quite new to FOG and Ubuntu. Also, I am sorry if this topic has already been covered in another thread that I have failed to notice - please just point me in the right direction.

I have recently upgraded my FOG server to Ubuntu 12.04 and the latest FOG version 0.32. I finally got everything working after a lot of troubleshooting but I keep getting a problem which seems to only occur randomly. I can register hosts fine, upload images fine etc, but every so often I will get a machine that it will just not deploy an image to.
I will PXE boot the machine and everything will seem to go fine, but after “booting the kernel” I will just get a “#” and it will hang then do nothing. I have tried using multiple kernels to no avail. The strange thing is that it will work on an identical machine with the same hardware. For example, I am currently loading 10 x HP DC530 SFF. All of them imaging fine until I get to number 5 and it’s just hanging there with a “#” just before the blue deploy screen. I have had this happen with a Dell 745, 755 and also a D600 laptop now and I just can’t figure out what the problem is. I have been using Google and can’t seem to find anyone with this problem, and anyone who has a slightly similar problem I will follow instructions with no joy.
It is not a hard drive error, as I can pull the HDD out and image it on another HP D530 and it works fine - it just seems to be machine specific. It could well be some settings is the BIOS, which I have tried to troubleshoot myself but I am now reaching out for help.

Sorry if there is some information I have failed to supply. Please let me know and I will do my best
Thanks in advance