You can export a list of your current hosts and then import them again after installation, (would be fastest and safest).

I would install 0.32 and then put back my current images from 0.32: name the image store the EXACT same as your previous image name (it will be the folder that houses your partition files)

After adding the image stores in, I would chmod everything to make sure that fog is happy and can see the images.[code]chmod -R 777 /images[/code]

Then I would immediately update to 1.2.0, I would not worry about 1.1.0 or anything between.

Afterwards I would restore my final images (if desired) and then import my host list.

This would be the most painless process I can think of (while saving your images and hosts).

Have you tried DNSMasq?

I recommend this a lot

It really helps to resolve to your bootfile and server, it can fix the issue that you are describing, I had to use it in my environment (Novell with Windows DHCP and WDS) so that my machines would default to FOG instead of the silly WDS server.

I would start here: [url]http://fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#DNSMASQ_settings_for_iPXE[/url]

[quote=“dwayneS, post: 36032, member: 25830”]Yes all of that was done and was working OK from day 1. After making the changes I mentioned above all was well. I only have 2 issues now.

1. a section of my unattended file seems to not work. There is a command to enable the administrator account but that not working. I need to revisit.
2. The computer is not being joined to the domain via fog client service. When I check the log file I get an unknown error 2202.[/quote]

Is this by chance an old image? I have had problems like this happen (with one unit in particular that we use for nComputing) where the Administrator user becomes corrupt and had to be removed. I also add a SECOND administrator when I use the unattend file, i name him Admin, that way I have two instances in which to enter as the admin user.

The only resolve I had for my issue was to set my image up again, it was daunting and well worth it!

I am glad you got your FOG issue fixed, and thanks for telling us HOW you fixed it, that will help users in the future, I hope you get your image issue fixed

not the .kkkpxe that was just information I decided to arm you with. I found that information on Etherboot.org It is a forum where that works very diligently on the ipxe system with the help of a VERY intelligent man by the name of Robin Smidsrod, the particular post I quoted you can be found here: [url]http://forum.ipxe.org/showthread.php?tid=6989[/url]

Only .pxe, .kpxe, and .kkpxe exist within FOG. (and kpxe.INTEL which was an attempt to alleviate issues with INTEL boards)

Sometimes the network issues can be alleviated by using DNSMasq to proxy serve your bootfile.

It would be worth a shot (because you don’t have to edit anything in your network). I have to use DNSMasq in my environment because it is Novell (which has boot file name limitations,) and I also have a few other imaging methods (such as WDS) that other co-workers feel more comfortable using. So I use the DNSMasq option in my buildings so that everything can resolve to my FOG server instead of the WDS server.

If you’re interested in seeing if dnsmasq will solve the issue (I know I am!) please use the following guide on the wiki: [url]http://fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#DNSMASQ_settings_for_iPXE[/url]

Good luck and let us know if it works, or how you solve your issue regardless!

What I do, and this is my personal preference and I will explain why, Is I build my images in a virtual format, and I ALWAYS keep this virtual Format.

I use Virtual Box, I have had the best speeds when compared to other virtual machines, but we have a pseudo work around for VMWare speed issues. I also chose Virtualbox because it is easy to port out your appliance and import else where. You can also take snapshots (and if you sysprep this is VERY important).

I always keep my virtual machine alive in some aspect, sometimes I even upload the image before completing the sysprep so I have a fall back in case my snapshot gets corrupted or deleted. Then I just start a new appliance and use FOG to image the machine and pick up where I left off.

This leaves me the opportunity (should it arise) for me to upgrade my fog server and re-upload my images if the format was not correct from a previous version (and that is just because I still use the 0.32 as a production server and I use my 1.2.0 for testing and breaking).

This would alleviate the issue of needing to change the type or to enable the legacy flag.

I realize that it’s probably too late for that, so my next suggestion is similar to the one Thiago gave. Back up your images, install FOG 0.32 fresh, and then perform the upgrade to 1.2.0. This will allow the legacy flag to be enabled so that when you restore your images they will be in the correct “format” if you will. This should solve your ‘partition out side of disk’ issue. I realize this is not the ideal solution, but it is A solution.

Sorry the upgrades have caused you trouble, I promise that all the changes are well worth it though, the system is much faster, and supports a wider range of partition types and OS types than we could previously cater to, plus now we have a really good means of compression that is easily changed

Thanks for letting us know, personally, I am like you, I don’t really use the Multicast features, just when someone says it’s not working so I can see what it is doing

Thanks for all the information it may help in finding the culprit and fixing it!

Of course if you troubleshoot further, feel free to leave some notes.

Yes it’s very highly possible. While they are all boot files, there are some key differences and that is why we recommend users test the others when one does not work, it helps us to determine what is failing and what helps it to succeed. I gathered some information for you below:

from Etherboot.org:
.pxe is an image designed to be chain loaded, unloading both the underlying PXE and UNDI code sections
.kpxe is a PXE image that keeps UNDI loaded and unloads PXE
.kkpxe is a PXE image that keeps PXE+UNDI loaded and return to PXE (instead of int 18h). From here
And there is also .kkkpxe - “The ipxelinux.0 build process should therefore now use undionly.kkkpxe instead of undionly.kkpxe.”

You usually use a .pxe when you want to use native iPXE drivers, most likely loading ipxe.pxe using chainloading.

And .kpxe is most commonly used with undionly.kpxe, because it allows you to use the driver of the vendor PXE ROM (which is handy when iPXE doesn’t support your card, or the iPXE driver is broken in some way).

I would have to argue that .pxe and .kpxe is the more commonly used forms, and .kkpxe is mostly used for buggy BIOSes and .kkkpxe is just for the ipxelinux.0 build (and nothing else).

Personally I have not had any luck using the command line to add, change, or remove a printer.

I am curious to see how you solve this issue, I normally just add the printers manually (if I forgot at image creation or I didn’t add them to the print manager).

[B]FIRST: [/B]I want you to know I came here to help to solve your issue, but then I found this: [url]http://www.reddit.com/r/sysadmin/comments/2en0v2/fog_partclone_error_exit/[/url]

[CENTER][SIZE=5][B]So Solve your own issue!!![/B][/SIZE][/CENTER]

I have no desire to help those who run their mouths on other forums/board systems and talk negatively about this product, or its devs which have given selflessly to solve issues that many of us will never experience.

Next time you want help ask for it with a piece of humble pie.

Junkhacker let you know that the machines themselves work, he has used them without an issue. The issue could be a number of things, from BIOS settings, to Network settings, to problems in the Image: And now you will never know. There is a LOT of documentation, not only from the devs but also the board USERS.

Many of us have lives outside of FOG. We do this in our spare time. Show some respect, and some gratitude instead of running to reddit to complain about the devs, you could try asking questions such as:

“What version of firmware is installed on your machine?”

“Have you updated your drivers?”

“What type of an image are you trying to upload?”

“Are your settings set to legacy settings in the BIOS?”

I could ask more to help you solve your issue, but you seem to have your own form of tech support, enjoy.

P.s. If you try the most up to date SVN we pushed a change that MAY solve this issue, or you can go make another angry post, you’re really only making yourself look bad when we sit here willing to fix many problems that aren’t our own.

When you say “image process” are you referring to an Image upload? or an Image download?

What happens if you run a compatibility check from the fog menu?

[FONT=Tahoma]To [/FONT]Run a compatibility test.

[FONT=Tahoma]From the fog PXE boot menu, you will see:[/FONT]

[FONT=Tahoma]Boot from hard disk[/FONT]
[FONT=Tahoma]Run memtest86[/FONT]
[FONT=Tahoma]Quick host registration and Inventroy[/FONT]
[FONT=Tahoma]Perform full host registration and Inventory[/FONT]
[FONT=Tahoma]Quick Image[/FONT]
[FONT=Tahoma]Client system information[/FONT]
[FONT=Tahoma]Debug Mode[/FONT]

[FONT=Tahoma]A. Choose Client System Information[/FONT]

[FONT=Tahoma]B. Your computer will load another menu and it will look like this:[/FONT]

[FONT=Tahoma]1.) Reboot[/FONT]
[FONT=Tahoma]2.) IP Information[/FONT]
[FONT=Tahoma]3.) Partition Information[/FONT]
[FONT=Tahoma]4.) Check FOG compatability[/FONT]
[FONT=Tahoma]5.) Ping a Host[/FONT]
[FONT=Tahoma]6.) Display MAC Address[/FONT]
[FONT=Tahoma]7.) Show DMI Information[/FONT]

[FONT=Tahoma]C. Type 4 and press Enter[/FONT]

I would try by removing the current information on the disk and making sure a partition exists, follow the directions listed here please: [url]http://fogproject.org/forum/threads/quick-format-to-ntfs-with-fog-for-noobs.10349/[/url]

If you’re Running Ubuntu, or Debian you can try the DNSMASQ service, it sometimes helps to alleviate issues and resolve to your tftp boot server with your correct file.

Instructions can be found here: [url]http://www.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#DNSMASQ_settings_for_iPXE[/url]

Use the section DNSMASQ Settings for iPXE.

Very nice guide, but I feel it should be stated, and possibly even at the very top of your guide, that [B]Ubuntu 14.04 is NOT a recommended OS for installation[/B].

Thank you for taking the time to document your steps, we appreciate your work

I think someone moved the post from the Bug section to the Features request section, before that was done, yes this was posted here.

These are my personal preferences:
If I were to install Ubuntu, I would use 13.04.

If I were to set up a fog server, I would use Debian 7.4.

Thanks for letting us know. I am about to tackle the process of switching over from Novell to AD, so these are the things I need to know before I figure them out myself!!!

I agree with Jarli.

I use the Name changer service frequently. The only time I have a problem is if the network drivers fail to install, in which case I install the drivers and then the name changer service does its job. I have even changed the name in the Host section of FOG and had the machine change it’s name after it had already checked into the FOG server after imaging. Actually, if you don’t change the name in FOG to meet that of the machine, FOG will change it’s name every time it starts up. Sometimes I manually adjust a machine name and forget to do so in FOG and it will change the name back… sneaky bugger.

This sounds to me like an issue with the OS, or the hardware. I would definitely begin troubleshooting the OS though.

Is this a wide spread issue and every machine in your environment is behaving this way? or is this only affecting a specific model? Or only this machine?

Are you using Novell or something similar to authenticate into the network? We set up auto login scripts to log in the windows user and it is dependent (or it use to be, its not so much anymore) on the Host Name of the machine and the Domain it is connected to. Changing this information without adjusting the registry values causes the machine to behave erratically, sometimes leading to not logging in, or shutting down.

That’s the way I do my drivers right at C:\Drivers. I even add it to the path variable in the registry so that when windows parses for a driver it looks in that folder too by default.

Thanks for letting us know how to solve it!