@cdutko

For the interface question you need to find out what your ethernet adapter is called, it may be called eth0 or it may be called something different. ip addr show may give you a better idea what your network adapter is called, just look for your known IP address.

As for the router issue, you can either change the IP address of the fog server or of the scope in your dhcp server. Changing the scope might be easier.

I had a long post here, but decided to be cautious first. Please post the output of ip addr show first.

I can’t find anything that explains the picture you posted initially other than there is a second dhcp server somewhere with a different next server (dhcp option 66) setting.

@cdutko yes your second modified settings are correct.

Updating the .fogsettings file and then reinstalling fog by running the installfog.sh command should take care of it.

@george1421 I would also confirm that the dhcp server config file is correct after the installer is done. As for the installer all of the settings from the .fogsettings file will be loaded in as defaults so it shouldn’t ask you for them again.

@lmioperations If you are following the wiki when you run the git command that directory will be created for you.

@lmioperations Well now you are set for the next update (lurking around the corner very soon). You will now return to the /root/fogproject and do a git pull and then run the installer again to freshen your installed image.

@lmioperations said in Fogupdater.sh "Attempting Download Failed" for all mirrors:

I was nervous about the install (based on the horror stories I was seeing in various communities online

Well that concerns me a bit there are negative posts out there. Yes there can be problems (especially when the linux distro changes stuff without notice), but that is why we are here in the fog project to help IT admins deploy FOG and help identify issues when they come up. FOG IS insanely complex using multiple other open source technologies. Its a delicate dance to keep everything in step.

Glad you have it going

@thebrennan47 After updating the .fogsettings file did you rerun the fog installer?

You have updated all of the places I know where to look, the bin/installfog.sh script should harmonize the settings again.

@Sebastian-Roth I kind of got pulled in a few different directions.

But the concept is to use grub to make an ipxe call. From grub we would use the menu that would look a bit like this

menuentry 'Quick Image' {
    set root='hd0,msdos1'
    linux16 /boot/ipxe.krn
    initrd16 /boot/qimage-initrd
}

Then the qimage-initrd would contain something like

#ipxe

param mac0 ${net0/mac}
param arch ${arch}
param username fog
param password password
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain -ar http://<fog_server_ip>/fog/service/ipxe/boot.php##params

Understand this is still a concept, but all of the bits look like they fit together nicely. That should provide the quick image menu for unregistered hosts.

@JLE said in Imaging across VLANS.:

10.241.96.0/19 (Vlan 300)

FOG Server info:
10.241.3.100/16

Something just struck me, hopefully there is a type-o here.

Your fog server is at 10.241.3.100/16 or subnet mask of 255.255.0.0, your vlan 300 is 10.241.96.0/19 (255.255.224.0). The issue is see is that subnet 10.241.96.0/19 is in the middle of the larger 10.241.3.100/16 subnet.

If this is true, I can understand why routing is not working and things are falling down.

{from discussion via IM}

I might assume this might get you pretty close.

@coh_is said in Dell OptiPlex 7050 fails to pxe boot:

Upon initial PXE connection the computer did receive an IP address, but the process terminated with the following message on the iPXE screen:
Configuring (net0 <mac address>)…No configuration methods succeeded (http://ipxe.org/040ee119).

Can you place a (dumb) unmanaged switch between the pxe booting computer and the building switch.

Your conditions tend to make me think you have spanning tree turned on (a good thing), but you are not using one of the fast spanning tree protocols (not such a good thing). Standard spanning tree takes 27 seconds to start forwarding data. By 27 seconds come around FOG has already given up trying to boot, yes its that fast…

@george1421 I was able to deploy the application with these settings

[0_1500920876828_Thumbs.db](Uploading 100%)

You can get the inits here, without upgrading to 1.5.0RC series. Here is the wget command to use from the FOG server’s linux console.

wget https://fogproject.org/inits/init.xz
wget https://fogproject.org/inits/init_32.xz

These files go in /var/www/html/fog/service/ipxe. Make sure you backup the current files before you update them with these.

With these new inits there is no need to use the postinit patch method I described below.

@Defcon I’m still of a mind to say that this is/could be a spanning tree issue. Can we assume both of these computers in the pictures above are on the same subnet in the same building?

Please test this idea by placing an unmanaged switch between the pxe booting computer and the building switch. Then pxe boot the computer. Confirm if you can get to the fog iPXE menu.

What you are experiencing is what we typically see when spanning tree ( a good thing ) is turned on, but is not configured for one of the fast spanning tree protocols (fast-STP, RSTP, or what ever your switch mfg calls it). Placing the unmanaged switch between the pxe booting computer and the building switch will keep that building switch port from winking as the pxe booting computer starts up.

If the firmware updates don’t help (I really hope they do for you), then we will probably need to see a pcap of the pxe booting process. This pcap will tell us what is flowing down the wire between the target computer, fog server and dhcp server. This process only works really well when the fog server, target computer and dhcp server are on the same subnet. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Upload the pcap to a cloud sharing service (google drive, dropbox, etc) and post the link here and we will take a look at it.

Will you check to see if this article applies: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

If you have unattended upgrades from ubuntu, that probably helped/broke your install.

Look at Method #2 here: (scroll down a bit to find it)
https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog

Different wimboot file but the same process. At first glance you are missing the alias names. Remember that case is important.

@george1421 The instructions are for pxe booting the MDT wim file, but also applies to any generic wim file.

When I say the alias I’m referring to these in the parameters section.

cpuid --ext 29 && set arch x64 || set arch x86
kernel http://${fog-ip}/wimboot
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/boot.sdi boot.sdi
initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim boot.wim
boot

Specifically the line
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD

Notice that after the file to load there is BCD in upper case characters. Those are the alias values I’m talking about.

@tom-elliott Confirmed the menu entry does work. You MUST PAY ATTENTION to the case of your path and file names (you can test with a browser to confirm you have it right). That tripped me up this time (yet again). There is the menu I used to pxe boot the WIN10 MDT LiteTouch install image.

cpuid --ext 29 && set arch x64 || set arch x86
kernel http://${fog-ip}/wimboot
initrd http://${fog-ip}/mdtboot/${arch}/Boot/BCD BCD
initrd http://${fog-ip}/mdtboot/${arch}/Boot/boot.sdi boot.sdi
initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim boot.wim
boot