Hosts not imaging - HELP

[prestop]

@prestop
OK now I connect but get "unable to locate image file for Windows 7/8! (sys.img.000)
argh.

[prestop]

@prestop
Something else changed as well:
the one image that had a size listed for client disk now also says “0.00iB”

[Junkhacker]

are you deploying to a larger disk, or uploading a resizable image?

[prestop]

@Junkhacker I am downloading to a 250G disk.

[Tom Elliott]

@prestop What happens if you run:

service nfs-kernel-server restart and try again?

[prestop]

@Junkhacker I set the image to ‘single disk - resizable’

[prestop]

@Tom-Elliott
unrecognized service

[Wayne Workman]

@prestop This thread is several pages long… Forgive me for not reading it all. The commands Tom just posted are the ones for Ubuntu/Debian. Also - you can find all that stuff right here: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_NFS

[Junkhacker]

@prestop said in Hosts not imaging - HELP:

@prestop
Something else changed as well:
the one image that had a size listed for client disk now also says “0.00iB”

… you haven’t been mixing up the upload/download have you?
upload to server, download to host (this naming convention has been changed in trunk)
i’m just worried that you’ve uploaded blank images over your existing ones

[prestop]

@Junkhacker Yes, that occurred to me as well…but I have been very careful not to do that.
If that happened wouldn’t the image be 0.0iB on the server though? Mine has iB on the server, but the ‘size on client’ says 0.0iB.

[prestop]

@Junkhacker
If I have done that - is there a way to get those images back? Supposedly he was backing this server up but I don’t see where/how that was occurring.

[prestop]

@Junkhacker Also, one last thing: there never seems to be any real exchange between client and server. It whips by and then reboots - if it doesn’t give an error message.

[Junkhacker]

if it still has a size on server, you’re probably still good.
but if the images have been replaced with bad ones, the only way to get them back is recovering from a backup.
with fog 1.2.0 i think it was possible for fog to think that it had succeeded when it hadn’t and replace a good image with a bad one, detecting problems and dealing with them better has been greatly improved in trunk

[prestop]

@Junkhacker Perhaps I should be installing Trunk then. I take it this is the link you gave me earlier to try? Especially if it’s easier to troubleshhoot.
This is getting difficult - the room is across campus and has actual bugs in it.

[Junkhacker]

since you now have a backup of the server you can recover from, i can’t see any reason not to try the dev build (commonly referred to on the forums as “trunk”)

[prestop]

@Junkhacker Great- I’ll give it a shot. Will I need accompaniment or is it fairly straightforward (bearing in mind that my chops are not the greatest)?

[Wayne Workman]

@prestop

We have solid documentation and videos in this article: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

[prestop]

@Wayne-Workman
Awesome. I will give it a try tomorrow. I have a switch to configure…(in a bugless room).

Many thanks to all for your support.

[Sebastian Roth]

@prestop said in Hosts not imaging - HELP:

It whips by and then reboots - if it doesn’t give an error message

In FOG 1.2.0 this usually happens when there is some kind of “faulty” partition layout on the disk. The tool used to enumerate disks and partitions was/is not very tolerant and freaks out easily - not giving any partition information. As FOG relies on that information to loop through the given partitions it just “whips by” if it cannot find any. Try booting the client into debug mode (FOG 1.2.0 -> Host -> Basic tasks -> debug) and run fogpartinfo --list-parts /dev/sda

[prestop]

@Sebastian-Roth
Thanks, I’ll try that…but I did format the drive into one big part as requested, etc. and I still got the same response.
My issue is that I"m out of time and I wanted to try the later version to get working.