@blindcat420 said in Cant pxe boot to fog.:
dhcp-boot=undionly.kpxe,<192.168.1.3>
Get rid of the greater than and less than signs around the IP address. That is part of the example <fog_server_ip> and should not be in the config file as <192.168.1.3> but as 192.168.1.3. Once you fix that dnsmasq service should start correctly.
@blindcat420 said in Cant pxe boot to fog.:
When I try to pxe boot from a laptop with legacy booting it fails and gives me pxe-e53 no boot filename received.
@Wayne-Workman You are right the next steps is to grab a pcap of the external laptop pxe booting. That pxe-e53 error is telling. The soho routers will typically post themselves as the next server with no boot file.
@blindcat420 Follow the instructions here and post the results in this thread: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
@Critchleyb said in Changing IP's on a portable FOG Server:
Is DNSmasq capable of pointing network booting at the server without editing any dhcp options on the router where it will be running?
Yes ^^
The quick steps are:
Install dnsmasq from your linux distro’s repo.
Use this config file. Save in it in /etc/dnsmasq.d as 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
Use the config file exactly. Replace <fog_server_ip> completely with the current IP address of your fog server.
Run these commands from your fog server linux console
sudo systemctl enable dnsmasq
sudo systemctl start dnsmasq
Depending on your linux distro dnsmasq may be called dnsmasqd.
@Kevin-Talbot We may need to turn this back over to the developers since it should not be doing what its doing.
Just for clarity, are you using the location plugin to direct the clients to the proper storage nodes?
@lschnider Also I’ve seen that date.timezone warning message before. I don’t know if that is something new with 1.5.5 or not. Can you confirm that this FOG setting is correct for your timezone: FOG Configuration->FOG Settings->General Settings->TZ INFO
@jjacobs When you plug those dongles into a windows computer and then go into the device manager. What hardware IDs are represented by each of those dongles. I’m looking for the hardware ID that look similar to this VEN_11C1&DEV_5811&CC_0C0010 for each model.
I get the impression you are using the FOG server as some kind of backup tool. If you are doing that, there are better (free) tools out there than FOG, such as Veeam Endpoint Backup (free).
There are surely risks in proceeding with your plan. Uncontrolled disc consumption is one that comes to mind.
@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.
@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.
@chanstag Your picture is interesting, in that after ipxe.efi there is an unprintable character shown as a block character. Make sure there isn’t any spaces or other junk after .efi in your router’s configuration.
It is also safe to assume the fog server is at 192.168.1.2?
If after checking your router settings and still are not having luck, we’ll get a pcap of the pxe booting process and look at what is flying down the network wires.
@gfontenot So let me understand. Did you change the IP address of the new FOG server since FOG was installed. I understand you copied over the old database so the database settings are wrong. You will need to update the FOG server IP address in the configuration settings page as well as the storage node pages. That should be it. If you changed the IP address of the fog server itself after you installed FOG then there are a few other steps. Even after updating the webgui settings you should rerun through the fog installer script again to resync everything.
After that is all done, if you are still getting a PXE boot error, take a clear screen shot of the error page with a mobile phone and post the picture here. The context of the error is almost as important as the error itself.
@cmyron Can you post a clear picture of the error taken with a mobile phone? The context of the error is almost as important as the error itself.
My intuition is telling me its a spanning tree issue, but it depends on where exactly this message appears. A spanning tree issue can be diagnosed by placing a dumb (unmanaged) switch between the target computer and the building network switch. If it boots and images correctly then its most likely a spanning tree issue, where the port isn’t using one of the fast stp protocols.
@blindhelix OK then make sure your kernels and inits on the usb are in sync with your fog server. You can get them from your fog server in /var/www/html/fog/service/ipxe directory.
@lxrsd I don’t know how to say this nicely, but you have soooooo many things going on here I’m not sure where to start.
How does this kernel update (4.9.137-0.1.ac.218.74.329.metal1.x86_64) have anything to do with FOG? Is that the kernel on the linux OS on the FOG server? That isn’t a FOS linux kernel release number.
I assume this bitlocker screen is on the target computer after its been imaged? If so, why is bitlocker been enabled before the image was captured? This will cause problem every time. You must disable bitlocker before image capture.
This is an invalid path initrd tftp://fog-server-99.lan14.test.com/tftpboot/fog/sccm/sccm.iso If anything it should be this initrd tftp://fog-server-99.lan14.test.com/fog/sccm/sccm.iso From the fog server linux command prompt I would check to see if the file exists with this command ls -la /tftpboot/fog/sccm/sccm.iso That should return the file and its size. If not your path is incorrect. The base path for the tftp server is /tftpboot. So that path should not be listed in the ipxe initrd command.
Understand that memdisk only works for BIOS based systems and not UEFI. If you are trying to boot a uefi system that ipxe menu line will fail.
@lxrsd Well again you have a lot going on here. So much so its not clear what your problem is.
If your issue is not being able to boot the sccm.iso I can see why
You have this section in your menu
:SCCM
initrd tftp://FOG-FQDN/SCCM.iso
chain memdisk iso raw ||
goto MENU
But according to yourls command the files are in /tftpboot/fog/sccm/sccm.iso Also SCCM.iso != sccm.iso. In linux case is important.
If it was me I would update your sccm section to look closer to this.
:SCCM
initrd tftp://FOG-FQDN/fog/sccm/sccm.iso
chain memdisk iso raw ||
goto MENU
If the bitlocker bluescreen is your issue then that isn’t fog’s issue. That is related to bitlocker being activated when the image was captured. Bitlocker is doing what it should and stopping disk access on a system where the tpm chip doesn’t match the encryption key. That is kind of the point of bitlocker.
Really what you are doing with this hand crafted ipxe menu, you could do with the FOG iPXE menu and the menu editor. I would have to look into why you are chaining to pxelinux instead of just using the more capable iPXE boot kernel, but your setup might be a bit more complex than needed.
@george1421 said in Cannot reach Dir -> Bitlocker prompt right After. Help!:
tftp://FOG-FQDN/fog/sccm/sccm.iso
You could also test to ensure you have the right path with a windows computer. Just install the tftp client feature, then open a command prompt and issue tftp <fog_server_ip> GET fog/sccm/sccm.iso (note that command syntax is from memory, it may not be 100% accurate). What we are testing here is does it download the file. If so then you know you have the permissions setup correctly and the file exists at the path provided.
@Aki-Heikkinen What dhcp server are you using?
Is the issue that the dhcp name is wrong, or is it the dns name is wrong? After the system is renamed and rebooted, does the dhcp name still stay the old system name?
The issue with releasing dhcp should be already addressed “during imaging”. If you look at this website: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/K40network This is the network shutdown script for FOG.
You will see at line 9 it releases dhcp with
/sbin/udhcpc -i $iface -R
Upon the first boot of Windows 10 while Windows Setup is running, the system is given a random name by WinSetup/OOBE. Once OOBE is done and the FOG client is restarted, the fog client will rename the system and then reboot. Once WinSetup starts then FOG Imaging is not involved other than the FOG Client. IMO this is a windows issue if the name sticking in dhcp is this windows made up initial name and not its real system name. But again without knowing all of the details I can only guess.
@Gamienator said in How can I troubleshoot the Diskusage Problem on the Webinterface?:
1 VirtualHarddisk with 50 GB on a SSD for the OS (sda)
1 VirtualHarddisk with 450 GB on the other SSD for the Imagespace on “fast” storage (sdb)
1 VirtualHarddisk with 900 GB on the HDD as a archive (sdc)
My Idea was: Image everything in SSD (mounted on /image1) and replicate on sdc to have a backup. For the moment! It’s all Work in progress, RAID card is on the way to have a RAID 1 with the SSD and so on.
For your sanity with this design I would make the SSD mounted over /images instead of /images1. As for FOG it doesn’t / shouldn’t care about the HDD. That is not in scope of FOG. BUT you can implement pretty easy with a CRON job (think windows scheduled task) that runs rsync to clone /images to /images2. That way you have your backup and fog won’t care.
In addition to the picture, lets grab the ipxe menu. Key in the following into your browser, replacing the <ip_address> with the address of your fog server.
http://<ip_address>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00
That will spill out a wall of text. That is the iPXE menu commands, post that results here in a code block so we can see what’s wrong with the advanced menu.
@Scott-B Well somewhere along the way there is no advanced menu defined. We are going to need the @Developers to look at the code in the FOG configuration page to why that field is hidden in 1.5.5.3 (it works in 1.5.4). Then you can rebuild your custom advanced menu again.