Posts made by george1421

@chris178 There is a right way to do this and an easy way.

Easy route.

1. Download both .sh files to your FOG server.
2. Then make both executable. by running this command chmod 755 *.sh
3. Install the script by running ./install.sh
4. Done.

@jphipps I’m having a hard time believing a kernel update fixed it, but if you have it working then job well done!!

Is it safe to solve this thread?

@jphipps well if you hit enter a few times at the screen with the text it should drop you to a linux command prompt

At the FOS command prompt key in cat /proc/cmdline and post the results here. My bet is that isdebug=yes is in the kernel parameters.

Make sure you don’t have a lingering task that someone has scheduled, where someone was doing a debug capture or deploy.

@jphipps Just so I’m clear, every time you boot into FOG you get the first screen?

This is telling me you setup a capture / deploy with debugging enabled - OR - someone setup a global fog kernel parameter where isdebug=yes

@jphipps Can you give us a clear screen shot of the error taken with a mobile and when exactly in the pxe booting process it pops up?

If you are building your own custom kernel then we can’t help you.

The 3570s should be similar to the 7270s, which I can tell you works. The grub menu is a bit troubling (if this is truly a grub menu since that is only an option of iPXE exit).

Typically the exit mode for bios systems is sanboot and the exit mode for uefi systems should be rEFInd.

@predator You are adding a little bit of complexity because you are using a type-2 hypervisor.

The requirements for FOG are the same.

1. FOG server must have a unique static address that is not changed after FOG is installed.

2. The target (client) computer must have its IP address assigned by dhcp, because that is the only way it can find out about the FOG server to boot from.

@predator You have this incorrect.

1.VM Host = leave network settings on dynamic
2.VM Guest = configure network settings on static
3.FOG Client = configure network settings on static

This should be,

1. VM Host = Must be unique, but don’t really care. Not used by/for fog
2. VM Guest = configure network settings on static
3. FOG Client = dhcp

@tywyn said in Changed IP of Fog, dhcpd is not starting anymore...:

isc-dhcp-server.service

You can / should also issue the start and stop commands manually
systemctl stop isc-dhcp-server.service
systemctl start isc-dhcp-server.service
To see if you can collect any additional information too.

Also lets see your complete dhcp.conf file. If what you posted is it, you are missing some bits (and the trailing curly brace })

(OK now this time using some intelligence). In the same directory where the installfog.sh script is, there is a log directory. In that directory should be a log for each installation you have done. Review the install logs to see why dhcp isn’t happy.

I would start with updating the hidden config file in /opt/fog/.fogsettings.

Then there are 3 places in the webgui where the IP address hides. There is 2 in the fog system settings in the web server and tftp server sections and then in the storage node configuration for the master node. Fix those locations then rerun the fog installer (./installfog.sh) script. I know its a pita to fix but fog doesn’t like its IP address changed post installation. If you are creating a mobile fog server then there is a script to manage this process for you.

OK forget that post. I did not read careful enough.

@julianh A SSD for only the OS will not add much value making FOG go fast. The critical data path is from /images -> nfs -> network -> target computer.

This is true. In the current release of FOG NFS is used to transfer the images from the fog server to the target computers. This needs to be open for the target computers to be able to read the images. You can restrict mounting the nfs share to a specific subnet, but that is it as of now.

While this version is still a years off, FOG 2.0 will have security built in from the start. But that isn’t here today.

I started doing some benchmarking on making fog go faster here: https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast
Warning: that post has a ton of data in it as I tried to document each step

I ran out of extra time to work on it consistently. There are benchmarking numbers in there. If you have a single hdd disk in your fog server AND you are trying to deploy multiple unicast images to different computers at the same time a ssd in the fog server will help quite a bit.

For fog to go really fast you need 4 things.

1. Fast disk subsystem in fog server (helps greatly when sending out multiple simultaneous images at the same time)
2. Fast network infrastructure
3. Fast NFS configuration
4. Fast target computer

@sebastian-roth said in Hp Elitebook x360 G2 Boot Problems:

If snp.efi is working for you, then just use this for those clients.

Since the OP is using dnsmasq we might be able to do this automatically. It does require a little detective work with dnsmasq. I’m hoping the uuid for this class of computers is populated and consistent for this hardware.

@crixx if you can pxe boot one of these HP computers then look in the dnsmasq log for a uuid value. Record that and the pxe boot another one of these computers. Then please post the results here and we can work up a filter for you.

Ref: https://forums.fogproject.org/topic/8726/advanced-dnsmasq-techniques

@kellyg said in Failed to get an IP via DHCP!:

the switch I’m using has been wiped (although I suspect something is still enabled on it).

The issue is a wiped switch will typically have spanning tree enabled by default. It depends on the switch mfg, but most of the time its a good then to have spanning tree enabled. So your suspicion is probably spot on.

Here is one way to go about it.

1. Acquire a usb flash drive that is at least 4MB in size (yes I said only 4MB, larger will work but we only need 4MB of space).
2. Format that usb flash drive - fat32. You can do this on a windows box or a linux box. The format must be fat32.
3. On that newly formatted flash drive create the following path \EFI\BOOT (case should not be important, but use all caps as I posted).
4. Now you will need 2 of the iPXE files from the fog server.
5. Copy /tftpboot/ipxe.efi to \EFI\BOOT as BOOTX64.EFI
6. Copy /tftpboot/i386-efi/ipxe.efi to \EFI\BOOT as BOOTIA32.EFI
7. Eject the usb flash drive and then attempt to boot this Dell laptop device from the usb drive using the device’s boot menu.

Taken from here: https://forums.fogproject.org/topic/7435/uefi-pxe-boot-asus-t100-tablet/79

What we will be doing is bypassing the on board pxe roms and loading iPXE right from usb flash drive. Understand this method will only work if iPXE has the drivers built in for this usb network adapter. If this route won’t work for us we have one more last chance option.

@fredlwal Does the network adapter support pxe booting?

For uefi mode, the uefi firmware needs to support the network adapter for pxe booting to be allowed. This means you need to get a network adapter that is supported by the firmware (hint: provided by the computer manufacturer and said to be supported).

We have some other options that as not so nice but might work. If the laptop is in uefi mode there is something that we can do pretty quickly.

@george1421 This method failed. By removing the alias name and using the -n instead. Wimboot threw an error and failed to boot.

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

@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