Best posts made by george1421

Deleting and reinstalling the location plugin resolved this issue. Its possible that I had something wrong with the location settings ( I was testing the windows storage node in this environment before ) or something was wrong with the location plugin and was reset when I reinstalled it.

Marking this solved.

On a side note. The hostinfo.php query page called from inside the FOS client returned the needed kernel parameters. So I think the concept of usb booting info FOS imaging is looking brighter.

@FlowLive First let me apologize for hijacking this thread a bit. But in the end I think I have a workable solution for your environment to allow you to run FOG along side MDT. I understand what you are trying to do by chaining FOG and MDT/WDS. Wayne has provided a way for you to mesh WDS and FOG into a pxelinux boot menu here.
http://www.vcritical.com/2011/06/peaceful-coexistence-wds-and-linux-pxe-servers/

And in my case I have worked out a way to launch a MDT install from the FOG pxe boot menu. This would allow you to launch and install MDT as you do today, but though FOG. It would provide a smooth transition path from MDT deployment to eventually a FOG deployment.

I’m going to say this with the most sincerity. The path you are on is kind of a waste of time to building your own kernel. You can do it that way if you want, but there are now documented ways to get it done without having to mess with syslinux. One of the issues with PXELinux (at least the last time I looked at it) was it only supports tftp booting and all the restrictions round that. Where iPXE can use other boot methods like http. Now if you use ipxe for your boot loader then chaining would work better. Then you could chain to fog using something like a call to

kernel ipxe.krn dhcp && chain http://<fog_ip_address>/fog/service/ipxe/boot.php?mac=${net0/mac}

(stolen from the fog pxe default configuration)

@Joe-Gill Here is a good reference https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

But you would actually disable the fog service in audit mode and then turn it on in the setupcomplete.cmd file with the following statements. Just add these to the setup complete file to start the fog service.

sc config FOGService start= auto
net start FOGService

So in the audit mode side you install the fog client msi right? So just after that is done, go to the control panel/services and just select the fog client, stop it and then disable the service.

If you had this ability, how would you decide what image to apply to the target computer?

Borrowed from Sebastian’s signature: Please take a look at your apache error log file (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log)

Take a look at this file on the FOG Server, see if there are any exceptions thrown at the time you deleted the host. This will guide the devs to resolve your issue.

@FlowLive

Looking and the chain load link that you sent. I did see this reference

  set netX/next-server ip.of.wds.server
  imgexec tftp://${netX/next-server}/boot/x86/wdsnbp.com

What I think I might have missed is in my guess is setting the network adapter 0:

set wdsserver:ipv4 192.168.1.88
set net0/next-server ${wdsserver}

Its interesting that the chain does work (kind of) that it does gram the wdsnnp.com file, but there is something in the referral that its missing to continue.

To answer your question that article was written specifically for windows 7. So yes you need to use winpe10 drivers for windows 10 (its on the same dell driver page). Everything still works as documented , with the exception of the registry change. For windows 10 you have to add a section to your unattend.xml file to tell windows 10 OOBE to look for the drivers in a location you choose.

@robin said in Multiple images for one host:

@george1421
Task 1 --> Deploy image 1 to host 1
Task 2 --> Deploy image 2 to host 1

OK this is a start. My question is how do we know / when to execute task 1 or task 2 or deploy image 1 vs image 2? What determines when a task should be executed. I want to understand the process to see if FOG has the resources to go about doing what you need. Its not clear what you need just yet in my mind.

@Wayne-Workman TBH I did not read the entire thread so if this has already been asked my apologies,

What is the results of showmount -e 127.0.0.1?

======
OP: If I understand this correctly you only have one FOG server but you have 2 hard drives in this physical server with each not having enough space for all of your images, do I understand this right? If so I think I would take a little different and less complex approach. There is two routes I can think of

1. Setup LVM and just add those disks to an LVM volume group and then create a LVM logical volume. Let LVM decide where to span the files on those two physical disks. Temp mount that LVM volume over /mnt and then move the content of /images to that LVM volume. Unmount /mnt and remount that new LVM volume over /images and be done with it. (make sure you update fstab). That way you are running a standard FOG configuration without having to deviate from the norm.
2. On your existing FOG server create 2 directories under /images like olifant and koei. Mount those two drives over those directories. Then when you create your image definitions make sure you pick one of the two drives. So if you create an image name called WIN7X64 make sure the destination path isn’t /images/WIN7X64 but /images/koei/WIN7X64 instead. Its not as clean as doing it at the OS level as with LVM but it should work.

@FlowLive said:

Now I read that it’s not possible to change the menu order of things, WDS being all the way down, can’t I just bump it up a little?

Where it should be, way at the bottom. Where do you think the competition would put it, front and center??

I’m glad/happy you got that wds thing fixed out. From what I’ve read those forward / backslashes are a PITA to get worked out. It looks like you got the right combination to get it done.

@Joe-Gill That’s very strange since they do work via command line and those exact commands are in my setupcomplete.cmd file. Just as a question, is your av getting installed? Try moving the sc command towards the top of your script.

Question? When your setupcomplete.cmd script executes does your computer reboot or does it go directly to the login screen? The setupcomplete.cmd script is exectued as system user after oobe is done and just before the login window is displayed. One thought is that your av install is rebooting your computer before the batch file gets to the sc command and the net start command.

I know this process works because that is how we use it today in our environment.

@Bob-Henderson said in Multicast Question:

The key is having a switch that can forward data to all 46 ports. That netgear should be OK, if you were using one of those cheapish 5 ports switches I’d have some concerns about its forwarding rate.

Can you confirm if the fog (linux user) account password is still consistent with what is defined in the FOG management GUI? (I’m guessing here) The error may be misleading in that its not really a database error, but the step before where the FOS engine logs into the FOG server via ftp and moves the image from the /images/dev to /images directory.

ref: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

@need2 said:

I’m late to the party, but no I never got WDS and FOG to play well together.

@FlowLive was just able to do this. Its a bit down in the thread, but he has FOG acting as the PXE boot server then you can select the WDS environment from the FOG Menu.

I went the other way around and setup FOG to be able to boot the MDT litetouch image so that you can deploy through MDT from the FOG boot menu. Two different ways to have FOG and MDT/WDS coexist.

Well that section of the unattend.xml file is a bit unexciting isn’t it?

I did a little research on this and the error message above may be misleading. There is the potential that this is a driver issue and not related to this section of the oobe process. Which would kind of tie into why it happens on this one model and not the others.

"This resolution is based on the source of the error, to troubleshoot this issue, review the Microsoft Setup log setupact.log file.

Note: The Microsoft Setup log file is located at c:\Windows\Panther\unattendGC\setupact.log.

To view the log file from a computer currently displaying the error, press Shift + F10 to open a command prompt and run this command: notepad c:\windows\panther\unattendGC\setupact.log "

ref: http://blog.vmpros.nl/2015/05/13/vmware-windows-could-not-parse-or-process-the-unattend-answer-file-for-pass-specialize/

I also found references to this file being in these locations:

1. %Windir%\Panther\Setupact.log
2. %Windir%\Panther\UnattendGC\Setupact.log

Please review these logs to see where the system is actually failing.

@cnbgeren I’m just trying to understand your logic for not wanting Internet access with your fog server.

In your case where you have a home router that is handing out dhcp addresses, but you want to run FOG on the same network and your home router as your dhcp server you can use a linux service called dnsmasq. This is a proxy dhcp server that will supply the missing information to a standard dhcp request.

@Wayne-Workman just created an updated document (that I can’t seem to find for setting up dnsmasq) Here is my older one that might get you started. https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7

@pmonstad I know I’m being a type “A” person this AM, but can you confirm that you can log in from a windows pc to the fog server using FTP and the fog (linux user) account?

A18 will work as long as you turn off the legacy ROMS. I did see that post too, btw. I just had to try it and it worked with the same results as you. So no better or worse then.

@Wayne-Workman While I agree with your conclusion, is there any chance we can get a tarball of the install files so git and/or svn isn’t needed? I understand with a moving target such as the trunk builds it would be very hard to maintain yet another repository item. But this could be one solution. But again the right answer is if this system is going to be setup from scratch why not use an OS that will be supported for the useful life of the system you are building.

@xfirero That way won’t work (as you noticed). Windows will look for a cdrom (hardware) if you do it that way.

Review this tutorial
https://forums.fogproject.org/topic/7765/pxe-booting-into-ms-windows-7-setup