Another unable to move /images/dev problem
-
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