id the name change service enabled? It sounds to me like the computer name doesn’t match what FOG thinks it should be and is attempting to set it, and rebooting to complete the change.

I know you are trying to get it to join to the domain, but lets test pieces at a time. Disable the name change service and see if that helps with the reboots.

Think I may have solved this, I didn’t realize that FOG saved the AD settings “inside” each host instead of using the settings specified in the configuration area. Will see if I’ve fixed it now. - Will update this post with result in case anyone else hits the same barrier.

That was the solution…
For people suffering with difficulties make sure the actual host has got the correct credentials as it didn’t apply globally when I changed it in the configuration area. See image below for the secondary configuration I needed to do.

[ATTACH]1363[/ATTACH]

Thank you for your help with this issue, I hope this helps others as well.

[url=“/_imported_xf_attachments/1/1363_fixed.png?:”]fixed.png[/url]

[quote=“Mentaloid, post: 36203, member: 4362”]You upgraded to 1.2.0? If so, you might want to verify that the default domain settings are correct in FOG config, noting that the domain portion should NOT be included in the username anymore.

If you have clients that are not using the default (as in you specified the OU, and therefore the rest of the domain settings as well), then you may need to double check the individual clients/groups as well for misconfigured domain/user’s[/quote]
hmmm thats interesting. i will have to try that when i return to work. the domain user section that is. When i searched the 2202 error is an AD authentication error and not a fog error, stating that the provided name is incorrect or in wrong format

Well, while I do make schema changes often, it’s not going to degrade the DB as that’s too much work. If there’s db values inserted, it’s all new stuff, and therefore wouldn’t matter to the FOG System as they most likely won’t even be updating anything.

Hello Tom,

I have resolved the issue. I has performed the upgrade too quickly and I missed the prompt to upgrade the database at [B][url]http://10.0.0.3/fog/management[/url] [/B]When I went to the link, there was the magic button to upgrade the database.

I apologise for wasting your time for my mistake. Thank you for your help.

Is this supposed to be a Resizable Image, or a Multipartition image?

had the window open for a while and posted that without refreshing the thread. happy to hear you figured it out.

This will help: [url]http://fogproject.org/forum/threads/so-you-need-to-change-your-fog-server-ip-address-good-luck-with-that.11638/[/url]

[quote=“Tom Elliott, post: 36441, member: 7271”]What is this?[/quote]
A drunk user ? haha
I don’t think there is link with the topic.

You sir, are my hero.

May someone buy you a beer on my behalf!

Hey ! Thanks for Answer !

I found the problem… i am so stupid sometimes…
so the problem was that i started running fog on a test server and one day i installed win 8 on my laptop …logged in as administrator…installed vmwareworkstation and imported my fog in my workstation… i worked with it a while and then i checked that i can’t use my apps if i am logged on as administrator so i create a user and then i imported again the fog in my workstation… but i imported the old fog not a newer version with my new images on it…

well… thanks again !

Success
I first tried bzImage32 network boot ok “client system info” returned
invalid or corrupt kernel image.
boot:
next I tried bzImage
network book ok client info passed
Ready to image the T440s Monday morning should be fine Ill report back to let you all know.
Thanks for the roadmap much appreciated
John R

Is the tftp server correct?

Does the file undionly.kpxe exist in /tftpboot/?

Have you copied the contents of /tftpboot/* to /var/lib/tftp/?

Don’t know if you got it right by now, but here it goes how I solved it.
I write another thread in BUGS, about this.
It has to do with the way the script fog.download counts partitions.
If you really need multicast with multiple partitions:

unzip init.xz (the same goes for init32.xz) with xz -d init.xz mount the init file in a loop device with: mount -o loop init sometempdir/ go to sometempdir/bin with cd edit fog.download, and search for the part that does the multicast write, for your “method” (mps or mpa) look for the part that does a loop on each partition, and fix it in a way that it checks for the existence of the file
(something like if [ ! -f $imgpart ] ; then echo “Partition file missing …jumping”; sleep 1; else writeMulticastImage; fi )
(look in the “not multicast” lines or the previous multicast method, for just linux type) save your file, and back to the init file dir. zip it with xz -C crc32 init

Put the task again to try it.

Try it again …you should briefly the message “Partition file …” and get the correct ones to the partclone/partimage program stream

Other related bug is in the MulticastTask.class.php. If you have 10 or more partitions, you need natsort() instead of sort().

Maybe you need a (not so much experienced) linux shell programmer to help.

P.S. Be sure to have also installed the php-process extensions to PHP, as the killing of multicast tasks uses posix_ functions in it. (That is for a CentOS / Redhat server; on Ubuntu server I have not tested or searched for them)

I can not promise anything but I will look into implementing this feature into the new FOG Service. It shouldn’t be overly difficult. If and when I do get around to it, would you be willing to beta test parts of the new service to see if the local port network printers work properly (I don’t have any to test on)?

Network issues I’ve experienced: STP taking too long to enable forwarding between network stack reloads, poor quality network wire or damaged runs (this is where I experienced your exact error message, it will work on dhcp, but fail on bigger packets), and amazingly enough, bugs in the switches (in my case, Cisco SG200’s with layer3 protection that could not be disabled - a firmware fix is available now) that caused issues with UDP on privileged port ranges (NFS), and slow DHCP servers.

Tom, first, thank you so so much for the work you do on the FOG project. I have been a fan for many many years. I thought that LVM support had been achieved in this latest release. So my heart is broken, but its cool. Fog is still a great product and hopefully one day LVM support will be included. I can only hope to one day contribute like you do. Thanks again!

To add on to this, While I completely agree with Jayme’s post, it seems to me that this issue is known about.

First, it seems to me that as you’re using XP, this problem is a known issue in a few threads. I’ve been doing my best, but as I, as many of us here do, work in a school district, am pretty swamped at work. The quick fix, from what I could think of, is to push XP/Vista images into the same category as how all the rest operate. Windows 7/8/8.1 resizable images are typically stored in /images/<imagepathname>/{rec,sys}.img.000

XP and Vista supposed are a singular file in the format of:
/images/<imagepathname>

I’ve pushed the changes to bring xp and vista into the same realm as Windows 7/8/8.1, but haven’t had any of either of these images to test it with as I have been busy at work. I’m sorry.

Second, the “hanging” for a second then error exit seems to me that the problem is more related to locating the file which leads me to the information in the "first’ part of this posting.

While I understand the “reddit” post may or may not have been done by you, it seems that Junkhackers response was an indirect (“We need more information.”) rather than a direct stab at you. The comments therein that post seem a bit harsh and rash. While it could’ve been stated more clearly, he was simply trying to get the point across that he uses those systems to actually do work and they work fine. He probably wasn’t using XP, and he was attempting (I think) to tell you the system in and of itself works fine.