Right,

Thats what I remember and have experienced with groups. But in this case those AD settings are not being applied to the hosts.

I will work on a video for you.

@Wayne-Workman

I have no need to set any host individually, they all need to join the same domain. Other than checking or unchecking ‘join domain’ box.

Would you like me to gather a video or some screen shots?

Thanks replying @Wayne-Workman
Some background on me, I have been dabbling with 1.3.0 as you guys have been working on for the last year.

1 . Yep, got it, thats where I am setting the correct passwords. Took me a little clicking around to realize the new client was using a AD password yet.
2. yep, got it.
3. yep, used it many times.
4. Ok, so your saying that no matter what the host fields have in them it will just use the defaults from the Fog Settings page? Previously it would autofill these ‘placeholders’ in so that you know it was set.
5. This, make sense, as each time I clear fields on a host and then check the box and watch the autofill, the new AD password changes its encrypted form. Default=6da1956736 HostField1=64a7977 HostField2=d0506078 (All truncated for security)
6. I have experienced this issue around the site, I am aware of it the issues and use the private/incognito modes when needed.

I am only checking in the web interface, however I did just install phpMyAdmin and checked the newly registered host(at bottom) and that shows the same as the web interface.
My work flow is this:
Make a group with All the hosts.
Goto the ‘All’ group I just created
Goto the AD page of the group
Check the Join Domain box
I see today its pulling everything from the defaults.
It auto-filled, the domain, domain username, and both new AD password (different again) and the legacy
Hit update
Page refreshes in about 1 second and says Group Info updated at the top of the page
Goto any host
Goto the AD settings page for said host
see that the box is checked to join, domain is there, domain username is wrong, its ‘fog’ and should have either been ‘fogadd’ or now ‘fogjoin’ (never used the username fog, this was changed when i updated from 1.2.0)
The new AD password field has the old legacy password in it (daa5c) which was used with the ‘fogadd’ account
the legacy password field is blank. This password is NOT set anywhere on the defaults page.

If I look at a host I registered and uploaded an image from on the new version 7498, this is what I see on that hosts AD settings page:
join box is not checked
all other boxes are blank

Hopefully this helps, there is 1700+ hosts on here so maybe there is too many to update all at once?

Having some issues with the latest (7498). I noticed that after upgrading from 1.2.0 that for every host it changed the AD join username from what I had set to “fog” thus breaking every clients domain join function.

So I thought I would create a group of ALL hosts like I have done in the past and update the AD info for them, however when check the box it autofills everything like it should but the New Fog Client password appears to be different that what is set in the Fog Settings page defaults. So I paste in the clear text password for it and hit update, says it updated all the clients. Am I wrong to update with the cleartext password? (my theory being that encrypting the already encrypted password)

But if I go look at any of the clients, nothing got updated.

Then under each host, if I clear everything out and hit the check box to autofill it only fills in the legacy client password.
EDIT: appears, that it only does this for some hosts, a newly registered one works the same as the group autofill above.

Thanks for your thoughts

@Wayne-Workman I just finished the successful image of Win10 to the Venue. Trying the quick image now… Seems like it works now… random fluke? I tried removing the device from the dock and putting it back on and reconnecting the network cable and it still gave me that error, which then cause me to google the error and get to this page. Then I tried killing the task and using the GUI to make the task. But seems like its working fine now. the only thing different is the OS drive had Win8.1 on prior and now it has Win10, and both times I am imaging Win10.

I have the same issue, however I am imaging a Dell Venue 11 (7130). I had been testing imaging and now was just testing Win10. I started the task from the ‘quick image’ screen and that was causing this error. I cancelled it and started it from the FOG GUI then it is now going fine.

Well its seems were both right (sort of) I reverted the server via snapshot back to 1.2.0 and it deploys fine to the 80.3% errors then it performs the after imaging tasks, such as change host name/resize FS/clear task. So its probably been corrupt for awhile but have never noticed it, since it works fine.
It appears the trunk fog just errors out and then stops everything and reboots.

EDIT: I did try pushing a different image to the same PC and that worked fine.

Thanks for the help and sorry about wasting everyone’s time.

On an off topic, how well is the legacy client going to work with the trunk fog? Is best to just plan to upgrade the client at the same time as the server?

Same spot and same error on another computer. Seems odd considering I just used this image on 1.2.0 about a month ago, and the server it runs on is a virtual machine and there isn’t any errors on the RAID array.

I will try and deploy a different image to see what happens…

I havent tested another computer, but i did run the task a couple of times and it failed at the same spot each time. I will go test another computer, they are Dell Optiplex 990s with a SSD in them.

Updated to the latest trunk version and tried pushing out an existing know good image. It gets to 80% and dies. I think this is the part where its done copying data and would expand the partition with blank data. I came from 1.2.0 and server is Centos 6.7.
Fog version is 6096

I canceled the task and the computer boots up fine, but the OS partition size is not the full 223gb. This is odd, because Windows Disk Management says its 223GB (which is correct and what it should be) but My Computer shows the drive as being 53.3GB.

On a side note it appears the legacy client wont do domain join anymore so will probably have push off updating until summer so we can update to the new fog client when we update images.

Screen shot here

Thoughts?

For anyone that is following this thread, this issue has been resolved and should be included in the 1.3.0 release.

[quote=“Tom Elliott, post: 36348, member: 7271”]If the smallest size the image can be (windows 7 defaults base install sysprepped and all is 8.9GB) is larger than the disk you’re trying to put the image on, it will not work.

If you resize the partition before FOG get’s to resize it, the partition is marked that it’s already shrunk and fog Cannot do anything with it. So let’s say you make a partition size of 40GB as the shrunken state, and you try putting the image on an exactly the same size, in 1.2.0 I made the partition size to 99% of the full size of the partition, so you’d end up with around a 39GB partition which is smaller than 40GB and the image would not deploy. I have since found and corrected this issue in SVN. That said, with the release of 1.0.0 we went with partclone as your primary upload method. We are still supporting partimage for legacy compatibility reasons. If you’d be willing you can send me your gmail address in a pm and I’ll see if I can help fix the image for you.

Hopefully this helps you out too. If you’re willing, try out SVN and see if your image starts working. There’s always a chance it won’t work and you’re left in a state no different than you currently are. However, there’s also the chance that this may help you out. You’ll also get to see some of the work we’ve been putting forward for 1.3.0 or whatever it’s labeled when we release.[/quote]

PM Sent

Well, I tried to resize the partition before uploading to a small size and then try deploying it, still didnt work.

Is it possible that the issue is that the computer the image came from has a larger hard drive then the destination computer? I thought the single partition option was supposed to support this, pending that your image isnt larger than the disk. This is in thought to the original problem.

[quote=“Junkhacker, post: 36178, member: 21583”]did you set the format to partimage on the image profile?[/quote]

Yes I did, forgot to mention that in the post before. I did this on the production server I pushed from

[quote=“Tom Elliott, post: 36144, member: 7271”]This sounds like an issue with the image and the partition layouts.

Your partition layout on the “new” system’s hard drives is different than what is expected.

When you created the “resize” image, how did you resize the original disk?[/quote]

Not 100% sure I follow, but here is what i did.

Deploy image to working 740 from production server. ( single part/single disk image)
switch over to my new .32 server
register the host
upload as single disk/single part
copy image to production server
switch back to production server
schedule image deploy from new file (i did chmod on the permissions for the file so it matches the rest in the /images directory)
didnt work, tried debug and thats where the image came from.

Do you have any thoughts on the original post?
in my testing it seems that no matter the kernel or bios version it can always see the network and the hard drive, it appears to be directly an issue with partclone.

Should pull the hard drive from a not working machine and try to image that drive in a working machine?

Thanks,

For those wonder what error i get trying to use PartImage. Here is a screen shot.[IMG]http://ruppnet.net/fog740partimg.jpg[/IMG]

As a temp patch by I am going to upload the image to a .32 server and move it to my production server as a partimage image. This should work. Will post back if doesnt.

EDIT
Didnt work, really thought this should have. Going to have to run 2 fog servers while i push the images back out to the problem computers.

would be really nice if i could upload using PartImage on fog 1+.

[quote=“cadyfish, post: 35349, member: 24458”]When you said

Are they the same model and image?
Also are they the same hardware (including hdd size/manufacturer) & bios wise?
Did you do anything different with them?[/quote]

Yes, the image is the same for both machines, they are both Optiplex 740s, one might be slightly different as far as CPU or something.

BIOS on the one that worked was like 2.1.9 and i updated the other from 1.1.something to 2.2.7(newest).

EDIT: Not sure on the hard drives, I think they are the same size, shouldnt matter my image is like 15gb and the drives are atleast 60gb in size, the image is set to single part/single disk in fog.

I have been reimaging them with FOG for years, had no issues until now. I will try and do more testing today.

EDITS
It seems the machine that works was built in 2009 vs the one that don’t work was in 2007.
updated bios from 2.2.7 on non working to 2.1.9 still no luck.

Well I thought I would try to upload it using the PartImage imager, but according to Tom on the forums they have it forced to use PartClone, which is a bummer, I think it would be nice to be able to switch between imagers, however PartClone seems to be much better. So needless to say that this didn’t work and I am out of ideas.

Anyone have any suggestions?

I have some 740s that wont deploy using a single disk image of XP however some other ones in the lab deploy just fine.
Server is on 1.2.0 for version.

I have tried different kernels on them and updating the BIOS to the newest.
FOG sees the disk and network fine, the issue is with partclone.

EDIT: on the 520 i also tried doing a normal disk wipe and letting it run for a couple minutes to for sure wipe out any MBR that is there.

The closest thing i have found to this issue was this:
[url]http://fogproject.org/forum/threads/latest-fog-0-33b.6476/page-42#post-22521[/url]

despite what this post says it happens every time.

I took a video of a Download-Debug process on a 520 that i saw the issue on.
[URL=‘http://www.ruppnet.net/fog520.mp4’]Video Here[/URL]