@hvaransky If you run sudo su - first then you should be able to run the commands without the sudo at all.
It would be interesting from a bench marking standpoint to use the same tool to give us the same relative number.
But based on the benchmark screen, I would expect you have either a SATA SSD or a multi hard drive (>6) disk array. Maybe raid 10. So your slowness is probably not your disk subsystem. So the next steps are network testing.
If you have some time, I’d like you to do some system benchmarking. Maybe we can find the source of your issues.
The first and easiest to test is local disk subsystem. From a linux command prompt on your fog server run these commands.
sudo dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=direct
run it 3 times and average the output which should look something like this:
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 13.9599 s, 76.9 MB/s
Then run this command 3 times and average the output.
sudo echo 3 | tee /proc/sys/vm/drop_caches && time dd if=/tmp/test1.img of=/dev/null bs=8k
Post the results here.
And finally we need to remove the 1GB file we created.
sudo rm -f /tmp/test1.img
The next bit is network throughput. But lets see your disk speeds to start.
@flipwalker If you have dell systems (sorry I don’t remember) you can get the cab files from here: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment (Hint: They are all in one place.) Just extract the drivers using 7zip and build the required directory structure.
@fox134 Right at the point of the IPXE> _ prompt key in dhcp net0 or dhcp net1 after 30 seconds to see if it picks up an IP address. (I see you did a dncp net0, btw).
Is that mac address listed the same mac address as on the usb adapter?
@lof yes, if no uefi then you don’t need 2.76 and also don’t use my configuration. You need the older 2.75 config and earlier. In your case you will need to create a link from undionly.kpxe to undionly.kpxe.0 and ipxe.efi to ipxe.efi.0 since the older releases always added .0 onto the end of what ever the configuration file calls for.
@fox134 well if its shows the mac address of the usb nic, that means that iPXE should have a driver for it. At the screen where it says press “s” for the iPXE console. Go ahead and do that before the timeout.
Then wait 30 seconds and key in the following to see if it picks up an IP address dhcp net0 or dhcp net1 if net0 doesn’t get an address because the usb network adapter is not the first one. If you do pick up an IP address after 30 seconds then I would surely explore what is going on with spanning tree.
@lof well you need the fixes in 2.76. I’m a bit surprised that mint is not current.
[edit] I just checked and ubuntu 16.04 is a bit behind. They only support 2.75 as you noted. Newer versions of ubuntu do support later releases of dnsmasq. I do have instructions on compiling your own copy. It should work with the tarball you found. I have not tested it with 2.78, but I guess try: https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support
@lof Mmmmm. I’m pretty sure that dnsmasq is not added by the script, but the script will manage dnsmasq if its installed. Wayne wrote the script so he would know for sure. But, if it was me, I would just install dnsmasq and be done with it.
@lof you need to install dnsmasq manually. Its not a direct function of fog.
I remoted in with teamviewer and helped the OP get things working correctly. We had to ensure that the dhcp server only bound to the imaging lan NIC adapter and not both. We also found a nuance with ubuntu where it only wanted one interface up at a time by default. Once we had both interfaces up, fog installed correctly and like the OP needed it. Solving this case.
@lof For your dnsmasq configuration.
dnsmasq -v command.# 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
Make sure you change <fog_server_ip> to the current IP address of your FOG server. The make fog mobile script (only needs to be run once since it sets up a cron job) will modify this file when it runs. This dnsmasq configuration will give you dynamic boot file name based on the pxe booting client. (bios or uefi).
@dpotesta50 well that explains why no dhcp boot. Its not running.
First lets try to start it. This might be the command systemctl start isc-dhcp-server See if that gives you a positive.
When you run the netstat command you should see something that looks like this
udp 0 0.0.0.0:67
If that works then you will want to run this command
systemctl enable isc-dhcp-server to enable the server to start at each reboot.
@eazis Ok then, wireshark is the next steps, as well as tcpdump on the fog server.
On the fog server you will want to follow this guide: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
In reality since your target computer is on another subnet, all you need is port 69 (tftp) the rest are dhcp and proxydhcp.
You will need a computer with wireshark loaded and on the same subnet as the non-pxe booting computer. Ideally this non-pxe booting computer should be on the same subnet as your main dhcp server. For wireshark you will want to run this capture filter port 67 or port 68
The process will be to start tcpdump on the fog server, then wireshark capture and then pxe boot a failing pxe boot system. As soon as the pxe boot system starts into windows then stop wireshark and then stop tcpdump. You can either review with wireshark or upload to a dropbox or google drive and I will review it. What we are looking for is the target system will send a dhcp discover packet. That packet will state the type of computer it is. Then your dhcp server should send out a dhcp offer. You should have only one offer from one dhcp server.
As for the pcap from the fog server, I’m interested in seeing the requested file is transferred completely.
@eazis Again to rule out the workstation, please test a non-functioning one from the business network on the imaging network. We have seen some systems with pretty cruddy uefi firmware that have been fixed with firmware updates. I want to rule out a hardware issue before going to packet capture.
@dpotesta50 Ok the slowness is from both networks?
OK, now lets work on one issue at a time.
So fog is the dhcp server, we need to make sure that isc-dhcp service is running on the fog server. Run this ps aux|grep dhcp and/or you can check to see if its listening netstat -an|grep 67
The fog installer should setup the isc-dhcp config file to look like this: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1
@dpotesta50 So if you run ip addr show to get the IP address of the wireless interface and then from the business network attempt to connect to that ip addresss /fog ?
@eazis To rule out the workstation from this problem, if you (have you) moved a non-pxe booting computer from the business network to the imaging network and confirmed it boots into the iPXE menu?
We are missing something here iPXE should boot no matter what subnet. The next steps will be to get wireshark setup to capture some packets.
@dpotesta50 Ok so then selinux will not be in your way. Did you ensure that the firewall has been disabled? I know that IS on by default for ubuntu.
@dpotesta50 (sorry I’m a rhel guy) I’m not sure if ubuntu has selinux enabled or not by default. If its on, then its mandatory that you set it to permissive. If from the linux command prompt you key in cat /etc/selinux/config look for a line that says SELINUX=permissive or SELINUX=disabled If that is set then selinux will not cause you pain. If its set to enforcing then you need to change it as root and reboot.
@eazis ok lets collect a bit more info then.
What I find strange is that the iPXE kernel is not starting at all. This makes me think secure boot has not been disabled.