There is a couple of things that could be the problem/solution.

First, while its not a problem here, ensure that secure boot is disabled

In regards to raid.
In fog configuration -> fog settings click on the expand all button. Search for kernel args and add in mdraid=true. Save the settings.

What this does it tells FOS linux to enable the raid management drivers in the kernel. If you are using the built in, intel rapid store raid you will need this kernel arg enabled. The intel raid, is a hardware assisted software raid. To linux it will present both the physical drives as well as the logical array. Since you are not seeing the nvme disks, this is probably not your current issue but there is no harm to have this feature enabled.

What I want you to do next is manually register this 3420 and schedule a capture or a deploy (doesn’t matter) but before you schedule the task tick the debug check box then schedule the task. Next power up the target computer but hit F12 a couple of times as soon as you see the dell logo, we want the boot menu to appear so we can do the next test. When the boot menu appears select from the bios menu (not uefi) network boot (if no bios boot options go into the firmware settings and enable legacy roms then reboot). We want to pxe boot the target computer in bios (legacy) mode. There is a known issue with Dell computers with the disk controller set to Raid-On and uefi mode. By booting in bios (legacy) mode we will be able to bypass this known issue.

When booting in debug mode you should see several screens of text that can be cleared by pressing the enter key. After pressing enter a few times you will be dropped to a linux command prompt. At the linux command prompt I want you to key in
lsblk and post the results here. This will show us the disks (block devices) that linux sees in this computer. You can either key in what you see here or take a clear picture of the output of that command with a mobile phone and post it here.

Once we know what we see in bios mode we can guide you to the next steps.

FWIW I imaged a Dell Precision 3630 last week (with sata drives) with the disks in a raid configuration and I had to switch to bios mode for imaging but the windows image and final firmware settings are uefi. Meaning you can image a uefi computer just fine in bios (legacy) mode even if the final operating mode is uefi.

@kasperdvdh Well then I have to ask where does 10.0.2.4 come from?

For virtual box, do you have the network setup to bridge and not use nat?

What version of fog are you using?
Do you know what kind of data is it sending?
Have you reviewed the FOG image replicator logs to see if the replicator is stuck on something?
Is your storage node a full fog server or is it a nas device?

I’m going to say you have 2 dhcp servers on your network. Also since you are getting 192.168.1.1, I’m also going to predict you have a soho router/access point on your network.

If the fog server and the target computer are on the same subnet (vlan) we can use the fog server to find out for sure if this is the case. You will have to do a little (not much) setup: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

You can either load the pcap into wireshark and look to see if you have 2 dhcp offers. If so you do have 2 dhcp servers on your network one will be your official dhcp server and the other will be your rogue dhcp server. If you can’t figure it out upload the pcap to a file share site and post the link here so we can review it for you.

Lets start out with making sure the firmware (bios) is at the latest release for this device. We’ve seen some pretty buggy early release firmware from Lenovo. Even if it doesn’t address this issue its not a bad idea to be on the latest bios release anyway.

See if this one fits the case: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

@dambron When you look at the uploaded image size in FOG Image management, what is its file size compared to how much actual data is on the reference image hard drive?

If you were to capture that same reference image again, looking at the partclone screen does it say capturing in RAW mode?

@lucas942 said in .fogsettings don't exist:

/opt/fog/.fogsettings

First of all this file is hidden by default so by just browsing /opt/fog you will not see it. You need to use ls -la /opt/fog to see it.

Second this file is created after the first time you run the fog installer script. If something happens where the installer script doesn’t complete successfully that file will not be created. That file contains the values selected during your initial setup of fog.

Normally you do not need to edit/change this file. What specific problem are you seeing?

Lastly, your english is perfect, no need to be sorry. I will not say bad things about you even if you are french.

@DarKFeeliN OK if the fog server, dnsmasq server, and pxe booting clients are on the same subnet then dnsmasq will (should) work without modifying your networking infrastructure. dhcp works through broadcast messages. If the dnsmaq server was on the same subnet as your dhcp server then you must update the networking infrastructure.

Now to understand why its not working. I want you to follow this tutorial. Since you have public IP addresses upload the pcap to a share file site (like google drive) and then IM me the link and I’ll take a look at it. The pcap will only contain pxe boot information if you follow my capture filter. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If you want to look at the pcap in windows you can use wireshark. You should see the client send a dhcp discover packet and then both the main dhcp server as well as dnsmasq sending a dhcp offer packet. As long as both offers are received by the target computer then it should work. There are a few other things to look out for so I need to see the pcap file.

@DarKFeeliN said in Not able to PXE boot from FOGServer on Proxmox LXC with proxyDHCP:

I haven’t been able to record a single packet from port 67, 68, 69 or 4011 for the duration of the time I had a client try to boot from PXE for both the fogserver and the proxmox host.

I suspect the gateway switch might suppress those broadcoasts. I will build a small local network with a switch I control, redo the tcpdumps and report if the results are different.

This might sound bad but this is a good bit of information. For dhcp to work, broadcasts MUST be supported on your network. Even if you are not picking up the other parts of the pxe booting process you MUST see the discover, offer, request, and ack/nack messages (also dhcp inform messages too) or there is no chance of any target computer getting a dhcp address.

So your fog server is running as a vm under Proxmox (I don’t know this hypervisor so I can only speak in general terms).

1. If you create a VM (or have one) on this same vm host server does it pick up a dhcp address in the x.y.42.X range?
2. Do you have the fog server bridged to the business network (not natted)?
3. Do you need to set the vm host server interface into promiscuous mode?
4. If you take a second computer as a witness computer with wireshark installed connected to the same network switch as the FOG server’s vm host do you see any dhcp traffic?

Once we see dhcp traffic then we can focus on if dnsmasq is working like it should.

@lucas942 said in Nas node storage : permission denied:

I just got to find a directory in / images on the NAS 14gb its name is: e86a64cbxxxx and this corresponds to the MAC address of my PC.
So I rename this folder “Standard”?
Because the name of my image is “Standard”

You have a few things that are wrong.

1. The image file should be first captured into the /images/dev/<mac_address> folder.
2. After the image is fully uploaded to the /images/dev/<mac_address> folder the target computer logs into the FOG server (nas in your case) via FTP and issues a move command to move all of the files in /images/dev/<mac_address> to /images/<image_name>.

The screen shot of the error you see about ftp_put tells me that in the storage node configuration there is 2 fields Management Username and Management Password. The values in those fields must match the user you created on the NAS device.

Have you changed or messed with the linux user fog’s password or user account? Understand this is not the default web ui admin named fog, I’m talking about the linux service account by the same name. If so you may want to run through this tutorial to fix everything: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

Is 10.16.20.2 the IP address of your fog server?

I’m shooting from the hip here, but since the table is blank we can’t break it more.

sudo mysql -u root -p fog

Press enter for the password

INSERT INTO users(uID,uName,uType,uAllowAPI) VALUES(1,'fog',0,1);

UPDATE users SET uPass = MD5('password') WHERE uName = 'fog';
exit;

If the insert into doesn’t work then try this query instead

INSERT INTO users(uName,uType,uAllowAPI) VALUES('fog',0,1);

If its having an issue with insert into then I will need to look up the exact syntax, but it should be close.

You should then reboot the fog server to flush the cached tables.

Make sure your firmware is up to date in this hardware. Its failing between the UEFI PXE rom hand off and iPXE starting. Typically when we’ve seen this in the past it was related to cruddy early generation firmware.

@willian said in Change the boot order automatically:

What I meant is if you configure each machine to enter the boot menu by F12

On the Dell systems, when its at the Dell splash screen if you hit F12 you will be presented with a ROM boot menu. From there you can (one time) change the boot order from the default hard drive to a network or cdrom boot. There is nothing to configure for this, you just hit 12 for dells and sometimes F1 or F10 for other hardware to get this boot menu. We do this because I want the IT Tech sitting in front of the computer they are to image so they know for sure what system they are imaging. If they have to image 10 machines at one they boot each machine, hit the F12 and select network boot.

Our approach would be different if I needed to image 30 computers all at once using the FOG multicast imaging, such as in a educational classroom setting.

@JerJer Well… I found in the git hub notes that 0.9.1 was in the build release for quite a while. I have not contacted one of the developers to find out what is currently shipping.

I would then revert to my previous request to temporarily rename refind.efi and then go through the pxe boot process and exit to the hard drive. I have not ever heard of refind being sent to a bios based computer before, especially since its not listed in the iPXE menu. I don’t understand how its getting to the target computer.

@kenneth-sisco Ok now where its stopped is its trying to write the kernel files to /var/www/html/fog/service/ipxe directory. If I remember correctly there was a bug in 1.4.4 where the directory permissions did not let the linux user fog (or apache I can’t remember which) write into that directory. While there is a slight security risk in this if you issue the command chmod -R 777 /var/www/html/fog/service/ipxe that will mask the directory permission issue and allow the ftp download to write to that directory. The security risk is that you are setting world read-write access on that directory.

If you still can’t get the download to work, you can update the kernel by hand, but lets see where fixing the permissions on the kernel directory gets us.

@kenneth-sisco said in FOG Kernel Update Errors:

/var/www/fog/service/ipxe

Well that’s great you have it sorted out.

Yeah some time after 1.4.4 the path was standardized across all linux distros because you had the debian variants in /var/www/fog/service/ipxe and the rhel variants in /var/www/html/fog/service/ipxe it was too hard to give clear directions to fog admins so the developers merged the paths together.

@kenneth-sisco Yeah based on the title this issue is solved. Lets start a new thread with this “new” issue. The developers don’t really like us to mix threads because it confuses the future readers.

But in the mean time as you start a new thread. Kill this current capture/deploy task and then reschedule the task with the debug check box ticked then schedule the task. PXE boot the target computer. You will see several screens of text that you will need to clear with the enter key. After the pages have completed you will be dropped to the FOS Linux command prompt. At the FOS linux command prompt key in ip addr show and lspci -nn|grep -i net and post the results in the new thread. Also include in that new thread the hardware manufacturer and model of computer that has this issue.

@kenneth-sisco Ok that is good (being on 4.11), well not really but explains why the network adapter isn’t working. Remember that the kernel is booting from the USB flash stick. So its the bzImage and bzImage32 on the flash stick that counts here. So you need to update the usb flash stick from here: https://fogproject.org/kernels/

Grab Kernel.TomElliott.4.19.36.64 and save it as /boot/bzImage on the flash drive.
Also grab Kernel.TomElliott.4.19.36.32 and save it as /boot/bzImage32 on the flash drive, replacing the files that are there.

Remember that case IS important.

As far as files and paths, I’m a RHEL guy so I have a certain slant on things and file paths. The debian variants (where FOS Linux is) confuse me a bit, i can get you into the ballpark but you will have to find the bases. Its good you were able to fine what you needed in /var/log/messages.