Posts made by george1421

In an effort to see if I could get a proper configuration for dnsmasq to offer both bios (legacy) and uefi iPXE kernels to the booting target I came up with this after reading many (many) configuration docs.

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
# dhcp-boot=undionly.kpxe,,192.168.112.24

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
# dhcp-no-override

dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI,ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI64,ipxe.efi,,192.168.112.24
dhcp-boot=net:BIOS,undionly.kpxe,,192.168.112.24

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Press F8 for boot menu", 10

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
# PXEClient:Arch:00000
pxe-service=X86PC, "Boot BIOS PXE", undionly
# PXEClient:Arch:00007
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
# PXEClient:Arch:00009
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi

dhcp-range=192.168.112.24,proxy

Running wireshark with the above configuration actually sent the right dhcp options to the target computer, but alas the target computer would not boot. Looking at the packet capture I can see the target send out the dhcp discover and both my home router and the dnsmasq device (fog server) respond. But the target never sent a dhcp request, it only started the process again sending a dhcp discover again.

For clarity the FOG server and dnsmasq is running on my FOG-Pi server running raspbian jessie. Dnsmasq version is 2.72. The target computer is a Dell e6230 switched into uefi mode. In the above configuration file 192.168.112.24 is my dnsmasq/FOG-Pi server and my dhcp server is a home router running factory stock firmware.

@dureal99d From your image below its working. Well an iPXE kernel is getting loaded. So that should removed dnsmasq from the issues. Is your fog server at 192.168.1.1?

@dureal99d If I understand it correctly your {next-server} value should come from your dhcp server (understand I’m guessing here a bit since I have not worked with uefi and dnsmasq as of now). But in my docs I also ahve this line:

dhcp-range=<fog_server_ip>,proxy

That defines the range.

Actually I still have my FOG-Pi server that I can boot back up. That has dnsmasq running on it. Let me see if I can get a working config.

In my tutorial for installing dnsmasq on Centos this is what I have for the dhcp-boot line:

dhcp-boot=undionly.kpxe,,<fog_server_IP>

Also you need to ensure that you are running dnsmasq 2.76 with has reportedly added the required code for pxe-uefi booting alongside legacy (bios) code.

I have not tried this with dd-wrt either but this extension should work with dnsmasq

dhcp-match=set:efi-x86_64,option:client-arch,7
dhcp-boot=tag:efi-x86_64,ipxe.efi

which sets up a flag if the client matches arch 7 (x86_64 uefi) and then sends ipxe.efi instead of undionly.kpxe. You may need additional arch added for IA32 uefi systems too. Wayne has added the info to the FOG wiki page https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#General
Look at the top for the isc dhcp server to an idea of what is going on.

@Wayne-Workman Just for clarity the installer now uses the right php install sequences and the command line variables are not needed when the installer is called? The pages still reference using the command line switches.

@adukes40 We went with LTSB for a few reasons, not having the consumer apps was one, the other was the longer refresh cycle. CBB will force an update even if you mark it to delay the upgrade. The force update will be 6 months after the current release was released. We have to verify each of our core applications work before we can release an new OS and twice a year is a little much OS thrashing. As soon as we would get one version tested and approved we would have to start on the next release. That is a bit crazy.

[edit] FWIW: I was just able to get CBB 1607 to create cleanly with mdt and windows updates after a bit of hacking about. The late sept 1607 cume update and setting the delivery optimization to 100d fixed the wsus updates getting stuck issue.

@adukes40 Only in the dev lab. We are not quite ready to roll it out to the organization. But it does work in the dev labs. We are still fine tuning the GPOs to get them to work like we want them.

@adukes40 Yes. I suspect the 2016 one should be in the works soon. I think 2015 LTSB dropped in Nov of 2015.

But right now CBB 1607 has issues with WSUS updates not applying, so I suspect they are trying to nail that one down first. (edit: Actually I just found an article that says LTSB 2016 will be released on Oct 1 [today]. Its unclear if that date is still valid or not).

@Scott-Adams How are you removing this applications? You have to uninstall them from the current users and then remove them from the system. The last time I built a win10 reference image (on CBB 1511) I was able to do it and sysprep without any issues, but I used a powershell script to extract the unwanted applications.

@RobTitian16 Either way you will have the replication time impact your ability to use that new image. Depending on the pipe size between the UK and US you may be talking about days for replication to happen. The bad part of days to replicate. You won’t be able to use the existing target image at the remote sites until the replication completes because FOG uses an in place replication process. You can throttle the bandwidth used for replication but not based on time of day. I’m not trying to turn you off to FOG, just point out a few pain points. Will FOG work for you yes, there are just some things that have to be thought through.

As for the process being documented. No. Its not officially supported setup but it works. The risk is that if its documented then someone might think it is a supported process by the developers. The import and export of the db configurations is done via the web gui so that is pretty straight forward.

The officially supported process is with a single master node and storage nodes at each location. Replication happens just like in the multimaster setup, except that each storage node (Which is a full FOG server with the database) uses the database on the master server. So the remote storage nodes must be in contact with the master node for imaging to work. In the case of a multi-master node the remote sites only get their images from the master node (with the images being pushed from the master node). So each site’s fog server runs independently of the others.

@pencils said in everything installed. But management page not displaying correctly.:

@george1421 sorry george, not a linux guy.

First to answer your question you need to be in the mysql tool. You will probably want to run this command mysql -u root There should be no password on the database since you are root. Once you are at the mysql command prompt then you can use the alter user command.

Second, you are not a linux guy and you are manually installing bits of fog. My intuition is telling me you have a botched install. I will repeat my recommendation (especially if you are doing this in a vm). Create a new system, install 16.04 (or 14.04) then install the 1.3.0-RCx version of FOG. You will have less issues with Ubuntu, plus with 1.3.x series you will get support for the latest hardware, gpt disk format, NVMe disk, Win10 support, faster speed, new features, and brighter teeth and fresh breath

@pencils FYI: That is a mysql/mariadb command. You should be using the mysql command line tool.

I think you would be better served if you install FOG 1.3.0-RCx series which supports Ubuntu 16.04.

There is some guidance on installing FOG 1.3.x on Ubuntu 16.04 this is required since Ubuntu change this release greatly from 14.04. https://wiki.fogproject.org/wiki/index.php?title=Ubuntu_16.04_Server

Could you clarify what “extra stuff” you are talking about?

Is that extra stuff that comes with FOG, or extra stuff such as you want to boot iso images, and foreign kernels via the FOG iPXE menus?

Just to be clear, the FOG Client is service that gets loaded into a target OS to allow the FOG server to interact with the target OS. Les make sure we are talking about the same function.

@Kris-Phillips Can you do this for us?

Remove the image, or register a new host, but don’t assign an image to it.

Then from a browser key in http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=<mac_address_of_system_registered> and press enter. That should create the ipxe boot menu in the browser. If you are doing this on a deploy image task then deploy the image and do the above step. The developers will probably need to see where its breaking in the iPXE menu (even though this is through a deploy, ipxe is used on bootup then it loads the FOS Engine to deploy the image).

@BASURILLABAS2 So do we have a root cause yet of this issue? Disk (organization, failure, structure), attempting to resize a really big image?? I’m finding this a unique issue that will probably come up again.

@sudburr Thank you for posting back there is another FOG user that is having a problem with similar hardware. Your insights may be valuable with his issue too.

@wcheung In the link that Tom posted [ https://forums.fogproject.org/topic/7302/lenovo-thinkpad-yoga-260-w-lenovo-thinkpad-usb-3-0-ethernet-adapter-fru-03x6903 ] The Op just posted he has success with a Yoga and ThinkPad in uefi mode using a Onelink+ to rj45 adapter. It may be worth your while to review his thread.

@Tom-Elliott I thoght that either Sabastian or you added a loop to the network startup code where it would check wait, and then check again for the a link or dhcp packet to be received before giving up on the interface. This was done to mask the spanning tree issue (I know this is not the case here) but it would seem the network link is slow to come up for some reason.

Rob, you have a couple of options here depending on how you want to manage your FOG install and how fast (big) is your UK to US link.

One option is to setup a storage node in the US. If you are using FOG 1.3.0-RCx then the storage nodes already have the tftp kit built in. In this case you will surely want to use the location plugin with FOG and then define a location for the UK and a second one for the US. Actually I would create a location for every physical location you have. That way the FOG clients will always connect and image from the storage node that is closet to them. The down side to this is if you are using the FOG client on the target computers they will check into “ping” the FOG server every 5 minutes for new instructions. If you have a vary large number of computers this check in may consume all of your site to site communications.

The other method is not currently supported in fog but works very well and what I use at my company. This is called a multi-master node setup. In this case each location has their own FOG server that the local IT techs use like a stand alone server. But in our case the images are managed at HQ. So what we have is at HQ a development FOG server (where we create and test the new images). ON that HQ development server we have a storage group setup. In that storage group we have the HQ development server as the master and each site’s FOG (master) server setup as storage nodes. So when we approve and release a new image at HQ it is replicated to each site’s FOG server automatically. As long as you are only updating master images this process works flawlessly. If you add a new image to the Development FOG server at HQ, you must export the image definitions and then import them on each of the sites fog server. Understand that replication will happen automatically, just the sites will not be able to see this new image until you upload the image definition on the remote sites FOG server. While this process sounds a bit complicated its not. Plus it has the advantage that each site’s IT logs into their own local FOG server so they can’t accidentally deploy an image to a remote sites computer (i.e. Site A tech can’t deploy an image to site B’s computer by accident).