Moving the host means physically moving it and plugging it into the switch that is managed by the other storage node. Both storage nodes are acting as dhcp servers and assigning ips, but they are connected to separate switches. I added a diagram that may help
SERVER
FOG Version: 1.4.3
OS: Ubuntu 16.04 Server LTS
CLIENT
Service Version:
OS: Windows 10
DESCRIPTION
My current setup is the following:
The first storage node works perfectly and images it’s hosts as expected, but hosts on the second storage node cannot get past the iPxe boot step. They fail with a “Connection timed out, Chainloading failed”
I have spent quite a bit of time trying to figure out what the difference is between these two nodes and I am at a bit of a loss. The default.ipxe files are the same between the two, as is /etc/network/interfaces
I also compared the the contents of /etc/dhcp/dhcpd.conf and the contents of /etc/default/isc-dhcp-server. No issues here either. Also, I moved one of the hosts from node 2 and connected it to node 1. The host no longer had any issues so this seems to be a problem with the storage node and not the clients.
I have attached two images, one is the error from a host on node 2, and the other is from a host on the working node.
Any ideas what I could be missing here?
Thanks @george1421
I went ahead and moved the php — but I am now getting http 500. I rebooted the fog server to see if that would resolve it but it doesn’t look like it did
SERVER
FOG Version: 1.4.3
OS: Ubuntu 16.04 Server LTS
CLIENT
Service Version:
OS: Windows 10
I have a new .php module I want to install — I have put it next to the others in packages/web/service, but I don’t want to re-install fog in order to load this. Is there a better way to install this?
Sorry for the late response on this guys.
The issue with this turned out to be with the OEM recovery partition that came with our dell machines. For whatever reason fog didn’t like it. Removing this partition fixed the issue and we now have the new fog server, and all the new hardware synchronizing and imaging correctly.
Thank you guys again for all your assistance in this thread (and the others). This forum has been extremely helpful
@george1421 Awesome, thanks again for all of the help with this.
Our 7040’s are set up with SATA drives
I am going to try a manual install like you suggested and see what happens — but while I do that I do have a few updates
All of the hosts are Dell Optiplex 7040’s, and I was able to verify that the BIOS settings are the same.
Some details of what I have configured in the BIOS:
Also, I tried testing out the different exit options, and I got different behavior when selecting GRUB - ‘First Found Windows’
With this option, I get the following message: BOOTMGR image is corrupt. The system cannot boot.
The original host from the capture boots just fine, so it seems that maybe the image is getting corrupt somewhere in the capture and deploy process??
I will follow up again once I test a fresh install of windows 10 and see if the FOG PXE Boot works afterwards.
@Sebastian-Roth Alrighty so switching it from SANBOOT exit to GRUB allowed the original host from the capture operation to boot in correctly.
However, now when I try to deploy and boot into one of the other hosts, the process gets stuck with only the following three lines visible
Launching GRUB…
begin PXE scan…
Starting cmain()…
I double checked the bios on these hosts as well and everything seems to match up. Any ideas?
@Sebastian-Roth. I tried a deploy as well, and the machine I deployed to is experiencing the same issue it seems.
After completing an upload task on a host with windows 10, the machine becomes unbootable via fog. The fog system attempts to boot from hard disk but ends up stalling on a blank screen with a single blinking line.
I verified that the image / hard drive is fine by skipping the network boot and manually booting into the hard drive. So it seems like something is wrong on the fog end.
I was wondering if you guys had any ideas?
@george1421 This is solved. There was a stale storage node in the web console, and that is what the client was attempting to attach to. Thanks for the help guys!
The wrong IP Address is being used during the capture process. The IP shown in the below picture is an old IP address from before I moved this machine to a different server room. So it seems something needs to be updated somewhere. I verified that the correct IP address shows up in the Web UI for the storage management, and I have also checked interfaces, .fogsettings, dhcpd.conf, the tftp, and also the /tftpboot/default.ipxe config. I have also tried rerunning the install script as well, but still no luck so far.
I found another post that seems to mention the same problem as well. He mentioned having to change it in two places, 1: The web UI for the storage node, and 2: “a config file”
https://forums.fogproject.org/topic/6764/cannot-mount-ip-images-wrong-ip-is-used
However he doesn’t mention which config file. Any idea what file he may be talking about?
@george1421 Alrighty I will go ahead and install the location plugin and see if that helps — but I don’t think that is the issue here because there is no machine that actually exists at this IP Address (10.2.102.49). It is an old ip address from before we moved this machine. So it seems something needs to still be updated somewhere.
I found another post that seems to mention the same problem as well. He mentioned having to change it in two places, 1: The web UI for the storage node, and 2: “a config file”
https://forums.fogproject.org/topic/6764/cannot-mount-ip-images-wrong-ip-is-used
However he doesn’t mention which config file. I have checked interfaces, .fogsettings, dhcpd.conf, the tftp, and also the /tftpboot/default.ipxe config. No luck so far though. Any idea what file he may be talking about?
@george1421 I haven’t set the location plugin up yet – but that does seem really useful I will likely try to do that next
I found the below post which seems like a similar issue… however the IP address field has the correct value in my case. Is this value cached anywhere? I will try rebooting the fog master node and see if that helps
https://forums.fogproject.org/topic/8828/could-not-mount-images-folder-wrong-ip-setting/3
I actually don’t know where it is getting this IP… This particular machine has been moved in the past… so it may be possible that this is the old IP and it needs to be updated somewhere…
Any ideas where/what file this IP is being pulled from? I did a grep for it but had no luck…
10.0.88.49 was the DHCP / Storage Node. The fog management console is hosted at 10.0.88.42. I updated the default.ipxe file to point to the correct server and that fixed it! Thanks for the help with that
After a reboot on my client, I now get into the fog upload page and the process begins; but quickly terminates do to a mount failure for the /images folder. I am guessing it is a permissions issue? I am currently looking into but I figure you guys may have seen this one before so I wanted to ask real quick. Sorry for the spam of questions on this thread… I am getting really close to getting this working though it looks like
@george1421 apologies for the crooked picture. Also I can clear up those ip addresses for you
10.0.88.49 is the DHCP/TFTP/Storage Node on interface #1
192.168.1.1 is the router address for interface #2
This seems correct I think? The weird thing is the file/directory does exist when I browse to it via a web browser
(http://10.0.88.49/fog/service/ipxe/boot.php)
Hey thanks @george1421 !
I was actually temporarily pulled off of this project for a few weeks – which is why this thread is so old. I don’t believe I am the one you are referring to if it was a couple of weeks ago.
Good news — I made some edits to the ip tables and it looks like the connection is now working in both directions. So it looks like I am getting very close! Thanks for the help with that
I once again tried a capture, but I got the following error. Any ideas?
Also, I looked at the file in a web browser and it contains the following:
#!ipxe
set fog-ip
set fog-webroot
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
goto MENU
:alt_console
goto MENU
:get_console
console --picture http:///fog/service/ipxe/ --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
item --gap Host is NOT registered!
item --gap -- -------------------------------------
choose --default fog.local --timeout 0 target && goto ${target}
:bootme
chain -ar http:///fog/service/ipxe/boot.php##params ||
goto MENU
autoboot
Also, the following is the TFTP setting in the Web UI for my Fog master server: /var/www/fog//service/ipxe/
Okay, so it looks like the management password is the same for all storage nodes? So I think I have gotten past that, unless there is something that the install script does that I am missing with the manual add. I attempted to do a capture operation, and I am still having an issue. Do you guys see anything wrong with my dhcpd.conf file?
Quick Edit: After some playing around it looks like the client machines are being assigned an IP correctly, but are not able to access the internet. It doesn’t seem like a DNS issue neccesarily because I cannot ping individual IP addresses either. I can only successfully ping the DHCP server. (IPv4 forwarding has also been enabled) So it seems like there is still something wrong, but I am getting close. Any help would be appreciated, thanks!
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16;
use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
# option definitions common to all supported networks...
option domain-name "xxxx.xxxx.xxxx.com";
option domain-name-servers ###.###.12.30,###.###.12.8;
# Specify subnet of ether device you do NOT want service.
# For systems with two or more ethernet devices.
# subnet 136.165.0.0 netmask 255.255.0.0 {}
subnet 192.168.1.0 netmask 255.255.255.0{
option subnet-mask 255.255.255.0;
range dynamic-bootp 192.168.1.10 192.168.1.100;
option broadcast-address 192.168.1.255;
default-lease-time 21600;
max-lease-time 43200;
option routers 192.168.1.1;
next-server 192.168.1.3;
include "/etc/dhcp/worker-reservations.conf";
class "Legacy" {
match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
filename "undionly.kkpxe";
}
class "UEFI-32-2" {
match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
filename "i386-efi/ipxe.efi";
}
class "UEFI-32-1" {
match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
filename "i386-efi/ipxe.efi";
}
class "UEFI-64-1" {
match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
filename "ipxe.efi";
}
class "UEFI-64-2" {
match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
filename "ipxe.efi";
}
class "UEFI-64-3" {
match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
filename "ipxe.efi";
}
class "SURFACE-PRO-4" {
match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:Arch:00007:UNDI:003016";
filename "ipxe7156.efi";
}
class "Apple-Intel-Netboot" {
match if substring(option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";
option dhcp-parameter-request-list 1,3,17,43,60;
if (option dhcp-message-type = 8) {
option vendor-class-identifier "AAPLBSDPC";
if (substring(option vendor-encapsulated-options, 0, 3) = 01:01:01) {
# BSDP List
option vendor-encapsulated-options 01:01:01:04:02:80:00:07:04:81:00:05:2a:09:0D:81:00:05:2a:08:69:50:58:45:2d:46:4f:47;
filename "ipxe.efi";
}
}
}
}
As sebastian suggested, I did a new installation and selected full install instead of just a storage node, which allowed me to select the options to configure DHCP.
After a couple of manual tweaks, my clients/hosts are now successfully being assigned IP addresses. So that is good news!
However it looks like the full installation does not have an option to hook up automatically to my fog server (Which is not this machine). I can do it manually, but I don’t know of another way to obtain the management password for the UI. Is there a way to do this? I believe this is the last step before I have this all hooked up.
I hacked up a quick diagram of our setup if that helps at all.
