@Tom-Elliott
@Wayne-Workman

Great to hear! Thank you for the update! Thank you also for the quick replies and hard work. It is enormously appreciated. Will await RC-11 and give it a go.

Thank you again.

@george1421 said in LDAP Plugins in FOG 1.3.0 RC 8:

Your explanation also tells me why there was an admin field in the database

It was setup to restrict someone to just fog mobile if they weren’t an admin. It’s a checkbox in user management, for a user. When checked, they can only access fog mobile I think. Or vice versa… or something.

One detail that I left out was that the fog images files were saved on the open partition of the 5tb drive I assigned them too as pointed out by @george1421.

I admit i was a bit confused at first by what he was saying as i wanted to mount the images to a specific folder on the drive (secondary) and then i realized that i needed to partition the drive as the new fog destination needed its own space. I then create space on the drive by partitioning the drive and mounting the second partition as a files storage for whatever i like while the fog partition would stay hidden.

0_1474264470152_partition.png

Thank you guys this thread is solved, success!!!

Tom and George are correct. Nic to Nic requires a crossover cable - anything else simply wouldn’t work at all.

I’ve used fog to change hostnames of computers joined to a domain. It works fine. What’s most likely happening is the credentials you have saved in fog for AD don’t have the authority to disable the old computer objects so new ones can be made.

At any rate - we’re just guessing and won’t be of much help until we can get a c:\fog.log file from an affected host from you.

@Tom-Elliott Yes hosst register is enable for all hosts… As you said, I suppose for any reason Fog client can’t see other mac addresses, but finally it’s not important !
Can it be due to pci=noacpi parameter ?

@george1421 I wonder if it’s the same error as the line 103 error of the other items?

@mbarker
in a normal fog install, there is no init.xz in /tftpboot.
I think that maybe your install is very modified and this is causing some issues…
I know that it would be your thousandth installation, but when you got fog up and running, your effort will have been worthwhile.

I was looking for other tools, they exist but are not as productive as this.

@Tom-Elliott Gotcha. I appreciate the help.

@Thiago Yes I did. I also rebooted and ran this again.
Still with the same issues.
Thanks,
Rob

@Tom-Elliott
Yes, I’ve had confirmation from the tech.

i looked for /opt/fog/.fogsettings and changed the password the for fog user to the password i set before the update.
After that, re-runed the installer - seems to fix the problem.

tnx 🙂
Niv

@Scott-Adams You should first update to RC-10. You already have the file you need, it’s /tftpboot/ipxe7156.efi

Please use wireshark to capture a DHCP conversation from the surface pro 4, we are collecting vendor strings for these devices, it’s kind of important to us. With this, we can tell you exactly how to configure your DHCP server to serve this particular file to your Surface Pros, and this will help everyone else too. And it’s not that big of a request. In wireshark, use the bootp filter.

@irishfoguser 2nd yep right where you are scheduling the task

I had the same issue. I changed the “HOST EFI Exit Type” for the host to “REFIND_EFI”. After rebooting, when you go to boot from HDD, you will get proceed to a screen titled “rEFInd - Initializing” and “Hit any key to continue”.

After hitting enter, I boot right into Windows no problem.

@PeterT Just to circle back on the question.

I just received a 7440 AIO and using FOG 1.3.0-RC8 I was able to deploy to the 7440s without making any adjustments to the device. I just unboxed it, plugged it in and pxe booted into the fog menu… and the rest they say is history.

@Wayne-Workman add a note that this is specific to Linux images. This same step would not work on Windows based images

@irishfoguser just wanted to say the messages you saw aren’t hurting anything whatsoever. Tom reworked the build parameters for the kernel not long ago to include better support for Surface Pros. Some of those messages are the kernel not seeing the surface pro hardware.

Turning down the log level could even be a disadvantage to you, because if you did have kernel problems, you wouldn’t know it, and you’d post here with zero errors asking for assistance - and it’ll maybe take us a while to figure out what’s going on. And - say you remember to turn the log level when you have a issue. But will the person that comes in behind you do that? Would a co-worker know that?

I’d suggest leaving the log level at default, but you can do as you wish.

@MarcB said in Client boots from FOG server in one network, but registers with FOG server in different network:

I just reread the README and see that every file in that directory will be read by dnsmasq unless it has “.dpkg-dist”,“.dpkg-old” or “.dpkg-new” appended to the end.

Lol… that would explain what I found long ago, and ranted about in this thread:
https://forums.fogproject.org/topic/8127/has-something-changed-with-uefi/24

@Wayne-Workman said in Has something changed with UEFI?:

Also, I want to point out some stuff with dnsmasq that has tripped me up before.

Firstly, it uses WHAT-EVER it finds inside /etc/dnsmasq.d

Doesn’t matter what it’s named. ltsp.conf, ltsp.conf.old, MyXmasWishList.txt - it does not care. If you have backup configurations in there, move them somewhere else.

Maybe that issue is resolved in the newer version, I don’t know.

Second - when dnsmasq sends out it’s ProxyDHCP - it appends .0 to the filename it gives. You could do some complex stuff with symbolic links, but I prefer not to. I prefer to copy the file I want to use. In your case, let’s go with ipxe.efi. You’d copy that like so: cp /tftpboot/ipxe.efi /tftpboot/ipxe.efi.0