So, I uploaded a new image, then made sure the Encrypted password strings were right for AD joining, made sure AD joining was checked for that client, imaged it with the new image…
And it did not auto-join the domain.
I will have to check with a previous image that I KNOW beyond doubt is good and see if domain joining works…
This will let me know if it’s the image, or the FOG version…
[quote=“need2, post: 45182, member: 21891”]I greatly look forward to any documentation of your travels in this. It is something I have fiddled with, but have lacked the time to actually work on. I have a hunch that, if you are running a Windows Server Domain environment, you could use a WDS server to figure out the different systems, then chain it into the appropriate boot files fog FOG.[/quote]
Follow my travels here: [url]http://fogproject.org/forum/threads/undionly-kpxe-and-ipxe-efi.12607/[/url]
That’s the junk thread that everything I find is going into… When I’ve got it nailed down, I’ll make a wiki article.
I think the client stuff just needed to update itself… and I didn’t allow the source machine enough time to do that…
I’m re-making a new image and will try again…
FOG client log.
[CODE] 4/8/2015 8:54 AM FOG::ClientUpdater File: SnapinClient.dll requires an update.
4/8/2015 8:54 AM FOG::ClientUpdater File: C:\Program Files (x86)\FOG\tmp\SnapinClient.dll hash doesn’t match server hash!
4/8/2015 8:54 AM FOG::ClientUpdater Checking Status : TaskReboot.dll
4/8/2015 8:54 AM FOG::ClientUpdater File: TaskReboot.dll requires an update.
4/8/2015 8:54 AM FOG::ClientUpdater File: C:\Program Files (x86)\FOG\tmp\TaskReboot.dll hash doesn’t match server hash!
4/8/2015 8:54 AM FOG::ClientUpdater Checking Status : UserCleanup.dll
4/8/2015 8:54 AM FOG::ClientUpdater File: UserCleanup.dll requires an update.
4/8/2015 8:54 AM FOG::ClientUpdater File: C:\Program Files (x86)\FOG\tmp\UserCleanup.dll hash doesn’t match server hash!
4/8/2015 8:54 AM FOG::ClientUpdater Checking Status : UserTracker.dll
4/8/2015 8:54 AM FOG::ClientUpdater File: UserTracker.dll requires an update.
4/8/2015 8:54 AM FOG::ClientUpdater File: C:\Program Files (x86)\FOG\tmp\UserTracker.dll hash doesn’t match server hash!
4/8/2015 8:54 AM FOG::ClientUpdater Checking Status : config.ini
4/8/2015 8:54 AM FOG::ClientUpdater File: config.ini requires an update.
4/8/2015 8:54 AM FOG::ClientUpdater File: C:\Program Files (x86)\FOG\tmp\config.ini hash doesn’t match server hash!
4/8/2015 8:54 AM FOG::ClientUpdater 1 new modules found!
4/8/2015 8:54 AM FOG::ClientUpdater Checking Status :
4/8/2015 8:54 AM FOG::ClientUpdater File: requires an update.
4/8/2015 8:54 AM FOG::ClientUpdater An exception occurred during a WebClient request.
4/8/2015 8:54 AM FOG::ClientUpdater at System.Net.WebClient.DownloadFile(Uri address, String fileName)
at FOG.SnapinClient.downloadAndDeploy(String localFile)
4/8/2015 8:54 AM FOG::ClientUpdater Client update will be applied during next service startup.
4/8/2015 8:54 AM FOG::ClientUpdater Client update process complete, exiting…[/CODE]
[url=“/_imported_xf_attachments/1/1852_fog.zip?:”]fog.zip[/url]
Oh, the problem is they didn’t join to the domain.
Just got done imaging a lab, never had this problem before in this lab… FOG r3218
[IMG]http://s28.postimg.org/bzo9guunh/unable_to_resolve_hostname.png[/IMG]
Same here, although this isn’t critical because things are working.
Just reporting the bug is still here. FOG r3218
This may or may not be related, but, I’m sitting in a lab watching it image right now.
Things are going smooth, but the “Tasks” tab in the FOG web GUI is reporting some hosts speeds correctly, while others are sitting at zero… FOG version r3218
Have you checked the server’s hdd health ? Checked the RAM health?
Built a FOG server at home, using dnsmasq, having the blues with it.
I can’t get the target computer to network boot…
Fedora 21 server - fully updated as of yesterday.
FOG - r3224
Target machine: Optiplex 745 This is listed in working hardware with undionly.kpxe
[CODE][root@localhost trunk]# ps -Af | grep tftp
root 13942 9516 0 20:45 pts/0 00:00:00 grep --color=auto tftp
[root@localhost trunk]#
[/CODE]
[CODE][root@localhost ~]# service dnsmasq status -l
Redirecting to /bin/systemctl status -l dnsmasq.service
● dnsmasq.service - DNS caching server.
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled)
Active: active (running) since Tue 2015-04-07 20:54:05 CDT; 52s ago
Main PID: 15967 (dnsmasq)
CGroup: /system.slice/dnsmasq.service
└─15967 /usr/sbin/dnsmasq -k
Apr 07 20:54:42 localhost.localdomain dnsmasq-dhcp[15967]: 2712157279 tags: enp2s0
Apr 07 20:54:42 localhost.localdomain dnsmasq-dhcp[15967]: 2712157279 bootfile name: undionly.kpxe
Apr 07 20:54:42 localhost.localdomain dnsmasq-dhcp[15967]: 2712157279 broadcast response
Apr 07 20:54:42 localhost.localdomain dnsmasq-dhcp[15967]: 2712157279 sent size: 1 option: 53 message-type 2
Apr 07 20:54:42 localhost.localdomain dnsmasq-dhcp[15967]: 2712157279 sent size: 4 option: 54 server-identifier 10.0.0.3
Apr 07 20:54:42 localhost.localdomain dnsmasq-dhcp[15967]: 2712157279 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74
Apr 07 20:54:42 localhost.localdomain dnsmasq-dhcp[15967]: 2712157279 sent size: 17 option: 97 client-machine-id 00:44:45:4c:4c:46:00:10:4c:80:52:b2:c0:4f…
Apr 07 20:54:42 localhost.localdomain dnsmasq-dhcp[15967]: 2712157279 sent size: 97 option: 43 vendor-encap 06:01:03:09:3f:00:00:20:e2:80:9c:42:6f:6f…
Apr 07 20:54:47 localhost.localdomain dnsmasq-dhcp[15967]: 2712157279 available DHCP subnet: 10.0.0.3/255.255.255.0
Apr 07 20:54:47 localhost.localdomain dnsmasq-dhcp[15967]: 2712157279 vendor class: PXEClient:Arch:00000:UNDI:002001[/CODE]
Also, I can use tftp to get files from /tftpboot (some may find this example very funny)
[CODE][root@localhost log]# cp /var/log/foginstall.log /tftpboot
[root@localhost log]# exit
logout
Connection to 10.0.0.3 closed.
[administrator@D620 ~]$ tftp
(to) 10.0.0.3
tftp> get foginstall.log
tftp> quit
[administrator@D620 ~]$ ls
Desktop Downloads MEGAsync Pictures Templates xpshare
Documents foginstall.log Music Public Videos
[administrator@D620 ~]$ [/CODE]
And, the foginstall.log that I grabbed is attached.
Here is /etc/dnsmasq.d/ltsp.conf
[CODE]port=0
log-dhcp
tftp-root=/tftpboot
dhcp-boot=undionly.kpxe
dhcp-option=17,/images
dhcp-option=vendor:PXEClient,6,2b
dhcp-no-override
pxe-prompt=“Press F8 for boot menu”, 3
pxe-service=X86PC, “Boot from network” undionly
pxe-service=X86PC, “Boot from local hard disk”, 0
dhcp-range=10.0.0.3,proxy
dhcp-option=66,“10.0.0.3”[/CODE]
Firewall and selinux:
[CODE][root@localhost ~]# systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled)
Active: inactive (dead)
[root@localhost ~]# sestatus
SELinux status: disabled
[root@localhost ~]# [/CODE]
/tftpboot permissions
[CODE][root@localhost ~]# ls -la /tftpboot
total 3040
drwxrwxrwx 3 fog root 4096 Apr 7 20:47 .
dr-xr-xr-x. 21 root root 4096 Apr 7 19:59 …
-rwxrwxrwx 1 fog root 840 Apr 7 19:59 boot.txt
-rwxrwxrwx 1 root root 397 Apr 7 19:59 default.ipxe
-rw-r–r-- 1 root root 7129 Apr 7 20:47 foginstall.log
drwxrwxrwx 2 fog root 4096 Apr 7 19:59 i386-efi
-rwxrwxrwx 1 fog root 906560 Apr 7 19:59 ipxe.efi
-rwxrwxrwx 1 fog root 337051 Apr 7 19:59 ipxe.kkpxe
-rwxrwxrwx 1 fog root 337099 Apr 7 19:59 ipxe.kpxe
-rwxrwxrwx 1 fog root 336613 Apr 7 19:59 ipxe.krn
-rwxrwxrwx 1 fog root 337291 Apr 7 19:59 ipxe.pxe
-rwxrwxrwx 1 fog root 25340 Apr 7 19:59 memdisk
-rwxrwxrwx 1 fog root 16794 Apr 7 19:59 pxelinux.0.old
-rwxrwxrwx 1 fog root 169088 Apr 7 19:59 snp.efi
-rwxrwxrwx 1 fog root 169280 Apr 7 19:59 snponly.efi
-rwxrwxrwx 1 fog root 88724 Apr 7 19:59 undionly.kkpxe
-rwxrwxrwx 1 fog root 88772 Apr 7 19:59 undionly.kpxe
-rwxrwxrwx 1 fog root 88816 Apr 7 19:59 undionly.pxe
-rwxrwxrwx 1 fog root 147728 Apr 7 19:59 vesamenu.c32[/CODE]
Here’s a video of what it does: [media=youtube]9hwZpqPpYNQ[/media]
Here’s a screenshot of the Web GUI’s TFTP settings:
[IMG]http://s8.postimg.org/64q2abs5x/Screenshot_from_2015_04_07_21_13_53.png[/IMG]
Not sure where I’m going wrong with this… help would be very appreciated.
[url=“/_imported_xf_attachments/1/1851_foginstall.log.zip?:”]foginstall.log.zip[/url]
I posted a work-around here, on page 2.
[url]http://fogproject.org/forum/threads/svn-3192-hangs.12685/[/url]
[quote=“Uncle Frank, post: 45121, member: 28116”]Sucessful…??[/quote]
Nope… 
So, I’m sort of taking extreme measures for testing… I’ve set up a FOG server at home using dnsmasq, still haven’t got that completely working yet…
And I’m in the process of setting up another FOG server at work, isolated on it’s very own little 100Mb switch, disconnected from everything. I plan to run DHCP on that FOG machine.
So, literally, I WILL have every type of setup at my disposal to try to get this working with.
I’ve tried snp.efi snponly.efi ipxe.efi and a few others so far… and a custom one that Tom had me try as well.
This is really the wrong thread for this…
I might make one if I continue to have bad luck.
In my opinion, this should be a host setting, and if it were, you could then apply those settings in mass to whatever groups…
Tom,
I looked here: [url]https://svn.code.sf.net/p/freeghost/code/trunk/packages/web/client/[/url]
But FOGService.msi is not there. Where is it?
Although I’ve not used the Location Plugin yet, I hear it’s pretty awesome.
I am eventually going to write some detailed info on it for the WiKi… just not there yet… I’ve been Fogging since February and things are good SO FAR!
Ironing out some issues with UEFI at the moment…
[quote=“Mark Shelton, post: 45080, member: 423”]OK, just tried with 3221, which must have been submitted in the last hour. Still fails but I get a message now. Screenshot attached.
Regards, Mark[/quote]
Mark,
I just tested a work-around because I ran into this at home…
go to here:
[CODE]/root/svn/trunk/lib/<your flavor of linux>/[/CODE]
edit this file:
[CODE]functions.sh[/CODE]
towards the bottom, you’ll see stuff about “New FOG Client”
It’ll look like this, depending on your flavor of linux… but it’ll be similar…
[CODE]if [ ! -f “$webredirect” ]
then
echo “<?php header(‘Location: ./fog/index.php’);?>” > $webredirect;
fi
echo “OK”;
echo -n " * Downloading New FOG Client file…";
cwd=pwd;
cd $webdirdest/service;
count=0;
while [ -z “$clientVer” -a “$count” -le 10 ]; do
clientVer=php -f ${webdirdest}/service/getclient.php;
count=expr $count '+' 1
sleep 2;
done
if [ -z “$clientVer” ]; then
echo “Failed to get client version”
exit 1
fi
[/CODE]
Where you see this line:
[CODE]exit 1[/CODE]
Just put a hash tag in front of it like this:
[CODE]#exit 1[/CODE]
What this does is allow the script to try to download the new fog client, but if it fails, it won’t exit the installation script…
If you do this, I’d still highly recommend working with Tom fully to try to resolve the issue though.
Also, if your install fails to download the new fog client, YOU WON’T HAVE THE NEW FOG CLIENT… so don’t try to use it.
However, the old client will still be available for use.
Tom was working on it today a little for me.
At work, we have Dell 7010 models which UEFI can be enabled or disabled for. I’ve been having the blues trying to get them to boot with ipxe.efi
Shouldn’t keep him from pulling a file via TFTP client from some other computer though…
But yeah, that step is required.