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

@Towndrunk said in Multicast won't start:

Is there any benefit to updating all the time if there is also the potential to have things not work?

The benefit - getting a bug you report fixed. Getting bug fixes others report.

Updating is totally up to you. Nobody is forcing your hand, and Release candidates are just that. Release candidates. If you want to sit on it, you can. If you want to update, you can.

However - if you have issues and ask for help here, and the devs/mods/testers know your issue is fixed in a later RC, we will ask you to update and won’t offer much help with getting your older RC to work, when all you would need to do is update. Of course we’d help with the updating itself if you had problems. But it’s all still up to you.

@Dommason01 said in Intermittent failure to expand ext4 filesystem to fill disk:

I assume that I won’t lose all my registered hosts, and my images will still be valid?

Correct.

I’ll do a mysql backup anyway, first…

Always a good idea, and I’d always recommend this. But also the installer makes a DB backup, and puts it into /home/fogDBbackups

From your picture of All Storage Nodes, there is no storage node in a group called “Green”. That may be related to your issue.

What’s the host’s location setting set to?

And, I see several storage nodes, but only two locations. Both locations are set to DefaultMember. This probably isn’t right.

Can you just verbally describe what servers are where and maybe we can help get the locations sorted?

@habu what I’m saying is its copying data that should not be there. Modifying core files only works around the issue. What I’m suggest will fix the issue permanently for you.

Works like a champ once again

@Sebastian-Roth
Yes, My image is not resizable…
I will try to reproduce my steps…
1 - Erase disk data/delete partitions
2 - Install Windows, reserving space for linux or shrink windows later (in disk management tool, or gparted if needed).
3 - Install Linux, install grub on mbr or partition.
4 - Configure grub if needed ( i had to make some minor changes only in Debian8/Windows10 because grub was listing windows 10 as 7)

My preference to use grub is because i can make changes in boot order, one time boot order and so on… easily using ansible or other management tool. I don’t know how can i achieve the same in Windows side.

@Miguel-Palacios
I think fog 1.2 is not totally compatible with synology nas because synology use two different path to access data over NFS & FTP (/volume1/images & /images)
and on fog storage node interface you can only set one path.
(Fog does the rename job with the ftp account.)
you need to go with a newer fog version to have the “ftp path” option.

@Lenain
Solved now, I will open a new post for WOL problem. Thanks 😉

Check in time cannot be changed. The checking time out can be but this is not what you’re looking for.

It is highly doubtful checkins are causing issues as they are not spamming the server very often (one check every 5 seconds per machine.) If it were a server spamming issue it would most likely come from progress reporting as that checks in every 3 seconds. However the slowdown on images is the main issue as quazz and Wayne pointed out.

While I suppose removing intermediary requests could help lessen the work stop/start, this would be primarily micro-optimizing as all the checkin does is update state, if needed, and decide if it is safe to start doing the tasking.

@THEMCV rc10 is pushed, albeit a couple days later than I wanted to.

@gerald.stachl

I solved this question, i hope it may help someone.

FOG 1.3-RC1 on CentOS 7.0. Unicast deploy working. Even multicast was working.

After a system reboot, MulticastManager didn’t start again:

Sep 4 06:01:28 clonacion FOGMulticastManager: PHP Fatal error: Call to undefined method MulticastManager::getBanner() in /opt/fog/service/FOGMulticastManager/FOGMulticastManager on line 13

It didn’t matter if I added a multicast task: udp-sender process didn’t start because service didn’t start before (you’ll see only one FOGMulticastManager in process list --ps–, it’s the parent which forks periodically one child process (but this one will die at GetBanned method invocation).

If I commented GetBanner() invocation out at /opt/fog/service/FOGMulticastManager/FOGMulticastManager, then it failed at next method call to object MulticastManager.

I found TWO “MulticastManager” class, one of them extends FOGBase (at lib/fog directory) and the other one extends FOGService (at lib/service directory). Only the last one has defined methods like GetBanner(), etc. By any reason, it uses in some cases wrongly the first one (even when it used the second one after installation because it worked before).

So, I renamed MulticastManager class that extends FOGService to MulticastManagerService, and I changed the code to use that. After that, service FOGMulticastService starts with no problems, it works. I did the same thing with rest of services: FOGScheduler,…

I resume (for service MulticastManager: repeat it with other services in /opt/fog/services directory):

Edit /opt/fog/service/FOGMulticastManager/FogMulticastManager file: modify line 8 from $ServiceClass = FOGCore::getClass(‘MulticastManage’); to $ServiceClass = FOGCore::getClass(‘MulticastManagerService’);

Rename file /var/www/html/fog/lib/service/multicastmanager.class.php to /var/www/html/fog/lib/service/multicastmanagerservice.class.php (/var/www/html/fog is the path to fog web service)

Edit /var/www/html/fog/lib/service/multicastmanagerservice.class.php and modify the name of this class (line 2) from “class MulticastManager extends FOGService” to “class MulticastManagerService extends FOGService”

In the video @ 9 seconds, did you reboot the machine? Why did it appear to reboot?

Also - FOG does not use ISO files for imaging. You must first capture an image using FOG before you can deploy it.
0_1473376357244_iso.png