Posts made by george1421

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

Continued testing:

e6410: UEFI not available.
e6420: UEFI available, UEFI pxe booting not allowed. Boot via efi flash drive using the debug ipxe.efi no problem.
e6430: UEFI available, UEFI pxe booting allowed. Booting either via PXE or generated debug messages (same as 7010. Also noted the 6430 and 7010 where purchased the same year).
e7440: UEFI available, UEFI pxe booting allowed. Booted correctly with either PXE or USB
e7240: UEFI available, UEFI pxe booting allowed. Booted correctly with either PXE or USB

OK, so I started digging into the details of the 7010 and the 6340 then comparing them to the 790 and 6420. The thing (from the spec sheet) that is in common between the 7010/6430 is the chip set with Q77/QM77 respectively. The 790/6420 has the Q65/QM67. I thought the graphics were the same between the two but on the 7010 we have the Intel HD4000 (integrated) and on the 6430 we have Nvidia Nvs 5200. All four systems use the intel 82579LM ethernet nic.

@Sebastian-Roth Sorry to get you excited. I see I should have been clearer with my table.

UEFI pxe booting no == PXE booting in UEFI mode is not supported.

The only system that failed to boot via ipxe.efi is the 7010. All others that supported UEFI will boot the debug version either via USB or PXE (where available)

So the question I have now is, what is physically different between a o790 and o7010 ??? I’m finding it less likely that its a nic issue since both the 790 990 and 7010 use the same intel nic.

Testing so far as follows:

o780: UEFI not available.
o790: UEFI available, UEFI pxe booting no. Was able to boot via efi flash drive using the debug ipxe.efi no problem. FWIW: The o790 uses the same NIC as the o7010 (82579LM).
o990: UEFU available, UEFI pxe booting no. Same results as 790
o7010: UEFI available, UEFI pxe booting yes. Booting either via PXE or generated debug messages.
o9020: UEFI available, UEFI pxe booting yes. Booted correctly with either PXE or USB

I didn’t test any laptops for UEFI booting.

Here is the output from the efibootmgr. Nothing spectacular was found.
0_1448455704315_efibootmgr_v.txt

If I have time today, I’ll go through the computers in the devices lab to see if there are other computers in our fleet that have issues with efi booting. We have a US national holiday Thursday and Friday this week, so if its not done today it will have to wait.

I’m wondering 2 things here.

First, if you use another computer can you use tftp client to download that file. We want to make sure the permissions on that boot file is not blocking access. You can use another linux computer or a windows computer if you install the tftp client (built in to windows 7+).

Second, it worked with undionly.kpxe and now with the ipxe.efi it doesn’t. Make sure there is not a blank space on either side of the text in the dhcp server configuration. I’m not seeing anything strange in the pcap files you supplied.