Moderators

Private

Posts

  • RE: FOG Multicast on different VLANs

    @sega said in FOG Multicast on different VLANs:

    So some people already tried it?

    Yes and so have I. You would need some way to dynamically change the network adapter defined in the global FOG settings to change the network adapter. You might also need to change a file called /tftpboot/default.ipxe to point to different interfaces. You might be able to get around this by setting up multiple tftp servers on the fog server, where each tftp server bound to a different interface and had a different home directory, that would be more of a long term change. And then you need to work out a way to update the imaging network interface in the fog settings depending on what interface you wanted to image using. There may be more crafty ways about doing this, but this is just off the top of my head.

    posted in FOG Problems
  • RE: FOG - Label Print....

    @ecoele I can say this option will not probably be added by the developers since its such a niche or one off requirement. But I’m not speaking on behalf of the developers, I’m just stating my opinion. Its up to them to decide if a feature request has merit.

    But fog being opensource its free for you to modify to your needs.

    What I can tell you that there are several user defined fields you are free to add whatever data you want. On the database side I think the fields are called user1 and user2.

    The second part is that FOG’s database runs on mysql (mariadb). This is much like any other sql server. If you have a windows computer and the mysql odbc driver installed you can query the fog database from a reporting writing tool running on windows. From there you can print labels, etc. You could do something as an excel macro to query mysql on the fog server.

    Again on the mysql server, you could program something on the fog server in either python or php to extract the data from mysql.

    posted in FOG Problems
  • RE: FOG Multicast on different VLANs

    @sega said in FOG Multicast on different VLANs:

    I wanted to try to run multicast, but sadly our switches are just Layer 2 switches and they don’t support that on other VLAN (as far as I read, not a big network guy myself).

    Layer 2 switches are good enough. Hopefully they are managed switches, that will make them work a bit better. Turn on igmp snooping on the switches. What that will do for you is enable sparse mode (i.e. only ports part of the multicast will transmit multicast data) without it the switch will work in dense mode where multicast traffic will be sent to all ports (impacting the bandwidth of devices not part of the multicast).

    Muticasts are typically restricted to the current vlan. Where the magic happens is on your router between the vlans. Your router needs to be configured to forward muticast traffic between the vlans. This is typically done with a igmp helper / proxy / relay service much like dhcp needs a helper service to forward dhcp traffic from remote vlans to the vlan that has the dhcp server. This service running on your router will send the multcast data between the subnets.

    So my idea was now: The FOG server is running on a VM, is it possible to give that machine just 4 more virtual network adapter (for each VLAN one) and reconfigure the IP address on the clients to one thats on there VLAN? Somehow I think that would be too easy.

    This won’t work because when FOG service was designed it was designed to only support a single imaging network. Your fog server can have 4 network adapters, but only one can be the imaging network adapter. The rest will only work as management interfaces.

    Or do I need to have a second FOG Server in that specific VLAN that just using the main FOG storage?

    If you have no other option you can use a fog storage server here on the remote vlan. The issue is that only the FOG server supports muticasts. The fog storage nodes only supports unicast imaging.

    posted in FOG Problems
  • RE: Dell OptiPlex 3000 Thin Client

    @phant0mbot said in Dell OptiPlex 3000 Thin Client:

    have tried both SAN and GRUB exit options

    boot loader == snponly.efi

    These are in contradiction with each other. SAN boot and Grub are bios boot methods. snponly.efi is a uefi boot loader. Since you are getting into the fog iPXE menu we can assume the hardware IS uefi based since it is booting snp.efi. Try a uefi exit mode of rEFInd (refind) to see if that will boot from the hard drive. The default value can be set globally in the fog configuration->fog settings page. Don’t force a bios attempted boot from a uefi booted computer, that never works.

    posted in Hardware Compatibility
  • RE: Dell OptiPlex 3000 Thin Client

    @phant0mbot said in Dell OptiPlex 3000 Thin Client:

    The Thin Client is able to pxe boot and accepts the image, but then can’t get past booting the final time.

    It just attempts to boot from hard drive on the Fogproject Menu and keeps refreshing.

    1. Just to be clear here. You CAN get to the FOG iPXE menu?

    2. What happens when you pick a FOG iPXE menu. This will cause bzImage and init.xz to the target computer. Does the kernel attempt to boot?

    posted in Hardware Compatibility
  • RE: How do i add more storage space to my Fog Storage repository

    @Jchinn412 The answer is it depends on how you have your disk structure setup

    Post the results of these two commands.

    lsblk
    df -h

    It maybe easy or harder (but not impossible) depending on how you have the disk created.

    posted in Linux Problems
  • RE: Using if/then during PXE boot for proper boot loader

    @aurfalien The arch value is not going to be fine grained enough for what you want.

    This is a short table of what is available in the arch field.
    Arch:00000: This is often associated with the non-UEFI, or legacy BIOS, boot process.
    Arch:00007: This value typically indicates a 32-bit UEFI system.
    Arch:00009: This value identifies a 64-bit UEFI system

    So if you want to send bios or uefi boot loaders this is the method you want to use.

    But from your post you want to switch between "undionly.kpxe while others the ipxe.kpxe " This are both bios boot loaders so the arch value == 0 for both hosts.

    …However would you know how I can determine the client-arch value for a particular host?

    If you know how to use wireshark you can get the answer you seek. Take a witness computer (third computer not part of the pxe booting process) and load wireshark on it (you may need to disable the windows firewall for this) Plug this witness computer into the same subnet as the pxe booting computer. When you startup wireshark set the capture filter to port 67 or port 68 and then select your ethernet adapter that is plugged into the same vlan subnet as the target computer. With the witness computer scanning pxe boot the target computer. Keep the scanner running until the pxe booting computer gets to the fog menu.

    Now stop wireshark from scanning. Look at the packets it captured, it should have captured about 4 if you setup the capture filter correctly. If it collected a lot of traffic (like if you forgot to set the capture filter) set the view or display filter of bootp.

    So with the 4 packets these should be the DORA packets Discover, Offer, Request, Ack/Nak. What you are interested in is the Discover packet, this is from the target computer saying hello world. Look into this packet. Scroll down the list of values until you see the dhcp options. To see the arch value its in dhcp option 93 or 94, or right in that area. You can use most of these dhcp options to set special filters on the dhcp server and then send different boot files depending on the values. You need to find what is unique between these systems so you can tell the dhcp how to react when it sees that particular value from the client during the discover / offer part of DORA

    posted in General
  • RE: Using if/then during PXE boot for proper boot loader

    @aurfalien I’m right there with you. The iPXE menu can also do a if/then action but that is more limited than what you can do on the dhcp server side.

    OK so it looks like your dhcp server is linux based and not via windows or third party.

    So to my question, what is unique you can identify (from a computer standpoint) so your dhcp server knows which boot loader name to send out?

    The method to take really depends on the number of clients you are looking at and what the uniqueness of the machines are.

    When a client computer starts the DORA process for pxe booting it sends out a DISCOVER packet. That packet tells the dhcp server about the client. Those parameters can be used to customize the OFFER response back from the dhcp server.

    Common parameters might be if the client is uefi or bios, or x64 or x32 architecture, mac address, or stripping out the manufacture from the mac address, or system UUID.

    The simplest and most accurate method is to send the unique boot file based on the mac address.

    for the standard isc dhcp server you would put in something that looks like this for each host. The host specific settings will override the pool options.

        host myhost01{
            hardware ethernet 00:11:22:33:44:55;
            filename "undionly.kpxe";
        }
        host myhost02{
            hardware ethernet 00:a1:b2:c3:d4:e5;
            filename "ipxe.kpxe";
        }
    
        # General configuration for other clients
        subnet 192.168.1.0 netmask 255.255.255.0 {
            range 192.168.1.10 192.168.1.200;
            option routers 192.168.1.1;
            filename "snponly.efi";
            next-server 192.168.1.100;
        }
    

    While that is the most accurate and simplest to implement if you have just a few hosts, if you are dealing with 100s of hosts that might be challenging.

    If your targets have multiple network adapters you could use the system UUID (if the vendor populates this field)

        # Define a class for clients identified by a specific UUID
        class "uuid-clients" {
            match option dhcp-client-identifier;
        }
    
        # Host declaration for a specific client identified by its UUID
        host myclient {
            option dhcp-client-identifier = 0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f; # Replace with actual UUID
            filename "ipxe.efi";
        }
    

    There are options but the path forward depends on the number of hosts you are trying to manage.

    posted in General
  • RE: Using if/then during PXE boot for proper boot loader

    @aurfalien The quick answer is you can’t do what you want with an if/then in iPXE. I’m not saying there isn’t a solution but with iPXE it might be difficult.

    So lets start with undionly.kpxe and ipxe.kpxe. Undionly.kpxe uses the undi driver built into the network card. Almost all bios cards in the last 20 years support the undi driver format that is almost 30 years old. The ipxe.kpxe boot loader uses iPXE built in network drivers, much like linux has built in network drivers. I’m finding it strange that undionly.kpxe doesn’t work where ipxe.kpxe does work. These must be some really old network cards where only ipxe.kpxe only works. Lets make sure you don’t mean ipxe.efi (which is the uefi driver version).

    So from a programic standpoint how will the system know what iPXE boot loader to pick between undionly and ipxe? What is unique between these two systems?

    How many systems are on each side of the fence?

    The solution lies in your dhcp server. We have some options as long as the dhcp server can tell or identify system A get boot loader X and system B gets boot loader Y. We’ll need more background information here to give you a complete solution.

    posted in General
  • RE: Windows 11 + NTLite + Fog Projects

    @gaptoothgonni Well darn, have you tried booting with snponly.efi instead of ipxe.efi? It wouldn’t make a ton of sense if that worked but something else to try.
    If it’s booting to the wim though, it should just be getting the drivers from the wim unless ipxe somehow changes how they’re presented, which I don’t think it does but that’s also the only difference between where it’s working. Might be worth looking at https://github.com/ipxe/ipxe/discussions and seeing if anyone has had similar issues. Since you’re just using FOG to create the ipxe boot menu, it’s not likely anything within FOG that’s causing this. You could try ipxe’s pre-built boot files, though they won’t have the embedded fog stuff https://boot.ipxe.org/ but maybe will make a difference. There’s other ipxe efi files you can try too, or try an older one ( I think we still include some legacy ones in /tftpboot)

    posted in Windows Problems