Hey there,
Have’t really used this feature before. The plan was to set the AD bind in a newly created group but the settings don’t stick.
I had a read on the forum and noticed a host has to be added to be persistent but if I add another host to the group the settings get cleared (hypothetically if I had another network adapter)
What do you guys usually do in this situation?
Export the single host and import the csv with identical settings but different names? what do I do about mac address?

@lucycle
I used to have an issue with some Realtek cards behaving weird and throwing errors in IPXE and later in the boot process, but it’s been a while. With these two HP models and an integrated Realtek card I had to use a different boot firmware, long shot but maybe you can try that?

HP210 Legacy Test

pxe-service=tag:HP210,X86PC, “HP-210 Working”, realtek.kpxe

HP430 UEFI Test

pxe-service=tag:HP430,X86-64_EFI, “HP 430”, realtek.efi

@lucycle said in NFS over TCP not available from x.x.x.x:

In my case the driver in question was dm9601.ko and I also compiled it into my initrd.img which did not fix the issue and behavior persists.

I’ve added another USB dongle, this time a Lenovo 2.0 Ethernet Adapter based on the asix driver, however it didn’t work, then I checked with modinfo and noticed I was missing a dependency (usbnet.ko)

modinfo asix
....
depends:        mii,usbnet

modinfo usbnet
filename:       /lib/modules/4.15.0-34-generic/kernel/drivers/net/usb/usbnet.ko

Just to be sure, you said initrd.img, I added it to initrd.lz

That’s about all I’ve got to suggest at this point

@george1421
Thanks george1421,
I have no issues with mine but thank you

Can you share your ltsp.conf ?
I have seen this as well if I don’t have this line in my confg

dhcp-boot=,,fogip

Hi Sebastian,
Thanks for your reply.
Simplecom USB 3.0 to Gigabit Ethernet Adapter Model: NU301 and the ISO in question is ubuntu-18.04.1-desktop-amd64.iso

I’ve investigated some more on Mint 19 and the location is …/net/usb not ethernet

modinfo r8152
filename:       /lib/modules/4.15.0-34-generic/kernel/drivers/net/usb/r8152.ko
version:        v1.09.9
license:        GPL
description:    Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author:         Realtek linux nic maintainers <nic_swsd@realtek.com>
srcversion:     D89AD85EA9A5FD30618C7B5
alias:          usb:v2357p0601d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v2357p0601d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0955p09FFd*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0955p09FFd*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v13B1p0041d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v13B1p0041d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp7214d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp7214d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp720Cd*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp720Cd*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp7205d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp7205d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp3069d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp3069d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp3062d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp3062d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp304Fd*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp304Fd*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v04E8pA101d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v04E8pA101d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v045Ep07C6d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v045Ep07C6d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v045Ep07ABd*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v045Ep07ABd*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0BDAp8153d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0BDAp8153d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0BDAp8152d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0BDAp8152d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0BDAp8050d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0BDAp8050d*dc*dsc*dp*icFFisc*ip*in*
depends:        mii
retpoline:      Y
intree:         Y
name:           r8152
vermagic:       4.15.0-34-generic SMP mod_unload 
signat:         PKCS#7
signer:         
sig_key:        
sig_hashalgo:   md4

Even when I add it to the right location, it wasn’t working so I read through this post and found the solution (depmod)
https://ubuntuforums.org/showthread.php?t=1843448
Thank you Jonathan L

Here are the steps I’ve taken from a Live Ubuntu USB

root@ubuntu:/home/ubuntu# mkdir /tmp/root
root@ubuntu:/home/ubuntu# cd /tmp/root/
root@ubuntu:/tmp/root# lzma -dc -S .lz /cdrom/casper/initrd.lz | cpio -id
315718 blocks
root@ubuntu:/tmp/root# mkdir lib/modules/4.15.0-29-generic/kernel/drivers/net/usb
root@ubuntu:/tmp/root# cp /lib/modules/4.15.0-29-generic/kernel/drivers/net/usb/r8152.ko /tmp/root/lib/modules/4.15.0-29-generic/kernel/drivers/net/usb/
root@ubuntu:/tmp/root# ls /tmp/root/lib/modules/4.15.0-29-generic/kernel/drivers/net/usb/
r8152.ko
root@ubuntu:/tmp/root# depmod -b `pwd` 4.15.0-29-generic
root@ubuntu:/tmp/root# find . | cpio --quiet --dereference -o -H newc | lzma -7 > /tmp/initrd.lz.new

I scp-ed the initrd.lz.new to the Fog server and renamed it to initrd.lz

I get an ip address but now I get a different error further down the track.

Not sure if because I just copied my Mint 18 Menu for Fog and adjusted it for Ubuntu hoping it would work
(ubuntu18 folder contains extracted files from the ISO)

kernel http://${fog-ip}/fog/service/ipxe/ubuntu18/casper/vmlinuz
initrd http://${fog-ip}/fog/service/ipxe/ubuntu18/casper/initrd.lz
imgargs vmlinuz initrd=initrd.lz root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/var/www/fog/service/ipxe/ubuntu18 locale=en_US.UTF-8 keyboard-configuration/layoutcode=la mirror/country=US
boot || goto failed
goto start

Looks like there’s an issue with booting Ubuntu 18.04, I see another thread here that I’ve been following.

I’ve done the same process for mint 18.2 and that works without a problem, hopefully someone finds this useful

Hi everyone,
I’ve got an issue with certain network cards not being able to mount nfs and load Ubuntu 18 presumably because of the driver?

connect: Network is unreachable
NFS over TCP not available from x.x.x.x

It drops to an initramfs prompt and when I type ip add all I get is the loopback interface

(initramfs)ip add

1: lo: >LOOPBACK>

I have no problems with PXE booting PartedMagic over the same USB 3.0 adapter, but it’s not using nfs
I suspect it’s the driver in the Ubuntu 18 iso, more specifically initramfs

I downloaded r8152.53-2.10.0.tar.bz2
compiled and inserted the r8152.ko into the initrd.lz in the /lib/modules/4.15.0-29-generic/kernel/drivers/net/ethernet/realtek/ folder and uploaded the new initrd.lz back to the fog server but it didn’t work. Must be a step I’m missing. There is no insmod in the busybox so not sure what to try next

The reason I used the above r8152 is because when I boot from a live USB that’s what the network card is using and works fine.

Sorry I know this is not really a fog issue but rather ubuntu / driver I’d still like to know how to resolve if possible
Thanks

@sebastian-roth said in FOG server with dhcp client registration:

@Pikmin I don’t like guessing much so we should just take a look at the facts - the packets on the network that is. So get your client ready but don’t start it yet. Go to your FOG server and install tcpdump (sudo apt-get install tcpdump or sudo yum install tcpdump). Then run the following command and substitute x.x.x.x with the client’s IP address: tcpdump -w /tmp/boot_issue.pcap host x.x.x.x

Leave that command sitting there, boot up the client till it shows the error “Either DHCP failed or …”. Now stop tcpdump (Ctrl+c). Upload the generated file /tmp/boot_issue.pcap to your dropbox/google drive and post a link here or send me a private message if you don’t want to share this with the rest of the world.

I just went through the process of doing this when I discovered that after issuing spanning-tree portfast on all the interfaces it appears to be working now, so that’s the solution like in the other thread.
Thanks again for all your help george1421 and Sebastian Roth, I won’t forget the porfast setting ever again

@sebastian-roth said in FOG server with dhcp client registration:

@george1421 Though the // isn’t nice and might be confusing - that’s not an issue.

@Pikmin To me this sound very similar to what we had just a couple of days ago here: https://forums.fogproject.org/topic/11093/resgistration-issues (read through all of it and take a look at the pictures!
Try using a mini switch to connect between client and your network - see if that makes it work.

I was using a cisco switch with a default config, so no vlans, nothing, tried with a dumb tplink, same thing.
It does look very similar after seeing the pictures attached

Is it worth mentioning that I have a proxy server at work, so when I was originally configuring the fog and downloading packages I have a few exports for git, apt.conf and wgerc so I can get to the Internet.
None of these appear to be on the fogclient

I’ve manually registered the client from the web interface and tried to capture the image that way but same error when it tries to start
I wasn’t paying attention, from the web it failed because Windows wasn’t shutdown or hibernation, testing that now, it’s up to the Resizing Filesystem… so might work
I’d still like to know why it’s failing through quick registration so I will try and upload the pcap file

I’ve also enabled portfast on all the ports

@george1421 said in FOG server with dhcp client registration:

I did not ask this and I probably should have before now. What version of FOG are you using? The latest doesn’t tell us much of anything.

My bad,
1.5.0-RC-10
SVN Revision: 6080

@george1421
Thanks for that, yeah not quite sure what’s going on
It appears when I wget http://192.168.158/test.php it downloads a file even though it doesn’t exist and the file contents are that of index.php
I see a link in /var/www/fog pointing to /var/www/html/fog
Compared the 001-fog.conf from apache to that of a production server here and appear identical, other than having ssl on one and http on this test server
Will report back if I find anything
Why is it detecting a . in wget I wonder

@george1421 No worries at all

I thought the second / was a problem until I saw it elsewhere on the forum, appears to be normal, could be wrong.

In any case the Web server settings look exactly like yours

So the issue is not being able to get an ip address from the server but not being able to access index.php

When I try to wget http://192.168.158.68/fog/index.php it works from a Linux laptop fine but from the debug console in fog I can’t get to it
wget 192.168.158.68/index.php however does work

@george1421 server is 192.168.158.68 assigned statically
EDIT: I’ve picked the debug option and tried to get an ip manually which worked and I can ping 68

I was trying BIOS first, then I thought I try UEFI, same issue with both

I am using the internal adapter yes.

I get an ip address in Windows from the fog isc-dhcp-server

First time I configured fog I used a router address of 192.168.158.1 but since that ip isn’t valid I removed it, also not using dns since not connected to Internet after initial configuration
server ip 192.168.158.68
client range 192.168.158.100-254

Hey guys,
I’ve been tasked to create a fog server on a standalone local network which will be connected to an switch (no internet connectivity), I need the server to hand out dhcp leases so I can capture an image and then push out the image to multiple laptops.

I installed the latest fog on ubuntu 16.04 server and specified to use isc-dhcp-server and a range.

Seems to be okay but having issues with registering the host, when I pxe boot it I can get to the fog menu but quick register doesn’t work, appears to be because of Realtek PCIe GBE Network adapter.
Attempting to register … Failed
The laptop model is HP 430 G5
I’ve tried specifying the realtek.pxe and realtek.efi with UEFI boot but no luck
For testing I tried another model - HP Spectre and that one booted up fine with a Lenovo USB 2.0 Network Adapter

@george1421

Thanks for clearing stuff up with me. Appreciate it

@george1421 said in dnsmasq ProxyDHCP BIOS and UEFI coexistence:

@Pikmin said in dnsmasq ProxyDHCP BIOS and UEFI coexistence:

bootfile name: snp.efi

Also looking at your log file snp.efi is being sent. If you used my config file it should have sent intel.efi (right not I’m not saying its right or wrong kernel for that system I’m just looking for the same as I told it).

My bad, I was trying something from your previous post, with the intel.efi setup same thing

Jun 20 10:30:27 ndfog dnsmasq-dhcp[13167]: 1636139832 vendor class: PXEClient:Arch:00007:UNDI:003016
Jun 20 10:30:27 ndfog dnsmasq-dhcp[13167]: 1636139832 PXE(ens160) b0:5a:da:9e:d8:b8 proxy
Jun 20 10:30:27 ndfog dnsmasq-dhcp[13167]: 1636139832 tags: UEFI, HP210, ens160
Jun 20 10:30:27 ndfog dnsmasq-dhcp[13167]: 1636139832 bootfile name: intel.efi
Jun 20 10:30:27 ndfog dnsmasq-dhcp[13167]: 1636139832 next server: 192.168.131.149
Jun 20 10:30:27 ndfog dnsmasq-dhcp[13167]: 1636139832 broadcast response
Jun 20 10:30:27 ndfog dnsmasq-dhcp[13167]: 1636139832 sent size:  1 option: 53 message-type  2
Jun 20 10:30:27 ndfog dnsmasq-dhcp[13167]: 1636139832 sent size:  4 option: 54 server-identifier  192.168.131.149
Jun 20 10:30:27 ndfog dnsmasq-dhcp[13167]: 1636139832 sent size:  9 option: 60 vendor-class  50:58:45:43:6c:69:65:6e:74
Jun 20 10:30:27 ndfog dnsmasq-dhcp[13167]: 1636139832 sent size: 17 option: 97 client-machine-id  00:4e:fc:b7:3e:58:32:11:e5:8b:16:b0:5a:da...

@george1421 said in dnsmasq ProxyDHCP BIOS and UEFI coexistence:

@Pikmin said in dnsmasq ProxyDHCP BIOS and UEFI coexistence:

Last message I get is
PXE-E21: Remote boot cancelled?

Ah ok then your dhcp server is sending out info too and the client is getting confused. Do you have time to debug this so we can see exactly what’s going on?

You will need the pxe-service commands but lets understand what’s going on first.
The Windows DHCP Server is set to PXE Boot SCCM

Also note that without using the netmask in the range directive PXE boot doesn’t work
dhcp-range=192.168.131.149,proxy,255.255.0.0

I also have ip helper on the switch so I can netboot from other vlans

@george1421

I’ve tried that but didn’t work for me, it gets to the boot menu but doesn’t seem to know what to boot, so the menu counts down and nothing happens
EDIT:
Last message I get is
PXE-E21: Remote boot cancelled?

This is what I get in the log

Jun 20 10:14:40 ndfog dnsmasq-dhcp[12339]: 2701847451 vendor class: PXEClient:Arch:00007:UNDI:003016
Jun 20 10:14:40 ndfog dnsmasq-dhcp[12339]: 2701847451 PXE(ens160) b0:5a:da:9e:d8:b8 proxy
Jun 20 10:14:40 ndfog dnsmasq-dhcp[12339]: 2701847451 tags: UEFI, HP210, ens160
Jun 20 10:14:40 ndfog dnsmasq-dhcp[12339]: 2701847451 bootfile name: snp.efi
Jun 20 10:14:40 ndfog dnsmasq-dhcp[12339]: 2701847451 next server: 192.168.131.149
Jun 20 10:14:40 ndfog dnsmasq-dhcp[12339]: 2701847451 broadcast response
Jun 20 10:14:40 ndfog dnsmasq-dhcp[12339]: 2701847451 sent size:  1 option: 53 message-type  2
Jun 20 10:14:40 ndfog dnsmasq-dhcp[12339]: 2701847451 sent size:  4 option: 54 server-identifier  192.168.131.149
Jun 20 10:14:40 ndfog dnsmasq-dhcp[12339]: 2701847451 sent size:  9 option: 60 vendor-class  50:58:45:43:6c:69:65:6e:74
Jun 20 10:14:40 ndfog dnsmasq-dhcp[12339]: 2701847451 sent size: 17 option: 97 client-machine-id  00:4e:fc:b7:3e:58:32:11:e5:8b:16:b0:5a:da...

@george1421
Hello, can you confirm that the following fields are meant to be enough to boot into UEFI, not the basic but advanced option
Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,192.168.112.24
dhcp-boot=net:UEFI,ipxe.efi,192.168.112.24
dhcp-boot=net:UEFI64,ipxe.efi,192.168.112.24

They don’t appear to be enough in my case, once again pxe-service is needed but you say in the guide to remove it :
Adding (a bit more complex) UEFI support to the basic script
We’ll start with our basic configuration file again. Note: we removed the pxe-serivce entries we added previously.

This is what my config looks like now, I’ve added a match for HP 210 and have been testing stuff out, BIOS doesn’t work with this model: No configuration methods succeeded (http://ipxe.org/040ee119) I have added a BIOS menu that boots nothing (removed the undionly line) because it fails anyway.

I have a separate HP210 UEFI menu

HP210 UEFI Test

pxe-service=tag:HP210,X86-64_EFI, “HP-210”, ipxe.efi

when I push F8 I get two options HP-210 and Boot UEFI PXE-64
Without the pxe-service and only dhcp-boot options, the boot fails

# 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

# 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


dhcp-match=set:HP210,97,00:4e:fc:b7:3e:58:32:11:e5:8b:16:b0:5a:da


##### Without this one I get asked to enter TFTP Address
dhcp-boot=undionly.kpxe,,192.168.131.149


pxe-prompt="Press F8 for boot menu", 10


pxe-service=tag:HP210,X86PC, "HP-210 NOT COMPATIBLE WITH BIOS",

# PXEClient:Arch:00000
pxe-service=X86PC, "Boot BIOS Legacy PXE", undionly ###########.kpxe

# PXEClient:Arch:00007
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi

# HP210 UEFI Test
pxe-service=tag:HP210,X86-64_EFI, "HP-210", ipxe.efi

# PXEClient:Arch:00009
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi


dhcp-range=192.168.131.149,proxy,255.255.0.0

@Sebastian-Roth said in dnsmasq ProxyDHCP BIOS and UEFI coexistence:

2.76
Hey Sebastian,
Yeah I’ve compiled 2.76
dnsmasq -v
Dnsmasq version 2.76 Copyright 2000-2016 Simon Kelley
Compile time options: IPv6 GNU-getopt DBus no-i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify

It doesn’t appear to be an issue with not being able to boot UEFI rather ignoring the dhcp-boot fields.
Without the pxe-service=X86-64_EFI, “Boot UEFI PXE-64”, ipxe.efi, the boot fails