@Wayne-Workman I’ll have to confirm that. The last time I checked all files in the /images folder was replicated to the storage nodes even if they were not specifically called out in an image or the database. The only exception was if the images were in */dev and */ca.

I can test this today since I just rebuilt the POC system this AM with the latest build. But again, I want to avoid having to dive into the OS to move things around. While I have the necessary skills to do this, not everyone will or should have the access to do this.

@Wayne-Workman Just looking at drawing a connection here. All three files (kernel, inits, client) are downloaded via wget. If wget is in place then DNS resolution may be another issue. But starting with manually downloading the client agent will give us a better idea of the error.

Is wget installed? The installer uses wget to pick up the files from the sourceforge servers. I might also expect the database backup to fail too if wget wasn’t installed.

If wget is installed then see if you can use wget to download the client image. There should be a warning message during the installer script. Copy that out and run it manually from the command line. That may give you a better understanding of the error.

I have seen proxy servers give issues if things are not setup correctly (I have one in my current environment). But you stated that there is no proxy server, so we won’t go down that rabbit hole.

Update the installer script to add the logic to automatically install the tftp boot files onto a storage node. I understand that not all storage nodes will be used for pxe booting. But add the required files just in case the node will be used for PXE booting. There is no risk to having the boot files or the tftp service installed if not used (xinetd managed the starting of the tftp process anyway). By adding this function to the storage node you can avoid having to enter into the host os to manage the files, or setup rsync to copy the files from a pxe boot server as new versions come out.

The other folder route might work, but I don’t think I can capture an image to a different folder (??). As for the replication (unless something has changed recently) if a file exists in the /images folder the replicator will copy it dutifully to all nodes in the storage group. If you have a multi site setup the link at HQ is typically pretty utilized already. Adding additional useless traffic to that link is something we want to avoid.

We can proceduralize this today if we setup a development FOG master node where the images are developed. Once we have the golden image, we could rsync it to the production master node and then manually create the image information on the production master node. While it should work it does require host OS access and someone with the authority and skill to do this. I’m trying to avoid diving into the OS for a solution to this if at all possible.

Issue: When working through a normal (initial) image development process we may capture several reference images before we settle on a golden image. If we have a multisite setup with a storage node in each location, as we capture these intermediate images these images are automatically replicated to the remote storage nodes consuming bandwidth and space on the remote storage nodes. We need a way to capture an image but have it remain on the master node (unpublished) until we determine that the image is golden and then publish the image to the storage nodes.

Some of these images could be several GB in size and may take up to a day to completely arrive at the remote storage node. Currently there isn’t any way to indicate the replication has finished via the GUI. If we try to deploy an image before the sync has fully completed the deployment will of course fail. This could be managed externally via a manual workflow process, but ideally the management interface should block deployment of the image until it completes to the defined location.

When I select create new access control item the search page is displayed instead of the add form. No error is thrown in the apache error log. The list all access controls does change to no access controls found (accurate since I was trying to add one)

Unless I’m missing something. Your storage node in Melbourne is in th storage group Melbourne. This is understood. But in the Melbourne what is the master node? IMO the Sydney server with ip 192.168.23.10 should be the master node in the Melbourne storage group. The Sydney server can also be a member of the Sydney storage group as a master node. What I see right now (reading the tea leaves a bit) is that in each storage group you only have one device. One group has a master node and storage node with the other group has just a storage node. There is nothing to copy in this setup because each server is in its own group. You need that linking connection.

While I’m just looking at the obvious here.

In the top picture it says Melbourne storage node in the bottom it says Sydney storage node. What groups is host 192.168.20.8 really in? Is it in the Sydney or Melbourne group. What ever group its in, is both 192.168.20.8 and 192.168.23.10 in the same storage group, 192.168.23.10 configured as the master server?

I also noted the date on the second group. Is it really 12/2 there. I don’t think the date comes into play. I just want to ensure the date is consistent between the two servers.

@jukka2015 Ok then, my first recommendation is for you to start a new thread so this one doesn’t get polluted with off topic discussions. Then we can focus on your specific needs.

@jukka2015

Not sure I totally understand what your goal is.

But for the easy part first. You have to be running the SVN trunk build (pre 1.3.0) not the 1.2.0 base. Under the fog settings there is the ipxe boot menu. You must add a new entry then you can set the options to display the new menu item depending on the state of the target computer (new, undefined, all, etc [stating from my memory]). You can add in the iso image as I outlined below. Also @Wayne-Workman just updated a wiki about adding items to the ipxe menu.

Now about the part I’m not sure about. Do I understand that you want to remove most of the standard FOG menu items except for a select few? If that is the case you will need to edit the mysql database. Before I go into that, lets make sure that is what you want to do. (personally I don’t recommend this approach [tweaking the database] because there is no way to know how it will impact FOGs execution, stated as a non developer). Wayne kind of laid out what needs to be done to the database about midway down in this thread.

I created a post a few days ago about booting a MDT iso image via the ipxe boot menu. This may help you on your quest as long as you are using a svn trunk. The only thing I think I would change from this post is to move the place I stored the iso image out of the fog directory directly. In the instructions I said to place the files in /var/www/html/fog/iso , moving forward I would put them in /var/www/html/iso This location is still addressable by apache but won’t collide with anything in the fog distro.

https://forums.fogproject.org/topic/6161/debian-8-fog-trunk-pxelinux-on-ms-server-and-ms-dhcp-help/15

@Vinnie said:
Since we have done this, the HP ProBook 450 G3 no longer connects to FOG at all. We have seen this before with laptops, but once we run G-parted on them it fixes the problem.

Can you explain this? I see a contradiction in your statement. You can’t connect to the fog server at all, but you fixed this in the past with gparted correcting a disk partition assignment?

The first statement is a communication issue and the second is a hard disk partition correction.

Where precisely is this failing? Do you see the ipxe part of the boot load? Can you see the fog ipxe menu? Do you see any error messages?

@Wayne-Workman said:

@StefanTS @george1421 I did recently ask the iPXE guys about network booting… They said something to the effect of - not all filesystems support being accessed over HTTP, and they recommended mounting the ISO as read only via NFS, and then having the boot menu entries point to that.

See that’s where we need a bit of clarification on the OP post. Looking at the additional information provided, I don’t see any reference to an ISO in his commands (even though he did mention it in his OP) What I see from his commands are sending the kernel and init file system to a target machine via a menu item, much like how FOG works. But then he also mentions tasks and the task type table. Which makes me think he might be trying to deploy this to a client machine and not via the FOG ipxe menu as I originally thought.

Yes it is possible. There is a wiki that shows how to do this (I will look in a minute). The idea is that the dhcp server looks at the bootp request to find out the kind of client just asked for an IP address. If an EFI client asks for an IP address it sends the boot file name ipxe.efi file if it is a bios client then it sends undionly.kpxe.

Let me see if I can find it.

[Edit] Here you go: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence The arch type of efi x86 is 00006 and efi x64 is 00007 [/Edit]

OK, if I understand what you want to do (Add a custom ipxe boot menu item). I have been able (on paper) put together a partial solution for you. This solution assumes you are running a SVN trunk upgrade from the core 1.2.0 release.

If you go into the FOG settings and add a custom IPXE menu item. Add these settings:
Menu Item: Dutch.Exams
Description: Dutch Exams Example

Parameters:
kernel /bootimages/facet/vmlinuz0 rootflags=loop initrd=initrd0.img root=live:/configured-bcld.iso rootfstype=auto ro rd.live.image rd.live.ram rd.luks=0 rd.md=0 rd.dm=0
initrd /bootimages/facet/initrd0.img
boot || goto MENU

Then press save.

You can view the results of this setting by pointing your browser at the following url
http://<fog_server_ip>/fog/service/ipxe/boot.php

This will show you the ipxe menu that will be presented to the ipxe menu application

The file path on the fog server is (on rhel) /var/www/html/fog/service/ipxe/

Now the part I don’t know about. You will notice that in my ipxe menu I have a path for the boot kernel. I don’t know if we can create a symbolic link from the path above to where your files are stored and then include that in the ipxe menu command. Or just go the easy route and dump your exam kernel and initrd files in /var/www/html/fog/service/ipxe I think it would be safer for your files to have a sym link from /var/www/html/fog/service/ipxe/<something > to your file location.

As I said (on paper) this should work without having to dig into the FOG code if you are willing to use the SVN trunk.

I found a wiki that talks about setting up dban under FOG: https://wiki.fogproject.org/wiki/index.php/Include_any_ISO_in_the_FOG_Bootmenu

@StefanTS Hacking the FOG code is not recommended. Doing so will trouble you for each upgrade that will come. The update cycle is much faster than between 0.32 and 1.20.

With that said, what are you doing here? I read your post two different ways.

1. You want to PXE boot certain clients with a custom boot image via the fog menu. This boot image works when booting from a CDROM.
2. You have an exam application supplied via CDROM ISO image and you want to deploy that to 30-60 computers.

If you have an existing ipxe settings files that information will help. The trunk version of FOG has many new features not available in the 1.2.0 core image. Just a word of warning on the trunk version (pre 1.3.0), this platform still has a few bugs in it, but it is very usable. The bugs are stamped out by the devs as soon as they are reported. If you want to test the 1.2.0 SVN trunk I would do this on a new VM/hardware so you don’t run the risk shutting down your production environment.

Anyway the SVN trunk allows you to add custom pxe menu items from within the FOG GUI.

[Edit] Sorry I just saw your post with the ipxe settings. Let me see if I can do the same thing with my FOG test VM. [/Edit]

@Wayne-Workman Interesting. (I’m still learning about UEFI) I thought to install a UEFI image, you had to boot in UEFI mode and place the image onto the system in UEFI mode otherwise the bios won’t be updated correctly. If we can boot in legacy mode and end up with a fully functional system booting in UEFI mode after deployment then this issue is not as big of a problem as it would appear.

@Wayne-Workman Me too. I’m showing about 400 e6430s and ~800 7010s in our company.

We were going to start Win10 image development. Just after the first of the year. We may have to rethink our deployment tool if the ipxe wizard’s can’t figure this out. I’m a bit spurised that this issue hasn’t came up before. These 7010/e6430/L530s are 3 years old. If we play our cards right, we may age the Dells out before we get around to deploying Win10 to them.

Looking at the Lenovo L530 specs. That also uses the Intel HD 4000 graphics (same as 7010) and possibly the e6430 (I didn’t confirm that the exact computer I tested had the intel HD 4000 or the Nvidia) Both were options for the 6430.

The L530 chipset is the ivy bridge. The system was manufactured by Lenovo in 2012, which is about the same vintage as the 7010 and e6430 from my fleet. I don’t have enough details yet to draw a positive conclusion but there is a lot of similarities between the L530, o7010 and e6430