Posts made by george1421

In regards to the dhcp relay: Lets assume you have a main dhcp server at the HQ site and also dnsmasq at HQ. For the HQ site the dhcp server and dnsmasq server are in the same broadcast domain. So the dnsmasq server hears when some device requests a dhcp address. This is the design. Now when a client at a remote site requests a dhcp address the dhcp helper agent hears the request and forwards it to the dhcp server. Since this communication is a unicast communication the dnsmasq server doesn’t hear the dhcp request so no additional information is supplied.
The solution to this is to add your dnsmasq server as the last dhcp server in your dhcp relay chain. You don’t want dnsmasq to supply the dhcp address only to be aware that a dhcp request was made and to supply the missing dhcp settings to the remote client via the dhcp relay.

I know that was a lot of words to just say, add your dnsmasq server last in your dhcp=relay configuration. As for the dnsmasq configuration, I don’t know the exact settings only that it should work.

@t1pt0p the problem is that stp IS enabled. You need to enable a fast stp protocol. The quick test is to put an unmanaged switch between your building switch and the target computer.

If you have stp turned on, then look for port fast, fast stp, or rstp and turn it on on the target computer port.

@dureal99d said in How to pxe boot cent os 7:

HOw would I make the nfs mountable?

Understand this is beyond the scope of what the FOG server supports. That doesn’t mean that you can’t do this with FOG, its just not supported by the FOG project.

You might want to explain exactly what you want to do here? Do you want to pxe boot a linux live environment with iPXE or do you wan to pxe boot a linux installer via iPXE? The answer may provide a better direction.

IMO it would be easier to use an already exported NFS filesystem like /images Just create a subdirectory below /images (like /images/centos) then update your iPXE configuration to use that share instead of an http nfs root.

Edit - Typo fixed.

@juice381 said in Making Fog Portable:

I would like to get this working in debian as well though, as I am much more comfortable navigating that environment.

This probably would not be a bad decision in the long run either. Since debian on the ARM processors is very popular. The hardest part is getting fog installed on an arm processor and working well. The rest is just config files that need to be updated for portability.

I would have to ask, what is your primary antivirus tool that is on these windows 7 targets?

@juice381 said in Making Fog Portable:

ODROID C2

Warning this post is off-point: I have not used an odroid device before, but I have used a raspberry pi. IF you are going to use the onboard micro sd for storage, used a good quality class 10 or uhs-1 device if you want any speed out of your device. I initially made the mistake of just going to the local big box store and picked up a cheap micros SD card. My first impression of the pi as it was junk, and unusably slow. After doing some research I decided to replace the sd card with something faster. Once I replaced the boot media with a samsug evo micro sd card the pi came to life. Depending on the number of images you need, the micro sd card may be all you need.

well the first one is stopping probably because you are telling it the nfsroot is an http path not an nfs mountable path. The protocols are different.

In your second section does /fog/kickstarts/centos6.cfg exist? But you are booting centos 7??

Here is a guide for pxe booting centos 7 that may get you closer. http://www.tecmint.com/install-pxe-network-boot-server-in-centos-7/

Your imgargs approach is right for additional kernel parameters. Also I would avoid the || read void tags at the end remember you are dealing with an iPXE boot loader and not syslinux. I would also move your files out of the /fog path. You have an apache web server create a new parent directory called /bootimg or what ever and put your boot OS files under that like /bootimg/centos (also watch your case, its easier to use all lower case).

If you want to see how the FOG developers download the FOS kernels you can key in http://<fog_server_ip>/fog/service/ipxe/bootp.php?mac=<registered_device_mac_address> You will see the kernel args and structure that iPXE needs.

@MattPayerle Thats great you have it working (sort of).
I’m sure you know this already, but I will state it again. Make sure the FOG service is disabled in your reference image before you sysprep it. Then use the setupcomplete.cmd file and sc to reenable the service. That keeps the fog client from starting its job too soon in the OOBE process.

@Wayne-Workman said in Chainloading Failed - Fog Menu - Boot HD:

@Motech09 The default exit type (which is Sanboot) doesn’t work for that particular computer.

@Wayne, Ah your midnight mind reading classes are working. Nice job!!

OK we need a bit more info, and a possible recommendation that you update to the 1.3.0 RC series before we do too much debugging.

What is version 13, is that fog 1.3.0 (something)? Since the svn versions became disconnected from the git version I can’t tell if that is current or not.

More to the point of your question, is this a uefi or bios (legacy) based target computer? Also please include the mfg and model number of the target computer.

The FOG client needs to be included in the reference image (with the service disabled) before you capture it. Posts deployment you would use the setupcomplete.cmd file to reenable the service. This keeps the fog client for executing commands to early in the OOBE install process that causes an install failure.

With that said you can include (inject) the fog client install post imaging with a fog post install script. This script would (in concept) copy the msi from the fog server to the target computer and then append the msi install commands to the setupcomplete.cmd file that will be executed once the OOBE process is complete. But the FOG server does not do this out of the box.

@Wayne-Workman OK to state where we are (still not happy but…)

We’ve got past the pxe booting and are now at the exit mode for uefi

I would like you to unhide the FOG iPXE menu for a few tests. I want to ensure that you can make menu selections and have the target system function correctly. What I’m interested in is the compatibility test, check for both network and storage media. I also want to ensure that you can register a target computer using the ipxe menu. If you can do that then the target and fog communications are working well.

The part I think is failing is the exit mode for these devices to boot from the devices internal media. But lets take one step at a time and test each bit then work on the exit modes (usually what causes the most pain once you get the FOG iPXE menu to display).

OK scratch that, I missed the post with the error about the storage node.

@rghawk said in FOG won't complete when reimaging a computer.:

Just meaning while in the process of doing a reimage(progress bar and percentage going across the screen in the blue, gray, and red screen) it will just stop and restart. Then after it restarts, the computer says Boot selection failed because of a required device is in accessible.

Just to be clear you are talking about the partclone (or what ever FOG 0.30 used) screen that is transferring the image from the FOG server to the target computer. At this point OOBE or windows setup program has not started.

So this might point to the fog server since you are saying that all target computers are doing the same. Check to see if you are out of space on the fog server storage disk or if you have a corrupt storage volume.

@Wayne-Workman said in FOG Client Service Updater:

If you go the PDQ route, be sure to include some way to first remove the legacy client. If it’s still there, the new client will not install.

Following Wayne’s instructions then you should create a batch script and deploy that with PDQ Deploy.

In that batch script you will issue the FOG client uninstall command

@echo off
msiexe /X <guid of fog client>

REM then install the new FOG client with 
msiexec /i fogclient.msi <what ever option switches>

@arton Just for clarity what were you trying to do when it created this menu? Were you trying to boot an unregistered device into the FOG iPXE menu or were you trying to deploy to this device?

The reason why I ask is that this menu isn’t complete. It has more lines than I expected but it isn’t what I expected. We may need to have the developers look at this.

I would have expected something like this based on the command I gave you

#!ipxe
set fog-ip 192.168.1.88
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://192.168.1.88/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0x00567a 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is NOT registered!
item --gap -- -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.reginput Perform Full Host Registration and Inventory
item fog.reg Quick Registration and Inventory
item fog.deployimage Deploy Image
item fog.multijoin Join Multicast Session
item fog.sysinfo Client System Information (Compatibility)
item mdtlti.x86 MDT LiteTouch x86 Boot
item winpe7a WinPE tester
choose --default fog.local --timeout 3000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 rootfstype=ext4 loglevel=4
imgfetch init_32.xz
boot || goto MENU
:fog.memtest
kernel memdisk iso raw
initrd memtest.bin
boot || goto MENU
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 rootfstype=ext4 loglevel=4
imgfetch init_32.xz
boot || goto MENU
:fog.reginput
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 mode=manreg
imgfetch init_32.xz
boot || goto MENU
:fog.reg
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 mode=autoreg
imgfetch init_32.xz
boot || goto MENU
:fog.deployimage
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:fog.multijoin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param sessionJoin 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:fog.sysinfo
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.1.88/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU
:mdtlti.x86
initrd http://192.168.1.88/fog/iso/LiteTouchPE_x86.iso
chain memdisk iso raw
:winpe7a
initrd http://192.168.1.88/fog/iso/winpe_amd64.iso
chain memdisk iso raw
:bootme
chain -ar http://192.168.1.88/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot

Since you are running ubuntu can you tail the apache error log. I think its called error.log.
One last question, was this system upgraded or did you install it new?

@Joe-Gill You can push out the client (or any msi or exe with an unattended installer) with PDQ Deploy. The free version will work for you. All that is required is the MSI and having/knowing the an account on the target computer that has admin rights. It will take you about 30 minutes to setup pdq deploy and create and deploy your first package. Its not a real big time sync. You can deploy to each machine you define, by machine OU or a custom list you can create. Its pretty flexible.

I do have to say the paid for version is well worth the cost. With the paid for version you can download already created packages for common software as well as create multi step intelligent install scripts (ie switch installers based on target system bits x86 vs x64).

@arton This last picture is what I might expect to see from pxe booting a bios (legacy) system with undionly.kpxe (not an uefi boot, it doesn’t matter but just trying to set the context). Is this the case? I’m still getting the impression that your install is broken.

What I want you to do next is to (with a web browser) key in http://192.168.15.187/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 and post the results here. Ideally this should display the FOG ipxe boot menu in its entirety (> 20 lines of stuff). If you get 3 or 4 lines and that is it, then we will need you to post (tail) the apache error log because something is broken.

@arton that’s very strange why the tftpboot directory is that why. Your screen shot contains what I would expect in the /tftpboot dir

Did the fog installer run to completion? Please run the installfog script again. If you are using a Debian based Linux you will need sudo then installfog.sh.

@asbenavides said in Failed to obtain lease on eth0 after ugrading to Fog 1.3.0:

@george1421 I also tried a newer dell model 7020 and its doing the same issue as well.

That’s because I feel its a network issue (i.e. outside of FOGs control). The issue is proving its a network issue that is the tough part. Typically installing an unmanaged switch between the target computer between the target computer and the building switch will mask this issue, but it helps us point to the building switch at fault. Since all devices are doing this tells me it (the problem) is in common to all devices and all locations.

Another way to test is to plug the fog server and the target computer into an unmanaged switch and then plug the unmanaged switch into the building switch. Test this setup. If this works, then you will need to get a network engineer involved to look at your switch infrastructure.

@arton Well that’s not right for 1.3.0-rcX series. Did you upgrade this install from a previous release? This looks a bit like a FOG 0.30 tftp directory.

How did you install 1.3.0? I assume you downloaded the installer from git or svn, then did you run the installfog.sh script in the bin directory?