@buercky said in New latitude E7400. No internal NIC, Boot to USB-C Puck NIC. Gets IP from DHCP but does not connect to Fog.:
when selected it gets an IP from dhcp but then goes to press F1
This part confuses me then. If its getting an IP address it should then transfer the file. Is this laptop in bios (legacy) or uefi mode?
Well this will get a little complicated to explain, but lets try.
Traditional pxe booting requires dhcp options 66 and 67 to be set with the proper information namely the next-server and boot-file settings. In a normal environment that is all that is needed to pxe boot a device.
Now enter a network function called ProxyDHCP. A proxy dhcp server can be configured to override what is set in dhcp options 66 and 67. FOG can use a ProxyDHCP server in cases where the main dhcp server can’t be modified such as in a managed service. For the FOG/linux world you would install DNSMASQ which can be configured as a proxy dhcp server. ProxyDHCP servers work over broadcast messages. So if you have a ProxyDHCP server on one subnet it will not hear or respond to pxe boot requests on a different subnet unless you have the ProxyDHCP server configured in the dhcp-helper/dhcp-relay service on your subnet router.
SCCM / WDS has a built in ProxyDHCP server. So that is why your dhcp options are being over written with the SCCM boot loader. If you want to block / stop this there is a netboot service on your SCCM server that you need to stop.
If you want proof this is happening you can use wireshark on a computer on the same subnet as the pxe booting computer that connects to sccm instead of fog. If you use the capture string of port 67 or port 68 or port 4011 then capture the pxe booting process.
When you look in wireshark you will see
@im-pearce said in Muticast:
My network supports routing across networks.
Just be aware that multicast routing is different than tcpip routing. Most tcpip routers block multicast messages from crossing the subnets. Fog has two modes of imaging, unicast (point to point one stream) and multicast (point to many one stream). Unicasting will work in any routed network. Multicasting needs the infrastructure setup to support the multicast stream.
But for the point of discovery, can you put at least 2 of these computers on the same vlan as the fog server and test. What I want to rule out is the fog server not multicasting right. If they image correctly then we can rule out the fog server at fault.
It should be possible to do, I’ve knitted together an idea that might work. Note: there may be a smarter way to go about this, but this might get you going until I can get my hands on a fog server console.
Go in and create a new FOG iPXE menu item and have it displayed for all hosts.
Menu Item: fog.fastwipe
Description: FOG’s Fast Disk Wipe
Parameters:
kernel bzImage
initrd init.xz
imgargs loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=${fog-ip}/fog consoleblank=0 loglevel=4 capone=1 mode=wipe wipemode=fast mac=00:00:00:00:00:00
boot || goto MENU
Multicasting is a beast upon itself. With that said, is the fog server and the target computers on the same subnet? If not you will need an multicast router or igmpproxy setup to send the multicast traffic between your subnets. This is not a fog requirement, but more of an infrastructure multicast thing.
Also for clarity, what version of FOG are you running?
I would be interested in seeing a pcap (network capture) from this device as its booting to make sure our wiki still contains accurate info: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
@bartont126 said in Unable to deploy Image:
What is the downside to running off achi instead of Raid
Nothing as long as you are not running a raid configuration (multiple disks teamed together). On a laptop its kind of hard since you only have one disk anyway.
haven’t had this issue before, unless the 7390s I’ve imaged before were on ACHI for some reason
If they were in bios mode, or ahci mode you wouldn’t have had an issue.
@bartont126 said in Unable to deploy Image:
The 7390 is currently in UEFI Mode/Raid-on. I have the option for Raid, AHCI, or Disabled. ’
OK there is an issue with linux, dell computers in raid-on, and uefi mode. If you set the disk to ahci linux (FOS in particular) will see the disks. The only risk to this is you may need to reinstall the os if it was configured for raid mode if it doesn’t have the driver built in.
@idiart33 Ok is there a tftp log in /var/logs directory? There has to be a clue somewhere why the tftp server isn’t starting.
You could also try to manually start it to see if there is any usable hints.
cd /etc/init.d
./tftpd-hpa start
I don’t know what status 71 is, but I’m hoping it will tell us what it doesn’t like.
@bartont126 Remember with great power comes great responsibility. Use the following commands with care.
Use this commands to see what directories are from failed uploads (yes they do take up space)
ls -la /images/dev
Get the list of directories that appear to be mac addresses. Then run this command replacing <mac_address> completely with the directory names. Remember executing this command is unrecoverable.
rm -rf /images/dev/<mac_address>
The -rf makes the command dangerous. -r == recursive meaning do it on that directory/file and all objects below. -f == force or just do it and don’t ask questions.
You can check the disk usage with this command before and after to see how much free space you made du -sh /images/dev
You have a 7390 is it in bios or uefi mode? If is in uefi mode is the disk controller in raid-on mode or ahci mode?
@vpt So did you boot the image you are trying to capture and run check disk “chkdsk /f”? There is something wrong with the structure of that disk you are trying to capture.
@vpt That first error is saying that windows was probably shutdown incorrectly for image cloning. This happens when someone just uses the shutdown start menu button. With fast boot enabled in windows, shutdown is really an enhanced sleep state. Its really not “shutdown” what we would think it is.
So what can you do?
Shutdown the windows computer properly for cloning by:
shutdown.exe -s -t 0 from a command window.To understand what is happening here you can google “windows dirty bit”.
@idiart33 OK the issue here is that the tftp service can’t start, it can’t bind to the ipv4 socket. This typically means that there is already a service running bound to that socket. So far there is no other problems other than tftp, so you don’t need to look at fog settings at the moment. Having to hand edit the default.ipxe file means that you do have some fixup to do with fog because the IP address changed after you installed FOG.
STOP... I just looked at your previous posts "In the /tftpboot/pxelinux.cfg/default file I had a bad IP." why is syslinux installed on this computer? FOG uses iPXE for its boot loader. This tells me you don't have a standard FOG install. Are you installing FOG side by side with another opensource project?
Lets first try to understand why tftp is not starting.
Please run these command:
systemctl status tftpd-hpa
Make sure the service is still in the state of not being able to bind to the socket.
Then run:
netstat -an|grep :69
You should not get any response.
If you get a response like below you already have a tftp service running on your computer. I’m going t guess you WILL get a response like below, but lets see.
netstat -an|grep :69
udp 0 0 0.0.0.0:69 0.0.0.0:*
Another test would be this command:
ps aux|grep tftp
With the status of can not bind to the socket, I would expect this to return some value too. What this test does is to check to see if a service with tftp in the name is running in memory.
@bartont126 First being on 4.11.0 is the root of the issue with l219-V network adapter. That support was added into the 4.12.0 linux kernel. So close but not quite.
There is no guide to manually update the kernels because its not recommended you do by hand. With that said download the kernels from here: https://fogproject.org/kernels/
Download Kernel.TomElliott.4.19.6.64 and save it as bzImage
Download Kernel.TomElliott.4.19.6.32 and save it as bzImage32
Move both of those files to your FOG server in the following directory
/var/www/html/fog/service/ipxe
-or- this if the above errors out
/var/www/fog/service/ipxe/
Note: you will probably want to rename the existing files before you move these new kernels in place just in case you need to backup for some reason.
@arnaudrigole said in Dell Optiplex 7060 - getHardDisk error:
I used that trick to switch between “raid on” and “AHCI” during more than one year right now, and it worked well but…
Now we got NVMe SSDs in our new DELL computers, which need to be configured in “Raid ON” as “Sata Operation” to boot on Windows. Do you think that “GetHardDisk” error will be fixed in next versions ?
I think you have two different issues here. The first issue is the raid-on vs ahci mode. This is an age old issue between Intel, Linux, and uefi. With these three amigos working together linux can’t currently see any disks behind this configuration. If you change any of the three (really two) linux will see the disk. From what I understand the issue is related to intel not releasing the uefi raid drivers to the linux community.
The second issue may be new Dell hardware with these NVMe disks.
@agray When you setup vitrualbox did you add in the virtualbox extension pack? The reason why I ask is that your network settings appear correct. I’d have to look at my home linux laptop to be 100% absolute. I know pxe booting does work with virtualbox into fog because I do testing at home often.
This appears to be more of an issue with virtualbox than FOG since your physical machine works correctly.
@agray I would say that looks like a normal pcap except I don’t see it transferring the file. If you look at the pcap we see a Discover, Offer, Request, and ACK. Then the client request the file size of undionly.kpxe and then requests the file… from there it stops. Then after 30 seconds or so it sends out a discover again and the fog server responds with an offer but then it cycles between discover and offer.
So my question is this: Does this happen with the VM only, where a physical computer boots normally?
I might understand what is happening but not the why just yet. I did notice that the mac address of the device in your picture doesn’t match the mac address of the pxe booting device in the pcap [08:00:27:8a:86:44].
@agray I guess the question needs to be asked are you running the dhcp server on the fog server for a reason in addition to the dhcp server on your router?
Which dhcp server do you want to run? I understand the goal is to pxe boot your clients but there is a number of ways to go about it, depending on what your main goal is.
@agray OK I also looked at the second pcap the first one didn’t have anything useful that I could see.
In the second pcap you have 2 dhcp servers responding to the target computer. The first one is 192.168.1.1 and the second is 192.168.1.90. .90 appears to be a fog server since its handing out the right next server and boot file name. The issue is that it appears to be configured as a full dhcp server since its also handing out an IP address which is in conflict with what your 192.168.1.1 dhcp server is doing.
Looking at the pcap more the .90 dhcp is winning the election process because its responding with a ACK packet.
I want you to follow this tutorial when creating your PCAP so we only get the info we need and not extra internal messages: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue