Posts made by george1421

@vince-villarreal Two other points.

You can build a usb boot drive with iPXE, but again that still relies on dhcp having the right settings to instruct ipxe on how to find the fog server.

You can also build a FOS usb boot disk, that will boot you right into FOS bypassing PXE altogether. But there are some caveats with this approach. If you can overlook the caveats and just want to capture and deploy (no multicast, no direct imaging from iPXE menus, etc) it will work for you.

One last comment, fog doesn’t like it when/if you change the IP address of the fog server once the FOG management console is installed. There are work arounds, but its best to have it at its assigned (forever) address when you install FOG.

@vince-villarreal Well if you have a soho router you can still make pxe booting work pretty easily. Just install dnsmaq on your fog server. Your soho router will supply dhcp IP addresses and dnsmasq will function as proxy-dhcp server and only provide pxe boot info. It works really well.

1. Install dnsmaq on the fog server from your linux distro’s repository.
2. Make sure you are running dnsmasq version 2.76 or later sudo dnsmasq -v
3. Create a new file as /etc/dnsmasq.d/ltsp.conf
4. Paste this config file into that file (ltsp.conf)

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP>

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi

dhcp-range=<fog_server_ip>,proxy

5. Be sure to replace <fog_server_ip> exactly with the IP address of your fog server. Be aware that that string appears in multiple places.
6. Start/restart dnsmasq
   sudo systemctl restart dnsmasq
7. Confirm its running in memory
   sudo ps aux|grep dnsmasq
8. Ensure it starts on every reboot
   sudo systemctl enable dnsmasq

That should be it. PXE boot your target computer and it should connect you to the fog IPXE menu.

@TheDiskDrive said in Create UEFI ISO and prepare Surface go deployement.:

but sadly this seem not working even with the efi iso from netboot.xyz

Don’t use this netboot thing. On your fog server in /tftpboot directory grab ipxe.efi. Move that to a usb flash drive in the correct directory and renamed correctly. This will work.

I have a tutorial on this: https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

If you are going the other path building the usb bootable FOS image. I can give you a jump start if you need. Look at the fog forum chat bubble.

@Beber55 sorry for the delay I have meetings here all day.

From a windows computer, install the tftp client feature. Connect the windows computer to the isolated imaging network. Then from windows command prompt key in: tftp 10.10.10.10 GET ipxe.efi . This will test if the ipxe.efi file can be downloaded from the FOG server to the target computer. In this case we only want to test if it downloads.

If that works then we will need to do a bit more debugging.

One last idea, make sure the firmware (BIOS) is updated to the latest on the target computer (hp elitebook 840). That will make sure any fixes are on that hardware before we go to the next step with testing.

So do I understand that the fog server is on an isolated imaging network and the FOG server is configured as the DHCP server for that isolated network?

If the FOG server is managing DHCP then it will send the right boot file name based on the pxe booting computer unless you adjusted the dhcp server configuration files by hand.

For BIOS (legacy) the boot file is undionly.kpxe for sure. For UEFI computers the boot file is ipxe.efi. It looks from your boot screen picture that its unable to load ipxe.efi. You can not mix these boot files. A uefi boot file (ipxe.efi) will not start on a bios (legacy mode) computer. The same the other way to.

With UEFI computers, make sure that secure boot is disabled in the firmware (BIOS) setup pages.

What part is not working? That structure should be supported. UEFI is pretty simple as long as the boot file is in the right location and named correctly. Does the iso image show as a bootable able disk in the UEFI boot manager, or with the dell laptop via the F12 boot manager? If the ISO/DVD is uefi bootable it should show up in the list.

Instead of creating an ISO DVD file, you could do the same with a usb flash drive.

If you can’t get this method to work I do have an alternative method to usb boot into FOS.

@besa said in [Solved] FOGProject Tecnical Info:

Its not for a paper, but for recommendation. My brothers supervisor wanted to take a look to the {Company}… and they use old fog system[1.2.0].

Just be aware that FOG 1.2.0 is really old. It doesn’t support win10, uefi, gpt disks, and current hardware. If you are imaging older stuff then it will work OK for you. But if you are going to need anything I mentioned, you will need a more current release of FOG. FOG versions newer don’t need fogcrypt since its all built in now.

lets start out by understanding why you are usb booting into the iPXE menu. What problem are you trying to get around?

which is a MUST for me since I have the option to type in my fog server IP

This tells me it working, but your dhcp server isn’t sending out the right information to go to the next step.

FOGCrypto is and old program used to encrypt password so they could be saved in fog. Not really of value for a cyber security student to write a paper on.

On a whole fog is not very secure because it uses many older protocols like NFS v3 and http (vs https). There is still some very old code in FOG that was written when security wasn’t really a topic. In the context of cyber security there are many reasons to not use FOG in vulnerable environments (if you were looking for a different entry point to discuss). Understand I’m not saying anything bad about FOG, but it was originally written in different time and space.

The developers are slowly working on FOG 2.0 code base that was built from the beginning with cyber security in mind. That release is still a while off at the moment from being realized. But the baseline stuff that has been done so far looks really great.

@AndrewG78 said in Tablet with WINDOWS 10 and USB-LAN SMC 7500 adapter:

Are there any news regarding refind_ia32.efi?

@Sebastian-Roth if refind_ai32.efi is included (I think it should be), then the ipxe menu will need to be reworked a bit to take that into account. Right now everything calls refind.efi. I think a simple test using the arch parameter could redirect the call to refind_ai32.efi vs refind.efi. I had it worked out a bit ago, but that fell off the table too.

@AsGF2MX said in Compatibility check for X1 Carbon 2018:

Well I’m now at the USB method and @george1421 thanks for the img. I got the usb to work. However I can’t remember the cli for the fog command. and the wiki page has the deploy section empty.

Not sure why you need the debug command. You should schedule the task in the FOG server then usb boot the flash drive. Pick option 1 and it should boot into fos doing what ever the FOG server told it to do (capture/deploy).

@AsGF2MX Well where we have seen this issue before is in then hand off between iPXE mode and the uefi firmware to launch the kernel. You could try newer iPXE kernels that may have a workaround for buggy firmware. Typically a firmware update fixes the issue. But if you have the latest firmware we need to look elsewhere.

As an alternative, you could switch the device back to bios (legacy) mode for capture and deploying. I know its a bit of a pain, but that method works too. You can capture and deploy a uefi image in bios mode no problem. You just have to be in the right firmware mode to boot the OS.

While this isn’t a solution (and not sure if it worked in 1.3) we have been able to usb boot right into FOS bypassing PXE loading altogether. There are some caveats with this approach but it does work (for sure) with the 1.4.x branch. https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image Look at the FOG forum chat for an example image file. You will want to install the kernels and inits from 1.3.x series on the usb flash drive as well as update grub.cfg according to the tutorial to see if it works for you.

One last thing I thought of, make sure secure boot is disabled. The FOS kernels are not signed by microsoft so secure booting is not viable right now.

Is there any chance to spin up a FOG 1.5.5 environment to see if the issue has already been resolved. 1.3.0 is somewhat old with old kernels and inits. Updating the kernel is not sufficient since you need the later inits too which are linked to the updated FOG server code.

X1 Carbons (i7-vPro) 2018 and right after the ram disk downloads
Can you explain this? is the ram disk you are talking about is the FOS init.xz file? Ensure that the firmware is up to date on the carbon devices. We’ve seen some pretty buggy firmware on early release systems that are addressed with firmware (BIOS) updates.

@Sebastian-Roth Well done. If we can filter these issue out at the beginning it will make support easier trying to figure out why this isn’t working… ;-)

@george1421 Just wondering is this fog client computer you are trying to USB boot registered in FOG? If so delete the registration and see if it throws the same error.

@hancocza OK that tells us that boot.php code is working on the fog server. That is the complete iPXE boot menu. So we know its not the fog server causing you pain.

So you haven’t changed the fog default.ipxe, boot.php is working because the menu is created when you call it from a browser.

so the question is what is being passed that is causing boot.php to return an invalid ipxe menu.

The next step is to usb boot again and get the error. Then inspect the apache access log, error log, and php-fpm error log files. These are typically in /var/log directory.

@hancocza Ok just to be clear you haven’t changed anything in FOG’s default.ipxe other than http and https?

What do you get if you key the following into a browser?

http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:01

That should give you a screen of text, which is the FOG ipxe menu.

@hancocza OK so we now know how you got here.

Looking at your picture its making a http call to boot.php. You made reference to using https? You are still at the ipxe prompt so something happened with the chain to boot.php

@hancocza If you are calling boot.php directly from your usb drive then you are not passing any parameters. That is the problem. If you look at the default.ipxe file in /tftpboot of the FOG server you will see what parameters its passing (like mac address, arch, and so on).

Just to save you time:

#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://192.168.5.22/fog/service/ipxe/boot.php##params

[edit] just for clarity thats from FOG 1.5.4. I haven’t installed 1.5.5 into production yet.

@hancocza If you look at the github site I referenced this is the ipxe script.

#!ipxe
isset ${net0/mac} && ifopen net0 && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck

:dhcpnet1
isset ${net1/mac} && ifopen net1 && dhcp net1 || goto dhcpnet2
echo Received DHCP answer on interface net1 && goto proxycheck

:dhcpnet2
isset ${net2/mac} && ifopen net2 && dhcp net2 || goto dhcpall
echo Received DHCP anser on infterface net2 && goto proxycheck

:dhcpall
dhcp && goto proxycheck || goto dhcperror

:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:proxycheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck

:nextservercheck
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

:netboot
chain tftp://${next-server}/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

It would be a trivial task to remove the dhcp bits and hard code in the IP address of the FOG server. You would have to recompile the ipxe boot loaders, but it would stop you from having to manually do stuff.

In your case look at the chain line of the ipxe script it called default.ipxe on the fog server and not boot.php directly. the default.ipxe on the fog server picks up several needed parameters that gets passed to boot.php. Without then boot.php gets lost.