I’m with you @Sebastian-Roth, while the idea is nice, it’s fairly difficult to setup. We’d need the client to send the logs and a place to store the information. While storing wouldn’t be too hard to figure put, it would mean space. Even though log files are relatively small, many logs would still add up. And that’s before we even start displaying the log in the gui.

There is another way to get the info, by say having it request the log directly from the client I suppose, but then you’ll be fighting Windows firewall i would think. It’s not impossible to do but I think if you’re looking at the logs because of an issue, likely you’d have an issue getting the log remotely as well.

@robertkwild The syntax is slightly different from SYSLINUX style, but there are a lot of examples of how to create menu’s throughout the forums and on the WIKI.

https://wiki.fogproject.org/wiki/index.php/Advanced_Boot_Menu_Configuration_options
https://forums.fogproject.org/topic/10403/boot-iso-from-ipxe-menu
https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

These are just some of the many numbers of examples that hopefully can help you out.

@Fernando-Gietz said in Multicast data address not change from one task to another one:

Se añade esta linea para que asigne direcciones IP diferentes a cada tarea multicast

I’ve added the patch, but a little more checking involved. This has been added to both the working and working-1.6 branches. It tests the set value for the $address variable. If this variable is set, it will calculate the address. Here’s the snippet of lines:

if ($address) {
    $address = long2ip(
        ip2long($address) + (
            (
                $this->getPortBase() / 2 + 1
            ) % self::getSetting('FOG_MULTICAST_MAX_SESSIONS')
        )
    );
}

Hopefully this will address the problem people have been seeing and allow the use of multiple sessions.

You are not required to run sysprep for windows machines, this action just makes your image less hardware dependent (or allows you to put the image on different machines if that’s easier to follow.)

Anytime I’ve created a linux image, I just copied it as is. As using the kickstart method, you might as well just setup FOG PXE to pass out the linux install and where to get the kickstart file from.

@Jim-Holcomb Yes, you’re on working-1.6 and I’ll be helping with that here shortly.

@Fernando-Gietz this is what I hope to move to in the future but this is not in use currently. The tablename and install method are not used for the core elements and those where just a placeholder until I can mimic the proper table layout for the item.

It is not in use for core elements.

@Sebastian-Roth that’s what I was thinking just wanted full understanding.

When you say hangs, do you mean it’s hanging at a certain point in the imaging process, or it never makes it into FOS?

If it makes to imaging and then hangs, where is it hanging?

If you could, see if you can take a video of the issue from boot until the point of hang, this may help us better see where and what the issue is.

@mmoore5553 That’s what makes me think networking is the problem. As you’re saying this is happening on a VMWare Workstation, this make me think the installation is not bridging to the “real” network adapter that is connected to the managed switch.

I’d almost guess that the machine you’re running VMWare Workstation from probably can’t even boot into fog?

There is means to do USB booting, but I don’t know how to translate that to VMWare Workstation, it’s not even something I fully support (though I’m not afraid to lead a horse where it needs to go.)

This is made by @george1421: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

I’m not understanding your question.

What version of FOG are you using?
What Boot file is VMWare Workstation trying to use to UEFI Network Boot?

My best guess, with the limited information I have, is that you haven’t told VMWare Workstation to boot to ipxe.efi.

I would highly recommend you use a bridged network as NAT network you essentially tell your machine, for lack of a better term, to use the Virtual Switch VMWare provides in a natted environment. This could make the network the Workstation is talking to, incapable of accessing the actual network your FOG server is distributing across.

At this point, I want to say this is NOT a FOG issue, and it likely is NOT a VMWare issue, but rather a networking issue. Either it’s how the network is getting to the VMWare Workstation Machine or it’s how the network is communicating from the FOG server to the point where the network touches your VMWare Workstation machine. (It really sounds like a networking issue, but I don’t know where to lead you to help out more directly.)