Posts made by neodawg

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]

Thanks for the info, using that I found this and updated php on the Fedora 10 box that was getting the white screen.
I then ran the installer script, which finished correctly now and then I was able to update the fog DB just fine.

[url]http://www.sohailriaz.com/how-to-update-php-on-servers-centosfedorarhel/[/url]

thanks for the help Tom

I am getting this error while downloading a kernel from the kernel update page. I want to set a custom filename to test certain computer model with this, i dont want to overwrite the default one. This is the error.

[code]
[SIZE=16px][FONT=Ubuntu][COLOR=#ff0000]FOGFTP: Failed to rename file. Remote Path: /var/www/html/fog/service/ipxe/backup/bzImage1055x6420140520_160535, Local Path: /var/www/html/fog/service/ipxe/bzImage1055x64, Error: ftp_rename(): RNFR command failed.[/COLOR][/FONT][/SIZE][/code]

If i dont set a custom name it works fine.
[code][SIZE=16px][FONT=Ubuntu][COLOR=#008000]Your new FOG kernel has been installed![/COLOR][/FONT][/SIZE][/code]

[COLOR=#000000][SIZE=16px][FONT=Ubuntu]if this was already posted, sorry, I searched but didnt find anything directly related to this issue.[/FONT][/SIZE][/COLOR]

Fedora 12 server
PHP 5.3.3

[COLOR=#000000][SIZE=16px][FONT=Ubuntu]Thanks,[/FONT][/SIZE][/COLOR]

[quote=“Tom Elliott, post: 27412, member: 7271”]What version of PHP do you have?[/quote]

[code][root@fog ~]# php --version
PHP 5.2.9 (cli) (built: Apr 17 2009 03:29:12)
Copyright 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright 1998-2009 Zend Technologies
[/code]

EDIT:
was just test updating a Fedora 14 server and got the same thing:
[code]

• Starting FOG Multicast Management Server…Failed!
  [root@fogwin bin]# uname -r
  2.6.35.14-106.fc14.x86_64
  [root@fogwin bin]# php -version
  PHP 5.3.8 (cli) (built: Sep 28 2011 17:34:42)
  Copyright 1997-2011 The PHP Group
  Zend Engine v2.3.0, Copyright 1998-2011 Zend Technologies
  [/code]

I dont get a white screen, and am able to upgrade the database and it appears to work fine so far. Just thought I would share