Another unable to move /images/dev problem
-
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,
-
Yes, i did an upgrade to an existing 0.32 server as this is the same as my production environment.
-
FOG 0.33b is not a direct drop in upgrade from 0.32.
It is recommended to do a full re-install when using FOG 0.33b as so much has changed that it doesn’t transpose well.
My recommendation is to put another hard drive in your machine and begin there, or if you are virtual, set up another server. Then migrate your images over.
-
This got me farther along. I will do some more testing this weekend.
-
A question that has come up here at work is since I am experimenting with the beta, how stable is it and when is the expected release date of a stable release?
-
Stability I’d say pretty near the same as 0.32, with more advanced stuff in 0.33b. I don’t know when the release is going to happen, but I know we’re planning for it relatively soon.
-
I would say the 0.33b is stable. Like Tom said, it is as stable as 0.32
HOWEVER… there are a lot of implementations going on. Tom is working to make the system leaner, and has already changed the cloning solution to SUPPORT uefi so we can make that transition. We are still working on the solid base of required features though so that we can begin to work on the luxuries.
I would say there isn’t really an expected time for a stable release, but I wouldn’t say that the Version of 0.33b is unstable either. Just definitely in the beta test stages. (Which is better than alpha test stage!!!)
-
[quote=“Tom Elliott, post: 24170, member: 7271”]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,[/quote]
Ok, I really did not understand exactly what you mean above, but I did remember reading about the [SIZE=2]undionly.kpxe change and I did not not that. I tried to work it out about four times and finally I just removed fog entirely (almost more about that ) and did a scratch install of 0.33b. I was able to PXE boot the clients but when I pulled the image it got stuck not being able to move it again, but this time it gave a reason (bad user name or password) and I realized I did not remove the fog users so I grabbed the new password out of the config.php and updated fog’s system passwd and worked [/SIZE]immediately[SIZE=2]. That was on a DD copy. I decided to go ahead and pull another image as single disk multi-partition no resize and that went through pretty quickly.[/SIZE]
[SIZE=2]Deployed the image and it worked right out of the gate. I will try doing a couple more but 0.33b certainly worked much better in every way including more information as to what was going on even in DD mode. There are a few errors running the 0.33b web interface but they seem like they are probably little things. For instance when you save a host an error comes up that says something to the effect of FOG ERROR: Location record not found error. No data array or ID passed… but everything is updated.[/SIZE]
[SIZE=2]After fighting with fog_0.32 for a few days I would recommend you think about a wide beta because it certainly worked out well for me once I stopped trying to update and just did a fresh install[/SIZE]
[SIZE=2]Thanks [/SIZE]
-
I have something to add to this. Have been using .32 without issues. Recently received a batch of HP z230 workstations. Updated to the newest fog kernel and had no issue uploading a custom image with the 32bit win 7 installed on it. But when I attempt to upload a custom image (that I created from the install dvd) with 64bit Win 7 installed, I get the error. So it seemed like something with 64bit win. Wiping the partitions, and clearing mbr doesn’t seem to help.
Three observations here…
- The original “untouched” 64bit hp load can be imaged with no issues, although it looks like it may take 8 hours to do so
- If I pull the original hp hard drive that came with the machine, and replace it with a 1TB Western Digital (Blue) drive…off of my shelf…things work perfectly. No problem uploading a win7, 64 bit imge.
- I checked the original hp load, and it is using the gpt partition. Sectors are also 512 bytes.
Like others, I am in a production environment, and was hoping to hold off on updating fog server until after summer 2014.
Anyone else experience this? Any ideas?
tia-Rick
