@FlowLive No boot option: ?? I said it was a guess.
But that should build the FOG PXE menu correctly for chaining. Since the documentation for the new fog pxe menu management is not written yet, I could only try to reverse engineer what the fields are and what they do to the pxe menu. It should work, but no promises.
I’m going to take a SWAG at it.
If you go into FOG settings and add a new PXE Menu item, and enter these settings.
Menu Item: wds.BootIt
Description: Launch WDS Boot x86
Parameters:
set wdsserver:ipv4 <ip_addr_wds_server>
set next-server ${wdsserver}
chain tftp://${wdsserver}/Boot\x86\wdsnbp.com
In the example above replace <ip_addr_wds_server> with the real IP address of your wds server. Then PXE boot your client and see if it chains correctly.
As I mentioned before, I haven’t use WDS. Can you answer what do you need to enter in options 66 and 67 to make WDS work?
Can we make fog chain to WDS probably.
Can I make FOG boot the MDT lighttouch image (which your deploying with WDS), yes.
@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)
Bingo, I have it.
I have two ways to boot a MDT litetouch image via FOG.
The first way is how I stated to take the iso image created by MDT and move that to your FOG server (on rhel variants) in /var/www/html/iso folder. The file I used was to move LiteTouchPE_x86.iso from the MDT deployment share to that …/iso folder as ltpe_x86.iso. Then to create the PXE boot menu as I outlined below. The freeze issue I had was related to how I created the VM. I created it as a linux VM not a windows VM (shame on me). Once I reset it to a windows 7 VM the system booted to the lite touch menu.
By using instructions found in Wayne’s link below. http://ipxe.org/howto/winpe I used this as the bases of option 2. I’ve created WinPE USB boot drives so I already had WAIK installed and already had a boot.wim created, so I’m not going into that part. But in the target winpe environement I took the ISO folder and moved it to the fog server in /var/www/html/ISO (which is different than the <lowercase> iso folder from option 1). I placed the wimboot file (downloaded from the link provided by Wayne) in the web root folder /var/www/html. Then copied the LiteTouchPE_x86.wim from MDT deployment share to /var/www/html/ISO as boot.wim. And finally created the FOG PXE menu with these settings.
Menu Item: winpe.BootMDT_x86
Description: Boot MDT LiteTouch x86
Parameters:
kernel http://<fog_server_ip>/wimboot
initrd http://<fog_server_ip>/ISO/boot/bcd BCD
initrd http://<fog_server_ip>/ISO/boot/boot.sdi boot.sdi
initrd -n boot.wim http://<fog_server_ip>/ISO/boot.wim boot.wim
boot
I still would like to understand how I can use the variables to the fog server IP address so I don’t have to hard code the IP address into the boot menu. That would make the instructions a bit more dynamic.
Understand what I’ve done is a first pass attempt to make FOG deploy both FOG images and to launch MDT’s litetouch image without the need of a WDS server (which would have made things a bit easier in one respect)
@Wayne-Workman said:
I would disagree with where the ISO is being kept - the installer blasts the fog web root every time it runs. I would suggest using /var/www/html/iso or creating an /iso directory and then doing a symbolic link to /var/www/html
Lets not get what I’ve done so far confused with the finished and working solution. Right now I’m in the mode, “Can I just make it work”. The next phase is; “How should it be setup for production”. I agree with you that the container should not be in the …/html/fog directory. It should probably be a symbolic link from /var/www/html/iso to /opt/fog/iso or something similar to keep the big files on the /opt partition (if setup that way) and off the / partition.
I am going through this for selfish reasons since with our old (non-FOG) pxe server we had utilities setup (like dban and bart-pe) that I need to bring those forward and launch them from the FOG server. I now have a slightly better understanding of the fog pxe boot menu so I think I can do this without a whole lot of pain.
I have had some successes and a failure with this approach but I think I’m on to something.
What I found so far (through a bit of hacking) is that I can create a new PXE menu using the FOG management GUI.
Menu Item: winpe.x86
Description: WinPE LiteTouch x86
Parameters:
initrd http://<fog_server_ip>/fog/iso/ltpe_x86.iso
chain memdisk iso raw
I created a directory /var/www/html/fog/iso
Then I copied the MDT LiteTouchPE_x86.iso to that iso folder as ltpe_x86.iso
I then created a new VM with 4GB of ram and configured it to boot via pxe.
I was able to pxe boot into the iso image but somewhere during the boot the system hung. The GUI came up and I did have a user surface before the system froze.
The other thing I found is that in the boot menu, I would have thought that the following variable ${boot-url} would have expanded but it did not, so I had to use a text literal ‘<fog_server_ip>/fog’ to get the system to boot. While this wasn’t a total success (because the image did not fully boot), it isn’t a total failure either because it started to work.
I’m going to have to table this for tonight, but I have a few other ideas I’ll try in the AM.
@Wayne-Workman said:
I didn’t want to go that route because of the number of files needed in the /tftpboot folder. I was holding that as a plan B. The iso image is just one file, plus changes to the ipxe boot menu. Do you know of a wiki that discusses the menu management? I’m having an issue finding much details on it.
In researching how to make pxe boot menu changes with the new system I found this link.
https://wiki.fogproject.org/wiki/index.php/Advanced_Boot_Menu_Configuration_options
The second frame under “Examples Basic Menu” shows exactly what needs to be done in the old menu to boot a winpe.iso image. So I’m not swimming in uncharted waters.
@Wayne-Workman Actually I think I figured out another way.
Understand I don’t have WDS setup and we build our reference images in a vm via an litetouch iso image. So the only pxe booting we do is into FOG. I’m kind of winging it here, but I know what needs to be done. I have found a reference to allow me to boot ISO images via tftp (I did this a while ago for diskless booting linux and a few other iso based utilities). If fog would use the traditional pxelinux menu I know how to get it done. Right now I’m trying understand how I can add these options to the fog pxe menu.
kernel memdisk
append iso initrd=litetouchpe_x64.iso raw
Once that is done, I think all I need to do is copy the iso image to /tftpboot directory on the fog server. Again this is a bit of guessing that it should work. The target computers will have 4GB of ram so there is enough room for the iso image to exist in memory as well as the WinPE environment (in theory)
I kind of have a similar setup as you, but not quite a chaotic.
Before I go too deep, I’m wondering if you have a separate subnet (vlan) away from your MDT environment you can use for testing? If have a subnet you could change the pxe boot settings just for that subnet to point to FOG. That way you would have a good test lab setup to ensure that everything deploys correctly before going live.
How I would go about this (be aware I have not needed to do it this way), is just as you stated to chain load MDT from FOG. Let the client pxe boot into the FOG menu and then add FOG menu item to chain load into MDT.
In our environment we use MDT to build the reference image, sysprep the image, and then capture the image with FOG for deployment. We do not deploy using MDT because of the volume of systems we manage.
If I can figure out how to chain load MDT from FOG I have the kit in place to test this concept.
We should first start out with what version of FOG are you using? Are you using the 1.2.0 release or a SVN trunk version. If it is a SVN trunk version what is the version number?
As for is this a problem, I’ll have to defer to the developers. Just off the top of my head, I would have to say yes this should be concerning.
But, only the @Developers know if it WILL BE a problem moving forward.
@KKTwenty101 Interesting, I also do a minimal install for Cento 6 and 7 and fog installs no problem. As long as you remember to disable iptables and selinux. I know that FOG installs mysql during the initial install because the password for mysql root user is blank. If you are doing something outside of the normal FOG install then something is broken either with the system or the FOG installer.
My FOG server is behind a proxy server so I have to create a few envron variables and update wgetrc and subversion with the proxy server settings, but the basic workflow is
That’s all I’ve done and it works correctly right out of the box, so to speak.
@Rusty It would be interesting to know if this computer’s bios is up to date. From Wayne’s suggestion, it would be great to know what SVN worked so then we could go back to the devs and say what’s different between then and now, why did this stop working? I’m still leaning towards the hardware on this issue though.
@Rusty said:
Updating to SVN 4367 didn’t help with this Dell Inspiron I have here. The second laptop I have here boots into FOG menu everytime.
Not to fork this thread, but just so I can get this clear in my head.
You have two computers that are exactly alike. They are the same models, with the same bios release and the same bios settings. But one boots to the fog menu and the other hangs at the init devices?
Have you tried to reset the bios back to defaults on the one that doesn’t work, save and reboot, then make any changes necessary for your image (uefi, legacy, roms, etc.) save then pxe boot. If it still hangs. Power it off, remove the battery and charging cable. Then power everything back up. If it still hangs then I might consider the mobo has issues. There may be a way (kernel parameter) that the developers can set to tell exactly where its hanging.
@Rusty Some systems will try to do a two way match between conical name->IP address -> conical name. This is a standard function of DNS. I’m kind of surprised that this issue (not having a reverse lookup zone) hasn’t been a problem.
Not to send you down a rabbit hole here, but I take it you don’t have a reverse lookup zone created for your DNS server. Because looking at the capture its looking for the 10.0.0.51 address but the reply from DNS is name not found. Can I guess that 10.0.0.51 is your FOG server? Outside of the scope of this project you should ensure you have a reverse lookup zone created in DNS.
Here is a how to for 2012. http://www.tomshardware.com/faq/id-1954333/create-reverse-primary-dns-zone-windows-server-2012.html
yes after you do the svn up then cd to the bin folder and run setup again.
A PRT record is a reverse lookup for DNS. Basically it asks DNS for this IP address what is its conical host name.
While I haven’t read this entire thread, for DHCP its best for option 66 to be an IP address and not a conical host name. Some PXE clients are just not that smart enough to know how to look up a name for option 66, so set it to the IP address of the FOG server.
Also I know they have been working on the boot image (in the last 3-4 days) where it was getting stuck at the initialing devices. You may want to try to update to the latest SVN. It sounds like you are almost there.
OK just to restate what I think you said, all of your fog servers are running under ubuntu 14.04 and the version of FOG is 1.2.0 base image. You have not applied any SVN trunk (a.k.a 1.3 beta) images on top of the 1.2.0 base image.
Now here is where I’m a bit fuzzy. Are you trying to deploy to a HP microserver or is the destination of the captured image the HP microserver? What I’m trying to dig at is of you are on the 1.2.0 base image and you have not updated the kernels since the base image was released (which is separate than applying a SVN upgrade), that kernels from 1.2.0 my not support current hardware.