@msheikh said in PXE-E51 Error after fresh installs:

I had to edit the field for ‘range dynamic-bootp’ to conform to the 192.168.1.xx subnet

Ah, forgot about that part. I glanced at next-server and saw it was right, idk what I was thinking.

Here’s a couple more links that might help me finish that dang article:

https://forums.fogproject.org/topic/5019/fog-nfs-challenge-can-you-do-it/14
https://forums.fogproject.org/topic/2861/latest-development-fog/369

@Wayne-Workman Thanks! I ended up needing rename /opt/fog/.fogsettings and run the installer fresh but it was able to update successfully.

Good Day

For the first time after loading new server FOG 1.3.0 RC 30 my scheduled cron tasks does work.

Thank You

FOG Client log is always the 1st place to look for anything concerning the FOG Client, always.

For the already registered what version of fog are you running?

For the kernel panic, maybe there’s a firmware update for these? Also, how are the clients booting to the menu (efi or bios?? I suspect potentially problem in efi boot code.)

@Haz The thread has gone off topic and has been forked to here:
https://forums.fogproject.org/topic/9085/host-already-registered-and-memtest-issue

So I am not really sure what I did, it was some combination of commands but it let me install it just fine… I’ll take it.

This can be marked as solved I guess!

@lawrence1997 Getting errors is not helpful to anyone. What kind of errors are you getting?

I’m seeing, now, that something recently changed on ondrej repository again :(.

@Wayne-Workman Thanks a lot, this did the trick, I had the exact same problem!

@WourN The installer should have taken care of it for you (but most people installing fog tend toward fresh which means they’re likely installing CentOS 7). Basically, those commands downloaded and installed the repositories FOG is supposed to be installing for you.

Worked out the issue. It was proxydhcp causing the issue. I cannot tell if the issue was Dnsmasq(router and DHCP server) passing off to dnsmasq (proxy DHCP) and not getting the dns to properly route. However, because dnsmasq is already available on the DHCP server we disabled the proxy DHCP and setup the dnsmasq boot items for efi/legacy on the dd-wrt side. This, as I understand it, change around for supporting efi and legacy was the reason he wanted to use proxydhcp to begin with.

@MarcB can only quote from memory since I don’t have the setup at work.

But my fog server is 1.3.0RC16 running on a Raspberry Pi running raspbian [https://forums.fogproject.org/topic/8642/installing-a-bit-of-fog-pi-the-hackish-way]. Yes it is running dnsmasq but I compiled 2.76 to have uefi support [https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support].

My ltsp.conf configuration is a bit more complex when you add in the uefi support, but the initial script is also listed in the tutorial https://forums.fogproject.org/topic/8726/advanced-dnsmasq-techniques

As for Virtualbox I installed 5.1.10 for Ubuntu 15.10 (“Wily”) x64 and the VirtualBox 5.1.10 Oracle VM VirtualBox Extension Pack. Then I changed the network adapter to bridged that was connected to my laptop’s wireless adapter and set the virtualbox network adapter to the intel (desktop) adapter. Then for the boot order I set the network adapter first in the list.

Your dnsmasq log file “looks” good. It says its sending bootfile and next server. But that isn’t what your pcap was showing.

@koelhomem Why do you think things are “correctly configured”?

Based on the message I’m seeing, there’s a problem with mounting the NFS share to perform the download from.

I’d say try:

Restart the server’s nfs service (Redhat typically service nfsd restart or service nfs restart, ubuntu typically service nfs-kernel-server restart)

Check the exports file It should look something like:

/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0) /images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1) Ensure permissions are correct and the .mntcheck files exist in both directories: touch /images/.mntcheck touch /images/dev/.mntcheck chmod -R 777 /images Make sure firewalls are disabled on the server. Or at least the right ports are opened up.

This is solved since the RC-28
thank you

@fry_p It could be a monitor, keyboard, mouse, patch cable, video cable, or power cable causing the issue too.

We had a computer “Spot” once that was just voodoo’d. It blue screen’d, I said OK. Image it. Fixed. A few weeks later, blue screen. I said, OK it’s a hardware issue. PC Replaced, boom fixed. A few weeks later, another blue screen. I said, OK, this is highly unusual, but I’ll image it. Fixed. And again, another blue screen.

After that last one, I went in with a replacement monitor, replacement VGA cables, replacement power cables for everything, replacement keyboard, mouse, surge protector, and replacement patch cable. The whole 9-yards. Everything but the physical desk and chair was replaced. And that fixed it. All the old crap I pulled from there was marked “bad” and surplussed, I didn’t even bother testing those items as they were old and low-cost.

I feel I need to add this, so people stumbling across the post understand.

The UNIQUE key for the hostMAC table is one key with two columns (hmMAC, hmHostID). Basically this means, a MAC cannot exist multiple times for the SAME host, but they can appear multiple times for different hosts. The idea is to allow the mac’s to show up with the hosts they reside in, but when it comes to identifying a host based on the MAC address, this becomes much more of a “no man’s land”.

This, we hope, will not be the case for much longer. One, MAC Addresses can be spoofed (and the same mac can exist on different machines even) so we’ve kind of lost the MAC Address as a unique identifier for a host. It probably doesn’t help that it’s not uncommon for a Laptop to have 2 or 3 MAC Addresses on it. Image an organization with only 1000 laptops. That’s potentially 2000 to 3000 MAC Addresses. Now I realize the unique identifier number is extremely high (each manufacturer has a potential of 16,777,215 addresses available) but as you see you can have the same mac address on multiple systems, it’s not very good for the hometeam.

It is uncommon to see the error itself, but when it has come up it’s usually because of a VM or TUNNEL adapter that is embedded as a part of the image. This, more or less, is where the pending filter comes in though.

While this field was, I think, only intended to filter any incoming “pending” mac addresses, it really should be applied to any mac address and it has been made to do exactly that.

OK, I fixed the Apache/HTTPD issue. After much, much, much searching I found this site for a fix and it worked for me.
http://awsadminz.com/httpd-service-main-process-exited-kill-cannot-find-process/
Should I post a separate tutorial as a fix for this issue?
As for the kernel thing, I tried a different PC and it is working fine. I guess I’ll have to figure that one out.

@88fingerslukee In the bios/uefi firmware settings, what is the boot order?

i.e and or also…

Is UEFI enabled and Legacy enabled, or just UEFI?
What pxe boot file are you using? I’ve seen that make a difference. I haves some cheaper HP’s that won’t boot with sanboot to the hard drive if you use ipxe.kkpxe, but they work fine with ipxe.pxe or ipxe.kpxe.

Also have you played with the refind boot settings? There’s a file on the fog server at
/var/www/fog/service/ipxe/refind.conf
there is a line that starts with scanfor I’ve changed mine to only look for internal,external which means it only looks for uefi options and not legacy options. On a few of my devices, if I have it set as uefi only it has a pause on the host every boot if UEFI CSM isn’t set and it searches for the bios options that are enabled in fog by default.

@Olduser Normally this is an FTP issue (as ftp is used to move the image from the /images/dev to /images folder).

Please run through:

https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP