@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.
Best posts made by george1421
-
RE: Issues With DHCP and PXE Booting on an Isolated Network
-
RE: Fogupdater.sh "Attempting Download Failed" for all mirrors
@lmioperations If you are following the wiki when you run the git command that directory will be created for you.
-
RE: Fogupdater.sh "Attempting Download Failed" for all mirrors
@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. -
RE: Fogupdater.sh "Attempting Download Failed" for all mirrors
@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
-
RE: Problems after updating fogserver IP Address
@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.
-
RE: Laptops with no integrated NIC any decent solution?
@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.
-
RE: Imaging across VLANS.
@JLE said in Imaging across VLANS.:
10.241.96.0/19 (Vlan 300)
FOG Server info:
10.241.3.100/16Something 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.
-
RE: FOG - Single Snappin
{from discussion via IM}
I might assume this might get you pretty close.
-
RE: Dell OptiPlex 7050 fails to pxe boot
@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…
-
RE: FOG - Single Snappin
@george1421 I was able to deploy the application with these settings
[0_1500920876828_Thumbs.db](Uploading 100%)
-
RE: Invalid entry length (0). DMI table is broken! Stop.
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.
-
RE: Unable to PXE boot on from different subnet
@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.
-
RE: PXE-99 FileSize 0 error
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.
-
RE: database schema installer / updater
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.
-
RE: Unable load winpe.iso
Look at Method #2 here: (scroll down a bit to find it)
https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fogDifferent wimboot file but the same process. At first glance you are missing the alias names. Remember that case is important.
-
RE: Unable load winpe.iso
@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 BCDNotice that after the file to load there is BCD in upper case characters. Those are the alias values I’m talking about.
-
RE: Unable load winpe.iso
@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
-
RE: Replication issue between Master node and Storage node
@sebastian-roth I need to fill in a bit of detail here. I helped Hugo setup a partitioned FOG Master server. This is where he has some images in /images and other images in /images2. There is a storage group associated with each images container where the full fog server is the master node in each storage group. From what I gather the storage group that points to /images is replicating just fine to its storage node. But the storage group connected to /images2 is not replicating to its storage node.
@Hugo What we would like to see is a screen shot of “Storage Management -> All Storage Nodes” page. This will tell us if you have the proper grouping right.
We would also like to see your master node configuration for the /images2 container.
-
RE: PXE Boot Issues
@donutsrule5 Just for clarity, (choosing ipxe.kpxe isn’t a bad decision) the undionly,kpxe driver is the most common used because it uses the undi driver built into each network card. This driver supports the most network adapters because almost all network drivers have undi built in. With that said some implementations of undi is broken which cause undionly.kpxe to fail. The kernel ipxe.kpxe contains all of the known drivers provided by the iPXE group. So this kernel “should” work on all of the common network interfaces.
-
RE: DHCP server doesn't see the client request
Please confirm that FOG Settings->Web Server ->FOG_WEB_ROOT is configured correctly. It should contain
/fog/
This also could be a spanning tree issue in that standard spanning tree is enabled and not one of the fast protocols (RSTP, MSTP, FastSTP, etc). But you should see this earlier in the process.
This error above usually relates to the dhcp client not being able to reach the FOG server during FOS booting. It will typically do this process 3 times and then give up.
udhcpc: started, v1.26.2 udhcpc: sending discover udhcpc: sending discover udhcpc: sending discover udhcpc: no lease, failing udhcpc: started, v1.26.2 ...
Its a bit misleading in that the target computer may be getting a dhcp address but unable to reach the fog server for some reason.