1. About 1000
   2 & 3. I’m at a school. Day to day only 1 at a time when needed. In the Summer when we reimage all our student PC’s, as many as it can handle in one go. I have had between 30-120 on the go at the same time but using the slots of 10. During this time we just wait, so to speed this up is my goal.
2. On one of our newest laptops it can get to around 9GB/min
3. About 35-50 GB
4. It’s an old PC with a single HDD

My theory was that if I could double the network bandwidth with bonding I could get some faster deploy times which would result in less waiting around. I tried many times with Ubuntu but haven’t had any success yet.

@george1421

I’m just looking at maximum throughput, that is all, to speed up imaging overall when imaging many clients. Thanks

@george1421

I asked the question here in case Fog worked better or worst with a particular set-up. I’ve run Fog on Ubuntu for years but I’ve read somewhere that it runs better on Cent OS, so it was to find someone who could say with confidence this combination will work rather than me trying different things. I tried bonding in Ubuntu but all it did was to slow it down further. I tried all the different bonding types. Some failed to work at all.

I’ve tried this with Ubuntu various times and can’t get it to work properly and I’ve also read and it can be tricky to get working with this OS. Has anyone got a tried and tested way that works well even if it is with another OS? Can I also mix onboard with PCI cards or is it better to use 2 PC’s the same. Any advice would be great rather than me guessing.

Many thanks

I think you’re taking me a bit too literally, when I say folder structure, I mean the effect of a folder structure. For example in fog you can create a group and then associate hosts with it. The hosts are relevent to that group. So in theory you can do the same with images and collect them under one relevent name, for example “windows 10”. Even if you had just one level of groups or folders, call it what you like, it would aid organisation when you’ve got 30 plus images.

Ok, don’t worry I can see you’re trying to lean me away from the idea. I just thought this would be a much tidier and logical layout for the images list. Searching is fine if you know what you want to type to get to the result. If you’re not sure, it would be easier to navigate through logical folders.

Server

• FOG Version:
• OS:

Client

• Service Version:
• OS:

Not sure if bug or not, I used to be on fog trunk before 1.3.0 was released. I used a couple of multicast session names a and b. After upgrade to 1.3.3 those session names seem to still be hanging around so had to use one called c. No big deal, but thought you might want to know.

I’ve got a lot of images now and it’s harder now to keep them organised, it would be great if I could name a few folders to organise my images better.

I wondered if this would improve deployment times. Has anyone tried it? Is it worth it

@Sebastian-Roth

Hi Sebastian, Yes, the file is only 8.5mb so can probably send as a attachment. I’m not sure how I private message you on here?

Success!

Thanks very much for your prompt responses and efforts which is better than some of the paid support I have to face on a day to day basis as a technician. I can now move all my use all my old images over to the fog trunk server.

@Sebastian-Roth

Ok, rechecking with debug mode it doesn’t look like there is any specific error message as I thought using FOG trunk and an old 0.32 image. Here is the screenshot any way. Not sure it tells you much

“Important information we need is the OS ID configured for the old” image on the new FOG trunk server!”

OS ID on the new server is “Windows 7 (5)” just like it was on 0.32 & 1.2.0

“As well I need to ask you to deploy that image via your old 0.32 or 1.2.0 FOG server so the client can boot properly. Then schedule a debug (capture or deploy does not matter) task on that client and run fdisk -l /dev/sda when you get to the shell. Please take a picture as we need the exact numbers (no typos allowed! ;-)”

See below, hopefully it will help:

@Sebastian-Roth said in Getting "disk read errors have occurred" after image completion on Fog trunk v7198:

@Zourous Would you please be so kind and upload a picture of the error on screen or at least post the exact error message here in the forum.

This is the message (replica grabbed from the internet) and happens straight after the first reboot from the image completing. I think there might have been a message at the end of the image process before the reboot, but I missed it due to a distraction at work. If I get a chance I’ll try an image again and see it I can catch the message at the end on my camera.

@Wayne-Workman said in Getting "disk read errors have occurred" after image completion on Fog trunk v7198:

@Zourous I think these are partimage type images, instead of the newer format partclone.
FOG 1.2.0 and FOG Trunk support partimage but I think you have to tell it to use partimage for that image - or maybe even for the whole server, not sure. Asking @Sebastian-Roth or @Tom-Elliott to clarify.

Just to reiterate, I have set the old 0.32 images to “partimage” instead of “partclone” in the image properties. I’ve tried a brand new image upload and download in Fog trunk and this worked fine, it just doesn’t seem to like my old images at the moment.This means I’ve got a separate server build on 0.32 so I can just restore old images. Trouble is I also need to play with W10 so appreciate the new stuff in the trunk version.

“Can you list the contents of this particular image’s directory? The command should be something like this:
ls -laht /images/ImageNameGoesHere”

total 21G
drwxrwxr-x 2 build build 4.0K Jun 19 2015  .
drwxrwxrwx 5 root root   4.0K Apr 29 09:05 ..
-rw-rw-r-- 1 build build  21G Jun 19 2015  sys.img.000
-rw-rw-r-- 1 build build 8.7M Jun 19 2015  rec.img.000

I tested one of my old backed up old 0.32 images back on Fog v0.32 and it imaged fine. Have just built a new fog server and now on v7356 and I’m back to the same issue again upon first boot after image deployment of “disk read errors have occrred”

@Sebastian-Roth

I would post a screenshot but there isn’t much to see. It’s a black screen with the error mentioned which also says " Ctrl alt delete to restart". I’ve booted the PC with a windows PE Ian and both the boot partition and the windows partition are intact. It’s like it isn’t copying the MBR over or something. I’ve just rebuilt the whole server with the same build of fog, to get the same thing again. I copied the image file back from a backup I had before I moved off of v0.32. I feel like I’ve done something unique here as I can’t find anyone else with the same issue. Maybe I’ll try the newest build to see if this helps.

So I’m on Fog trunk version 7198 on a Ubuntu 14.04 LTS. I’ve recently upgraded from v1.2.0 which was recently before that upgraded from 0.32. Images were working fine on v1.2.0 upload and download. Now I’m trying to deploy on v7198 and am getting “disk read errors have occurred” directly on the first boot after the imaging process on 2 different “partimage” images at least. I have always use “single disk” resizeable and the images are set as this in v7198. If I try to switch to any other option the task errors out before starting so I’m sure this is all correct. Is there anything you need to do to the old 0.32 \ 1.2.0 images before you use them in v7198 other than pointing to them and setting them as “partimage”?