@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

@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