Posts made by george1421

Well I see a conflict here. I see you have isc-dhcp server loaded in your configuration AND you are using dnsmasq. Which one do you want to use?

In regards to dnsmasq first confirm you are running dnsmasq version 2.76 or newer by keying this into the fog server linux command prompt. dnsmasq -v Hopefully the response looks like this:

Dnsmasq version 2.76  Copyright (c) 2000-2016 Simon Kelley
Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify

If so then please use my ltsp.conf, completely replacing yours.

# 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

Don’t forget to replace the <fog_server_ip> tags with the IP address of your fog server.

Ref: https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support/5

Now for the isc-dhcp server. You need to decide what really will be your dhcp server for the subnet where the fog server is. It can be the fog server if you are imaging on an isolated network, or it can be your building dhcp server if you want to image using your existing infrastructure.

If you have an isolated imaging network then you can use isc-dhcp server for everything, dnsmasq is not required and will actually confuse things. If you want to image on your current production network and your production network dhcp server isn’t capable of sending out the pxe boot options, then you can use dnsmasq in concert with your existing dhcp server.

You just need to pick a path and we can help you get there.

Just for clarity. When quick registration, and imaging are running you see text on the screen but when you select full registration nothing is visible??

I would also have to question your kernel, where did you get 4.13.4 from? The current newest supported kernel for FOG 1.4.4 is 4.11.6.

@adukes40 Can you explain a bit more about your network? Why are AP’s handing out DHCP addresses? Are you using consumer APs in your network?

A pcap will tell you a bit more about what is going on. I can tell you we had issues (many moons ago) with 780 and 790 with spanning tree enabled on the building switch (with and old netgear switch). We finally found that we needed to enable fast spanning tree on the switch port. Actually the device was not getting a dhcp address during pxe boot, but via windows it was working fine. Not saying that this is your case here, but you might want to ensure that its not a spanning tree issue either. Placing an unmanaged switch between the computer and the building switch is a quick test to see if its a spanning tree issue.

@tesparza Ok, then now lets take the next step to capture what is going down the wires. Please follow this process: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue and upload the file to dropbox or a google drive. Please post the link here or DM me directly and I will take a look at it. This should tell us what is missing in the pxe booting process.

@foglalt Sorry maybe it friday, or I need more coffee this AM, but I don’t understand what you are saying here. Pictures and screen shots of settings and the console of the computer in error may help us understand what is going on.

What boot up issues? Its stuck at boot from sanboot. If you change the host specific exit mode to grub, it should then use grub as the exit type not sanboot.

Is dhcp option 66 the ip address of the fog server?

Did you disable the centos firewall (firewalld)

From a debugging standpoint, is the pxe booting computer and fog server on the same subnet?

@rlindenschmidt Great we can see you have 364GB free for your /images mount. Can you provide a screen shot of the error you are seeing. From the df command it looks correct.

someone mess with the linux service account (user) called fog? That’s not the default web admin with the same name. What I’m talking about is the linux user called fog. That account is (should be) managed by FOG and not used for system maintenance.

@adukes40 Is the FOG server on the same subnet (vlan) as these 390?

If they are then we can get a quick answer if you follow the instructions in this tutorial: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If they are not, getting the answer is a bit harder but possible. You can use wireshark on a computer that’s plugged into the same subnet as the 390s to capture part of the dhcp/pxe boot process. That will give us an idea who the actors are during this pxe boot.

Having the FOG server collect the pcap will give us the best quality pcap since it will see the entire conversation. But the client has to be on the same subnet as the fog server to do that.

Upload the pcap to dropbox or a google drive and share the link with us or DM me directly and I’ll take a look at it for you.

This is a single fog server right? And that fog server has all of the storage directly connected to the FOG server as local DAS drives right?

On the fog server linux console what does the output of this command look like df -h?

@jjsplitter Since you still had firewalld enabled, did you remember to set selinux to permissive? If not you will have a sad time when you try to capture an image.

It looks like the instructions from the wiki came from here: https://forums.fogproject.org/topic/6162/firewall-configuration

If you need to leave firewalld running then you will need to enable exceptions to the block all policy. I know that you have that script, but my guess is that you don’t have samba installed and that is why its failing.

This script

for service in http https tftp ftp mysql nfs mountd rpc-bind proxy-dhcp samba; do firewall-cmd --permanent --zone=public --add-service=$service; done
systemctl restart firewalld.service

can be rewritten as:

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --permanent --zone=public --add-service=tftp
firewall-cmd --permanent --zone=public --add-service=mysql
firewall-cmd --permanent --zone=public --add-service=nfs
firewall-cmd --permanent --zone=public --add-service=mountd
firewall-cmd --permanent --zone=public --add-service=rpc-bind
firewall-cmd --permanent --zone=public --add-service=proxy-dhcp
firewall-cmd --permanent --zone=public --add-service=samba

Again I think its the samba that is causing the query to fail

@foglalt Then, without the fog client working for you, you can scale your network well into the 10,000s without any issue.

@foglalt said in exit type vs bios versions:

o you happen to have performance statistic about how much speed reduction may come if all host (like 2k of host) are registered?

With 2K hosts, you might want to change the client check in time to something longer than the default of 5 minutes. Maybe something in the area of 10 to 15 minutes. Consider in an ideal condition with 2k hosts and a 5 min check in window you would have ~7 client check-ins per second. But nothing is ever ideal, with 2K hosts you may have a bunch of check-ins then nothing the next second then a bunch more in the following second. All of these check-ins do consume CPU resources on your FOG server. I say all of this to that you can be mindful and watch your FOG CPU usage when you have all of the FOG clients loaded. If your CPU usage is too high, you can then change the check-in time to make it easier in your FOG CPU.

@greg-plamondon if you look in the directory where the fog installer is (bin/installfog.sh) There is a log directory. In the log directory there should be a log file of the last version of FOG that was installed. This is true for master nodes as well as storage nodes.

@greg-plamondon There is/was a change in the init.xz files between FOG 1.4.4 and 1.5.0RCx The 1.5.0RCx now supports both http and https transactions throughout, where 1.4.4 kind of - sort of - supported https transactions, but not always.

When you upgraded to 1.5.0 on your main server, did you upgrade all of the storage nodes in your fleet? The fog kernel (bzImage and init.xz) need to be matched to the version of FOG that is installed.

@gmonk said in Image Capture:

every time it hangs on clearing ntfs flags

I agree, the issue is not with FOG, but with your target computer not being shutdown cleanly.

Let either:

1. Sysprep power off your computer
2. Shut it down with shutdown -s -t 0
3. Or disable fast startup to ensure the disk is closed properly when win10 is shutdown.

@hsd3tech I think I was able to do that with gparted many moons ago. From a live boot CD and command line you would use extend2fs command. I guess with gparted questions Google is your friend.

@hsd3tech You might need to boot from a gparted live disk (or boot with something like puppy linux that has gparted built in), because you can’t change a mounted file system.

https://www.howtoforge.com/partitioning_with_gparted

@hsd3tech will gparted allow you to extend your file system to fill /dev/sda1?