Posts made by george1421

@george1421 The pxe error PXE-E78 means that the boot server that is either being returned by dhcp either doesn’t exist or that value is not being returned. Lets fix the IP address on the fog server. You can keep it at this address, it just needs to be configured in linux as static. Once you do that you should inspect the content of the /etc/resolv.conf file to make sure it is configured as you need it.

@mkstreet Well the first issue is that the FOG server MUST be at a static IP address (period). The issue comes (even if you use dhcp reservations) just as you noted the resolv.conf file will change based on outside forces. Once the network mode is set to static then resolve.conf should stay put. I don’t know if dnsmasq is forcing a dhcp renew or not, but what you have is not what I see on my FOG-Pi server that IS running dnsmasq.

@george1421 Justs for clarity, the device you are attempting to pxe boot is in BIOS (legacy) mode?

FWIW: Your ltsp.config will only respond to requests from bios (legacy) based computers.

@mkstreet You have a few things going on here lets take the easy ones first.

Unable to resolve internet names.

What does the /etc/resolv.conf point to ? Guess: 127.0.0.1? Your fog server resolve.config should point toward your buildings internal dns server not itself.

As for the dnsmasq, I want you to remove (comment out) the dhcp hosts and ignore at the end of the ltsp.config file then restart dnsmasq. From a sanity standpoint dnsmasq only works on a multinet broadcast so by default it will not cross a router unless you setup stuff on the dhcp relay. So running it on your single subnet is not an issue. Remove those settings to ensure that the right information gets passed out. I confirmed that your ltsp.config file matches my example file exactly. (I added the code block around your config file so it was a bit more readable).

NO change is needed to FOG for dnsmasq since all settings are external to FOG.

@mkstreet OK then let me see if I can put the bits together now.

10.0.253.24 is your FOG server with DNSMASQ running on it.
10.0.253.1 is your router on the 10.0.253.0 subnet. It is also running a dhcp relay/helper service that forwards dhcp requests to your site dhcp server.
172.16.1.1 is your corporate dhcp server that is untouchable (and a bit suspicious at the 1.1 address but…)

As long as the dnsmasq server is in the same subnet as the pxe booting client this setup should work no problem. What Sebastian noted is that your dnsmasq server is handing out the name of the boot-file but its not handing out the IP address of the next-server (so the pxe client is listening to what its getting from the 172.16.1.1 dhcp server).

Can you post the complete ltsp.config file from your dnsmasq setup? Some where you are missing a command. Hint: There should be two spots where you have to enter the IP address of your fog server in the dnsmasq configuration.

@mrayzies You came to the same conclusion I did (as I was finishing mowing the grass tonight, and still thinking about this issue). The fstab being empty is on the FOS Engine linux OS, that I can understand. Your mount command is needed to connect to the target’s local hard drive (which is not mounted automatically by FOS). We have to do this if we want to tweak the unattend.xml in the windows realm of the post install scripts.

@dholtz-docbox This is really a question for the @Developers.

But what I wonder is why (if the UUID’s being wrong is the issue) do you not use the physical partitions reference and do away with the uuid reference all together. ?? But this may be just a simplistic thought to a complex question. The Developers would have more insight on what FOG does when it deploys a unix defined target.

But I can say the skills you just learned will help you when you want to do more advanced things like rename a host or change service boot states via the post install script. So all is not lost.

@dholtz-docbox When you break out of the fog deploy script. You can check out the entire environment. Just use set | more or set | grep postdownload

@dholtz-docbox No menu needed for debug deploy. Just schedule a normal deploy, but in the task create box selected the checkbox for debug. Then the FOG server will schedule the task. PXE boot the target computer and it will do the rest. You should see a couple screens of commands where you have to press enter, but eventually it will drop you to a command prompt. You need bits of the fog script to run to properly setup the target’s environment but you can break out after the image has been placed on the target “your echo command may be the clue when to exit”.

First I can say that post install scripts do work.

Lee also has some excellent examples of post download scripts (again for windows targets) but you can also get a good idea what could be done: https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins

I might put some output in your script so that you can see if it is executing on the target computer. Even a simple echo we are doing this or that.

I can tell you some things that will help you debug post install scripts.

1. Use a debug deploy task. Then pxe boot the target computer, after the target boots it will drop you to a command prompt. You can key in fog to start single stepping through image deployment. When you get to where your script should run hit ctrl-C to exit the fog script. Then you can take a look at your environment and debug your code.

2. When you are at the command prompt of a debug deploy. If you give root a password with passwd you can connect to the FOS Engine via ssh (so you can copy and paste text via putty or what ever ssh tool you use). This help with debugging because you can paste in your script step by step to ensure that everything is working.

3. Remember that your script is running from the perspective of the target computer using the FOS kernel so if you need something that is on the fog server, you will need to connect to the fog server via nfs and download it.

4. The post install scripts runs as root in the FOS engine OS. That has nothing to do with the fog user or the root user on your FOG server. The FOS engine is a complete stand alone linux OS.

@LibraryMark OK I did this before, but its been many years ago.

The concept is that you need a utility that will create a virtualized floppy drive on your computer. This will create a .img file that is the size of your floppy drive. Then you will get the MSDOS/FreeDOS from a similar site: http://www.bootdisk.com/ This missing utility (from my memory) would then take the virtual floppy drive and create, format and install the image from the bootdisk.com onto that virtual floppy drive. You could add other files if you wanted and then when you wrote the contents of the virtual floppy drive to disk everything you needed would be in the .img file. You would take the .img file and install it on your PXE boot server and then load it that way.

I can’t seem to find that utility at this moment, but those are the steps.

[edit]
As I wrote the above, I think it was called VFD (virtual floppy drive) https://sourceforge.net/projects/vfd/

[edit2]

And when we ran a syslinux pxe menu this is what the command that invoked that .img file.

                MENU LABEL Dell Asset Tag Utility
                kernel memdisk
                append initrd=bootimages/win98c.img keeppxe

on our tftp server at the time we had all of the .img files in /tftpboot/bootimages/xxxxxxx.img

I do have to add a legal dislaimer here that doing this with anything other than FreeDOS is a violation of MS's EULA for MS DOS (since you don't own a legal copy of MSDOS for each .img file you create). The intent of these instructions were only meant as a way to show its possible to do, not that it is legal to do.

Do you want DOS or a WinPE environment?

On a slightly different topic I have setup a WinPE usb boot stick that contains the current bios for all of our Dell hardware. I don’t do this via PXE, but it could be done just updating the firmware would mean recreating the boot iso or mapping to a network share. Both can be done depending on your skill level.

I wrote this tutorial on how to launch windows 7 setup from PXE booting, if someone had a little (very little) scripting skills they could tweak these instructions to map to a network share where the bios update files were located: https://forums.fogproject.org/topic/7765/pxe-booting-into-ms-windows-7-setup

@Don-Winters Great you have it worked out.

Happy cloning.

@george1421 This thread and the ldap plugin is not dead. I have the code working with AD just fine, I need to perform some GUI updates to the web form to get it to work the way I want it to. But I think we are really close with the working solution.

@Sebastian-Roth I think my next step is to first update the bios on this computer from A11 to A15. The change log for these updates many uefi updates and hardware (nic and such) firmware updates. I want to make sure I’m not chasing something that has already been addressed. I have 2 issues with getting this done: 1) This computer runs Zorin (ubuntu variant) and the firmware updates are windows based. I have a WinPE flash drive at work that we use to update the computer bios at work. I need to make a copy so I can use it to update this 6230. 2) This is my wife’s computer, if I break it I will never hear the end of it. So I need to be spot on with the upgrade if you know what I mean.

@Matthieu-Jacquart Please let me understand this issue here as it relates to what we do.

We build our golden image with mdt and have all current win updates applied. This creates an entry in WSUS. The name of the system in WSUS is the default name of our golden image. We have this computer in our build up group in WSUS. Then we sysprep the image, and capture with FOG. When we deploy the image OOBE runs since the image was sysprep’d OOBE creates a new SID for the computer and wsus registers this device with the wsus server with its new name (we have the unattend.xml give the system its proper name as well as connect it to AD and not use FOG for this function). Since this is a “new” system with a new SID WSUS will add this computer to the default group in WSUS (because its a new computer). This is expected.

There are gpo settings where you can target a computer to a specific WSUS group, but we haven’t found this to work as we expected between the target computer and WSUS. The idea is great, in that the target OU would determine what WSUS the computer belongs to. We use that same GPO to assign the computer to the proper (local) WSUS server. That part works.

But Joe’s suggestion of letting a snapin enable wsus is brilliant because snapins run after all of the system maintenance stuff is done

@Don-Winters What version did you upgrade FOG from.

Where we’ve seen this in the past is someone has upgraded from a previous release like 1.20 or older and left the wrong setting in the dhcp potion 67 like pxelinux.0 or something. The FOG kernel and the init.xz must be insync or you will get a error kernel panic error. Can you post a screen shot (clear image taken with a mobile) of the exact error. Sometimes the text around the kernel panic speaks volumes.

And just to be clear other hardware (other than this 5040) register correctly?

You also might want to look in the bios to see if this device is in legacy (bios) mode or uefi. It could be either.

said in Deploy to onboard SSD:

N1-Samsung SSD 950 PRO 256G

To join the chorus here, upgrade to 1.3.0-RCx series. That disk is a NVMe disk that is supported by the latest version of FOG. You will want to use 1.3.0 if you need to capture / deploy to newer hardware, GPT format, NVMe disks, or need native Win10 support. If you have virtualization at your company, I would suggest spinning up a new VM with Centos 7 and then install FOG 1.3.0 on it. There are enough changes between the OS and FOG to make upgrading sometimes break.

Mod note: Moving to Hardware issues.

In addition to Quazz’s questions:

1. Can you tell me precisely what you have for dhcp options 66 and 67 on your dhcp server?
2. What device (mfg and model) is your dhcp server

The first option would be if your switches can support sending dhcp options 66 {next-server} and dhcp option 67 {boot-file} then I would use them. It is the cleanest solution.

If you can’t modify your dhcp server AND your clients AND fog server are on the same subnet then you can use a proxyDHCP server like dnsmasq. I created a write up for dnsmasq for Centos, but the configuration file should work for Ubuntu too: https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7

If your fog server and target computes are in different subnets and you have a single dhcp server, you need to configure your router’s dhcp-relay or dhcp-helper service and add the dnsmasq server on as the last dhcp server in the chain.