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

Tom Elliott

Is there a reason you’re building your own ipxe files? I ask this because it appears you missed a few of the configuration options that need to be enabled.

FlowLive

@Wayne-Workman Only MDT and a few tools, like memtest… I know there is also some litetouch scripts running as well as part of the MDT deployment if this has anything to do with it…

FlowLive

@Tom-Elliott I am not building any ipxe files. I only copied them from either the Fog server or the iso from ipxe.org.

What surprises me is the one from the iso is “working” as it is able to get to the server and the one included in Fog is not…

How should I fix this? Am I misunderstanding that the file ipxe.krn should be on my PXE server in order to be called in my PXElinux.cfg default file?

BTW I am using 5399 and will get 5411 just now.

Wayne Workman

@FlowLive Memtest is built into fog, so you don’t need to continue supporting memtest the way you are now. Most people will setup fog as the next-server and then use Vendor Classes to hand out specific boot binaries for specific architecture types. If other things in your environment rely on PXE, you could chain to those using FOG, they can be an item on your boot menu or automatic. The default automatic selection in FOG is to boot to the HDD unless there is a task waiting, then the task is executed.

Another thing to keep in mind is that in many cases, fog is a replacement for other network boot utilities - because they can either be integrated into your fog server, or the fog server already performs the task… like Disk Wiping for example, or diagnostics, or offline network-booted antivirus, I’ve already mentioned MemTest.

FlowLive

@Wayne-Workman Yes I realize this, the problem I have is I do not have access to the DHCP server and though I could request it I am trying to avoid doing this as it could result in some downtime for people reimaging using MDT. I have read that some are having issues chainloading back in MDT and I wouldnt want that to happen. Besides the dnsmasq thing disrupted our PXE server without any notice, I can’t really play around like this, hopefuly no one noticed

Seeing how this seems complicated I am getting to a point where I might just make that switch for the DHCP using undionly but before going there I would like to have either help to get this chainloading properly or have some succes stories from people using MDT chainloaded from Fog.

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?

george1421

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.

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.

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)

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?

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

145

11.7k

17.2k

154.7k