Debian 8, Fog trunk, PXELinux on MS Server and MS DHCP help

[Wayne Workman]

@george1421 said:

If I can figure out how to chain load MDT from FOG I have the kit in place to test this concept.

Others have tried before, I think @need2 …

Here is one approach but it begins with a WDS server and then would end with FOG: http://www.vcritical.com/2011/06/peaceful-coexistence-wds-and-linux-pxe-servers/

Other relevant threads:
https://forums.fogproject.org/topic/1955/pxe-boot-chainloading-to-wds
https://forums.fogproject.org/topic/4830/wds-and-fog/7?page=2

Looks like there’s just not a lot of work in this area. Probably mostly because FOG is a replacement for WDS. I don’t see how MDT would be different.

I think… If I was going to seriously tackle this problem - I would run ISC-DHCP on a Linux server, I would have FOG communicate with the WDS/MDT server somehow to detect if a task is present there - and if there is - to simply change the ISC-DHCP config to give out the next-server and filename for WDS/MDT instead of FOG. This would involve daemon writing in Linux to do the job.

[george1421]

@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)

[Wayne Workman]

@george1421 said:

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

http://ipxe.org/howto/winpe

[george1421]

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.

[george1421]

@Wayne-Workman said:

http://ipxe.org/howto/winpe

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.

[Wayne Workman]

@george1421 To my understanding, fog’s boot menu is just an iPXE boot menu given a web interface. There are some variables already available in FOG’s environment, if you look at other tasks in the menu you can see them being used. I’m pretty green myself to adding things using fog’s menu. @Tom-Elliott is probably the man you want to speak with about it.

[george1421]

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]

@george1421 said:

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 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

[Wayne Workman]

@Tom-Elliott has informed me that the web directory is now preserved - although manipulated and moved around to ensure correctness - for the reasons I listed below.

[george1421]

@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.

[Wayne Workman]

@george1421 There’s a wiki article on DBAN for fog 1.3.0

[george1421]

Bingo, I have it.

I have two ways to boot a MDT litetouch image via FOG.

1. 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.

2. 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)

[FlowLive]

Thanks everyone for the input, though it’s kind of heading in all sorts of direction and I am not quite there yet.

Anyone could elaborate on why PXELinux could not chain to iPXE?
Is it because of a broken chainload in syslinux? Simply not doable…?
It’s almost working for me with chainload but using ipxe.krn from Fog is not getting the address as opposed to ipxe.krn from the ipxe.iso, so I can’t help but think that it’s getting so close, at this point if I had ipxe.krn knowing the address of the fog server all would be needed is the imaging working and I would be set… i think…
What does Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Kernel Offset: disabled... mean when trying to image?

Other unanswered questions;

Is there some changelog we can refer to for svn changes or we have to see every single commits in Git to see what has been changed?
Also when I do a pull from Git, the installer asks to go to the management page to update the database but I never see this happening, is it needed?
Finally, after an update, is there a need to restart services or the computer?

[Sebastian Roth]

@george1421 You should be able to use ${next-server} (set by iPXE when requesting this information via DHCP). See my post here: https://forums.fogproject.org/topic/5754/storageip-parameter-in-pxe-menu/8

[Wayne Workman]

@FlowLive said:

Is there some changelog we can refer to for svn changes or we have to see every single commits in Git to see what has been changed?

Best place to look in my opinion is the SourceForge page on the project:
http://sourceforge.net/p/freeghost/code/HEAD/tree/
There is also a history area:
http://sourceforge.net/p/freeghost/code/4380/log/?path=/trunk
and a commit browser:
http://sourceforge.net/p/freeghost/code/commit_browser

Also when I do a pull from Git, the installer asks to go to the management page to update the database but I never see this happening, is it needed?

Sometimes. On newer trunk revisions you can use the -y argument for the installer to automatically update the DB for you like this: ./installfog.sh -y

Finally, after an update, is there a need to restart services or the computer?

Normally, no. The installer does this for you.

[FlowLive]

Thanks Wayne!

So I am back at testing, so I put ipxe.krn from the Fog server in my PXELinux and it asks for the ipaddress.
Then I get to the Fog menu and see my pc is already registered, choose Quick Image and I get a message ;

http://x.x.x.x/fog/service/ipxe/boot.php... ok
No Images on server found

Then it brings me back to the Fog menu and if I choose boot to hard drive I get a whole bunch of text output mainly saying about MEMDISK: bootstrap too large to load…

[george1421]

@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)

[FlowLive]

Yes I have seen the vcritical.com article but this is for launching pxelinux and not ipxe(fog) or am i just really confused?
I don’t quite understand why some of you see what I am trying to do as being building my own kernel… I use what’s provided without compiling anything.

I have just asked to have permissions given to me to play in the DHCP sevrer and will certainly try this, but it sorta sucks being so close!

FYI syslinux 6.03 supports tftp, http and ftp!

When I use kernel ipxe.krn dhcp && chain http://<fog_ip_address>/fog/service/ipxe/boot.php?mac=${net0/mac} from my PXELinux (syslinux 6.03) i get to the Fog server but I have to input the ip address of it to get there and imaging does not work with “No Images found on server” message. If i use ipxe.krn from the ipxe.iso on ipxe.org It chains properly to the Fog server but the layout seems more TUI without the white Fog background. This makes me think the problem might be with the ipxe.krn file alone… The other possible problem is that I have read that being on windows I should be using escaped slahes instead in my ipxe chain call… confused, confused

You think this will be resolved by having my DHCP using undionly pointing to Fog instead?
Because I cannot remove from the equation yet that I am using Debian 8.2 with trunk release…
If I am able to get to Fog, shoudnt I be able to Image just fine and be able to boot to local drive?

[FlowLive]

@george1421 So is there no way of simple have Fog ipxe chain to WDS pxe?

I’m scratching my head as this seems possible… how did you do it?

I will be starting to play around and change the DHCP options 66 and 67 now…

Should I bother with iphelper at all?

[george1421]

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.