@bryan-wright said in Boot hangs after init.xz on Dell OptiPlex 9030 All-In-One:

It looks like the per-host kernel arguments get concatenated onto the global ones, though.

Yes, correct, all kernel args are pulled together. Tough I can’t tell you why it was coded this way back in the days. I fear changing this behaviour in FOG will cause trouble for many people. But you could modify /var/www/html/fog/lib/fog/bootmenu.class.php on your FOG server to skip the global kernel args when it’s set for a specific host.

@wasps-d said in Shutdown after image deployment instead of reboot:

I’m booting via USB (Unable to use PXE booting due to limitation set by admin)

This is where the problem is. Using the USB booting, its getting the kernel parameters from the grub config and not iPXE (because iPXE isn’t being used). What you need to use is edit the grub.cfg file and add shutdown=1 at the end of the kernel parameters for menu item 1.

As below:

menuentry "1. FOG Image Deploy/Capture" { echo loading the kernel linux $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 shutdown=1 echo loading the virtual hard drive initrd $myinits echo booting kernel... }

Understand this will tell the kernel to shut down after any imaging task.

Okay so after George was kind enough to assist me with building a USB deployment method (which works great)

I have played around with the FZ-G1 on a docking station and I have been able to get these to PXE boot directly using a UEFI method.

It seems for some insane reason when selecting the IPV4 PXE option in the BIOS under boot override (which is 99% of the time the method I have used). It will become stuck at"ipxe initialising devices…"

If you specify LAN as the primary boot device and allow the machine to boot organically, it works… go figure?

So anyway this is now solved! Thanks for your help guys.

@GeorgeBells

This depends on how you downloaded fog in the past.

You could:

cp -r /path/to/fogproject/installation/packages/fog/lib/plugins/* /var/www/fog/lib/plugins/

Otherwise you could download it with:

git clone https://github.com/fogproject/fogproject cd fogproject/packages/web/lib cp -r plugins/* /var/www/fog/lib/plugins/

The only difference between yesterday and today was manually adding the repo, I’m not sure why it just instantly worked as soon as I did that. The major difference I can tell is that I have two ethernet cards, 1 internet connectivity, and 1 for the imaging network. Another service I’m running is sshd for remote control.

Before I installed the extra repo when I would run the script it would run without error and installed everything that it needed, and then it broke afterwards.

@sebastian-roth my colleague made me a joke by activating a second dhcp on a 4G terminal …

ty for answser

@gchartrandCRL For multicast to work properly all the hosts need to be “in sync”. Notice that when all the machines boot up they all wait on the blue partclone screen for everyone to join before it actually starts.

This is not only true for the first start but repeated on every partition. So all hosts need to wait and sync on the second, third, … partition. If a hosts arrives too late it can’t join this session and will drop out.

On the first partition FOG’s multicast manager waits for FOG_UDPCAST_MAXWAIT * 60 seconds but for all the other partitions the wait time is set to 10 seconds. This is usually enough but in some cases causes problems.

So to make a long story short, edit /var/www/html/fog/lib/service/multicasttask.class.php, jump to line 567 and change the value of 10 to 30 for example.

Before the change:

$i == 0 ? $maxwait * 60 : 10

After the change:

$i == 0 ? $maxwait * 60 : 30

Cancel all multicast tasks (or let them run to the end) and restart your whole FOG server to make sure it’s in a clean state. Then schedule a new multicast task and see if the same thing happens again.

@george1421 Thanks again for the help. This is probably where I’ll have to put a pin in this for now, because we restored the original sever and the duplicate server has been shut down for the time being. Hopefully we can circle back around to it soon, though.

@dashwell The linked post is years old. Please take a picture of the exact error you have on screen and post that here.

@SomeITGuy The adapter settings look fine I think. I suggest you configure your DHCP to serve UEFI and BIOS machines (see wiki article) and test PXE booting a hardware machine. Or if you want to quickly check UEFI PXE boot, then just change the filename to ipxe.efi for the moment and try it out.

@george1421 When i tape uname -a i got this: Linux fogclient.localdomain 4.19.145 #1 SMP Sun Sep 13 05:35:01 CDT 2020 x86_64 GNU/Linux
I don’t know why m not in the version Kernel.TomElliott.5.10.34.64
So i did it again, i downloaded this new version and now FOS see the second card and its working 😃
Thanks a lot for your help George, you can close this ticket.
Have a nice day.

@markus1204 Ahhh, I knew it would be something simple… 🙂

Run du -h --max-depth=1 /images/ on your FOG server to get a listing of the images’ size.

As well check out this post: https://forums.fogproject.org/topic/15501/request-dev-branch-web-ui-show-how-much-space-an-image-takes-up-on-the-server

@tesparza said in When do I know if image replication is done on a Storage node?:

Also when installing the Smart Installer client, what IP do i put.

fog-client communicates with the main FOG node.

@tallier Nor sure of we understand what you mean by “image de Fog”. Do you mean the captured image - probably a Windows installation?

@Mike-Fahey Just tried on a 1.5.9 install and it works perfectly fine for me (Firefox on Debian).

Possibly a browser or caching issue? Trycleaning the cache and using other browsers.

@sebastian-roth We don’t have a proxy server. Our iBoss web filter might be something I need to look at.

From what I’m finding this may be a router issue. I created a VM FOG server on VLAN 192, connected the client to the same VLAN and successfully PXE booted. When I plugged in the client to VLAN 194, PXE times out on http again. Are there any suggestions to resolve this?

I saw in this post https://forums.fogproject.org/topic/12368/fog-dhcp-server-on-multiple-vlan-network/4 mention of properly configuring Windows 2012 DHCP by Goerge1421. He also mentioned PXE roms may be an issue.

"Lets take a step back here. With such a complex network why are you using the FOG DHCP server instead of your network infrastructure dhcp servers?

FOG does work across subnets, what you need is the dhcp server responsible for those other subnets to set dhcp option 66 to the fog server IP and dhcp option 67 to the boot kernel. The issue you will run into now is that if you have both bios and uefi systems on your network, your dhcp server will need to be smart enough to send the right boot kernel name based on the target hardware. Windows dhcp on 2012 and newer will do this correctly if configured right. Linux dhcp server does that automatically like FOG uses.

If you have inter vlan routing working correctly, you can/should be able to image with FOG. There are some pxe roms that are not very smart and may not like pxe booting across subnets.

Instead of messing with all of these dhcp helpers, you should take a step back and answer what device provides your dhcp services for these other subnets?"

@omegaxis said in Failed to get IP VIA DHCP:

I am able to pxe boot vm’s within the server just fine

when I try to boot a thin client that is attached to the same cisco catalyst 2960g switch, i am getting the dreaded failed to get ip error.

Meraki mx64 functioning as DHCP
Cisco Catalyst 3750-E as backbone
catalyst 2960g as endpoint switch where both the server and the computer I am trying to pxe are.

So lets think about what I’ve outlined. You can pxe boot a VM on the hypervisor just fine. But a physical machine attached to your 2960g can’t get ip error.

Is your meraki dhcp server issuing ip addresses to the VM, or is that coming from some other dhcp server? If you plug a windows computer into the 2060 does it get an IP address? Is the virtual switch where your FOG server is connected bridged to the physical network or is it Nat’d? (I don’t know unraid as a hypervisor to give directions to check) We may want to get a pcap (packet capture) of the pxe booting process to know what is really going on. We can/should use the fog server to capture its side and then a witness computer with wireshark to capture the virtual side. I have a tutorial on using the fog server to grab a pcap. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue for wireshark you can use the capture filter of port 67 or port 68 if you don’t use a capture filter you can use a display filter of bootp. Capture both the what fog server sees and what the witness computer sees. My guess is the FOG server will not see the dhcp request.

Looking at the pcap you should see a typical DORA response.
Discovery (client sends)
Offer (server sends)
Request (client sends)
Ack (server sends)

If you look into the Offer packet, the dhcp server should set the {next-server} and {boot-file} fields in the ethernet header as well as dhcp options 66 and 67 in the options section. Both groups need to be there.

In my experience using a router or switch as a dhcp server does not give good luck because many do not handle the dhcp pxe boot settings well. Many for some reason will list the router/switch as the {next-server} even if they have a setting for a boot server. In this case you need the fog server IP configured in {next-server} and dhcp option 66.

@goll420 Ok here is a quick explanation of why the suggestion. iPXE has 2 basic sets of boot loaders. One boot loader has all of the known network drivers installed and only uses a single standard driver that interfaces with the firmware on the network card. This is the same idea for both bios and uefi.

For bios the standard driver is undionly.kpxe (fog recommended)
For bios with the all included network driver its ipxe.kpxe

For uefi the standard network driver is snponly.efi
For uefi the all included network driver is ipxe.efi (fog recommended)

For the FOG recommended boot loaders. The undi driver for bios is very old (~20 years) and very stable. The snp driver for uefi is new (~6 years) and in the early days not very dependable. That is why FOG recommened the ipxe.efi (all native drivers). With new hardware coming out the iPXE boot loader community can’t keep up with really new hardware and the snp network drivers are getting more mature. So the FOG developers at some time may switch their recommendation to the snponly.efi, but not today.

One last bit of info, its up to the network card manufacturer to write the proper snp driver into the network card’s firmware. Some do this better than others.