Another unable to move /images/dev problem
-
Hi to all!
I am attempting to upload a Windows 7 image from an HP Z230 to my FOG server 0.32. On upload we are getting the[SIZE=3] “unable to move /images/dev/macaddress to /images/name-of-image” [/SIZE]problem seen before. I did the chown -R fog.root /images and chmod -R 777 /images and are still getting the problem. looking at the /images/dev folder I see the folder of the MAC of the PC being used to create teh image. inside it is a d1.mbr file. In /images there is no folder created for the name of the image file that should be created.
Any ideas?
-
okay so it seems to be failing when it wants to move the files over to the /images folder, you can do so manually by making a folder in the /images folder equal to what you set in the Image Store as the image name. BUT FIRST lets check the size of the files in the /images/dev/MAC folder and tell me how large the files are.
to SOLVE the issue… Make sure your server fog user password is set and that that password is what’s set in Storage Management Password and in FOG Settings->FOG_TFTP_FTP_PASSWORD
What kind of a machine are you imaging (make and model)
Is this a new fog server or was it working in the past and recently stopped working?
Was this model a new purchase this year?
Can you try another test client (different model and type hopefully to rule out hardware issues)?
-
The server has been working with no problems for a couple months now. This is a new PC model for us that we are trying to create an image for. It is an HP Z230.
The size of the file in the folder name the same as the MAC is 4.0K in file d1.mbr
The fog passwords DO match between the FOG_TFTP_FTP_PASSWORD and the storage management password
-
I have more or less the same problem on Dell Optiplex GX620…
It did one week I work on ! -
Then I recommend checking the BIOS to make sure all settings are correct, use legacy settings, UEFI is currently not supported and others have had trouble with the advanced format drives, but some have been able to image them, please take a look here on the forums for further trouble shooting.
An option you may consider is trying Tom’s kernel set up as it has helped others get some unruley hardware cooperating, but I believe the problem you are experiencing is from the 4K advanced drives. If the folder is only a few KB, it did NOT save properly and should NOT be used as an image.
If you can use FOG to image other machines that you use to be able to image, the problem is not at the server it’s at the new hardware.
-
Due to a lack of a solution here is it safe to assume that FOG will not be able to image these new common hardware types until POSSIBLY a new revision? I know there are a lot of FOG users out there who are now looking for another solution if FOG will not work. I hate to say it but I am having to use a G#### Boot disk to image machines again. This is a sad day for those of us who have enjoyed using FOG to image whole labs from our offices.
-
Eric, have you tried FOG 0.33b?
While I realise it’s, technically, a beta it does support gpt disks natively.
Windows 8 may not be perfect, but you can now upload/deploy windows 8, just remember to repair the disk or ensure that secure boot is disabled before either and then reenable it after.
-
I have not tried the beta. Where do i acquire this version?
-
svn co [url]https://svn.code.sf.net/p/freeghost/code/trunk[/url]
or download from my website:
-
I shall try it.
-
Sorry to hear about the complications with the drives. Tom is working hard to try to include the newer hardware in the latest revision. I agree with Tom, if you would like to see how FOG is progressing download the 0.33b revision.
I have used it to image a few test machines with the GPT format, it’s not a perfect solution yet, but hey maybe you can help us find the snags and resolves for them!
-
I was able to update the server but it did create chaos. As soon as the server came online, it tried to update all of the clients in some way and because my DHCP lines are not changed in the Cisco switches we use for DHCP, all of the client PC’s were stuck in a loop of rebooting to get the client update. I had to pull the plug on the server to stop this. OOPS!Is there a way in the FOG configuration to allow me to determine when the clients get updated?
-
Please explain what you mean by “the client gets updated”? I don’t exactly know what you mean. FOG doesn’t dole out “updates”, it doles out images you assign to the Hosts. Are you referring to FOG trying to image the machines after the task is complete?
-
I think he means the “FOG Client” on the work stations. There are “updates” due to it. You should be able to just, either globally or on the hosts, disable the “Client Updater” service.
-
As soon as I upgraded our FOG server to the beta, when the clients checked in, the server told them to reboot for some reason. I did not have the undionly.kpxe line in my DHCP server yet so my clients rebooted and went back into windows and then as soon as the FOG Client timeout came, they checked in with the server and the server told them to reboot again.
-
As of now, I am disabling FOG Service on the client PC’s so that they are not checking in. I hope to plug the server back into the network later today so I can work with a controlled number of PC’s. I don’t have the luxury of a non production environment so i will just take all the clients off the server for now.
-
I set up a virtual environment for testing. In my router, I set the boot file to undionly.kpxe. When I boot form the network, I get a new-looking FOG boot menu, but when I choose to do a full register or a quick register, the machine says there is no operating system and reboots. I know there is no operating system on the hard drive, but if I can’t register the machine, how can I image the machine.
-
[quote=“Eric V. Baker, post: 22998, member: 22214”]Hi to all!
I am attempting to upload a Windows 7 image from an HP Z230 to my FOG server 0.32. On upload we are getting the[SIZE=3] “unable to move /images/dev/macaddress to /images/name-of-image” [/SIZE]problem seen before. I did the chown -R fog.root /images and chmod -R 777 /images and are still getting the problem. looking at the /images/dev folder I see the folder of the MAC of the PC being used to create teh image. inside it is a d1.mbr file. In /images there is no folder created for the name of the image file that should be created.
Any ideas?[/quote]
Has this ever been resolved or should I just move on to clonezilla? I mean really, I have followed all the recommendations, I have manually logged into ftp server as fog and have not an an issue. BUT every time I try and pull an image it cannot move from /images/dev to /images… and If I move the image to where it is supposed to be and try and pull it I get a quick GFY and in debug you find fog unable to mount the nfs share. I have totally reinstalled fog to no avail, I installed the 33b version and that cannot even boot PXE on the machines… so anyone have a clue or do I just move onRIck
-
I am equally frustrated. Right now I have a deployment of HP Z230’s coming in in probably less than a month and no deployment solution. I am probably going to have to go to each machine and image with a #$%^& boot disk and image by hand and also manually rename and add to the domain like I had to do back in the dark ages.
-
Look,
I can only try what I know, but as I’m not in either of your environments, I can’t tell you what’s wrong. I need to know details.
Eric, your issue appears (to me) to be with not finding the /init.xz and /bzImage files. When you installed 0.33b did you install fresh or perform an upgrade? If you upgraded, you’ll need to change the init.xz and bzImage lines in FOG Settings to say only init.xz and bzImage respectively as my guess is you upgraded.
Rick,
While I understand the frustration, I’d recommend taking a look at your options 66,67 lines and verify they’re pointing in the proper locations. The biggest change that you should need is instead of looking for pxelinux.0 change it to undionly.kpxe.Thank you,
