Boot FOG on client PC using a special partition?
-
Is it possible to have a bootable partition that the FOG Client can use to Deploy an image? I read about booting FOG from USB, but it would be really cool to be able to deploy or capture an image from a managed FOG client workstation. Is this at all possible?
-
I’m not sure of the logic, but technically if the “managed fog client” computer was uefi based you could take a hard drive and created a 512MB fat32 partition and then transfer the contents of the usb drive to that partition. Just mark that partition bootable and it should work.
-
@brakcounty While I find this an interesting approach it’s not something FOG can do out of the box as of now. We might consider adding this as a feature but this needs a lot of consideration and testing and I don’t see it happen any time soon. Symantec Ghost used that concept a lot and while it did work in many cases it also caused us a lot of grief and problems when we used it back in the old days. As soon as the boot partition is lost (for whatever reason) you are doomed to manually take care of this. Sure you could make it easy and create a PXE task to just install that boot partition for you on request.
Anyhow you are free to customize FOG and work on adding this. You are more than welcome to ask here and we’ll try to help you make it work.
As a first base I would talk about your PCs being UEFI only, legacy BIOS or mixed environment? There is a huge difference between booting legacy BIOS vs. UEFI and so you need to consider that first. In an ideal world I would suggest you switch to using UEFI only on all your PCs first and then go ahead and tackle this project. But that’s up to you.
Let’s take it from there, see if you are keen to discuss and work on this and we’ll see how fast we can get there. Usually pretty quick of you are on to it.
-
@Sebastian-Roth We have mostly UEFI capable systems, with a small percentage that still use BIOS. Another note, we are a large team and there really isn’t a standard for low-level preparations for image creation. Some people create images without an EFI partition, others do. Ever since I built the FOG server for my team I’ve sort of been in charge of the server. If I find a concrete solution then we can make it a standard. We would use SCCM but our network team doesn’t quite understand pxe booting so they don’t want to dive into it. It would involve configuring many many dhcp servers to hand out pxe boot files upon that packet request. So instead we either image here at HQ or in some cases we throw a WIM onto a usb drive and image that way, or in my case, I boot acronis via usb then connect to my NAS where my images are. I got UEFI pxe boot to work from my FreeNAS box a while ago, its a pain since I have to recompile the ixpe file each time I need to make a change. But I realize that FOG uses UEFI and has a customizable menu without having to recompile the boot image (correct me if I’m wrong). I am actually totally willing to be the guinea pig on this project. What would I need to do first? Like @george1421 suggested, maybe creating a small bootable partition? And from there, a menu would appear with a fog login screen, and a timeout counter, so that it can eventually boot into Windows if no imaging is required. This is all theory obviously. Or if a task to deploy an image is created, then the login screen or menu would not show but instead the task would commence immediately after a reboot.
-
@brakcounty said in Boot FOG on client PC using a special partition?:
Only adding color commentary to your post…
But I realize that FOG uses UEFI and has a customizable menu without having to recompile the boot image (correct me if I’m wrong)
The magic happens because the ipxe client chains to an external ipxe script.
ref: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src/ipxescript#L29
I boot acronis via usb then connect to my NAS where my images are.
If you want to do this use clonezilla.
Or if a task to deploy an image is created, then the login screen or menu
FWIW you can deploy an image directly from the iPXE FOG menu. You don’t need to create the task on the fog ui or need to touch the fog web ui.
SCCM is a beast and slow (slow because its a file level cloning system not a block based cloning system like FOG. I’ve used both). It takes about 1.5 hours to go from bare metal to ready for the user. With FOG its just under 15 minutes from bare metal to ready for user. The differences is with FOG your efforts are spent up front making the perfect golden image, with SCCM basically your golden image is built every time. PXE booting with SCCM is no harder than pxe booting with FOG. If your clients are on a different subnet than your SCCM server you need to make a small change to your subnet router to make it work well.
-
I followed these instructions at https://wiki.fogproject.org/wiki/index.php?title=USB_Bootable_Media#USB_Boot_UEFI_client_into_FOG_menu_.28easy_way.29
to boot from usb but get this error:
The IP address that I blotted out is the standard production network vlan, not the 10.0.0.0 that is the imaging/dhcp/pxe interface. At the step shown in the screenshot, is it trying to get boot file from the FOG server? -
@brakcounty Ok now we are getting somewhere. The blotted out IP address comes from your dhcp server. So dhcp option 66 needs to be the IP address of your fog server within the scope of where the target computer can reach.
ref: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src-efi/ipxescript#L29
You will see at this line iPXE is chaining to the IP address value discovered via the bootp process.
-
Sorry forgot to mention, the blotted ip is not received from DHCP rather set statically on the server. What is this step trying to do? Is it connecting to the FOG server to pull the menu?
EDIT: I think I see what is happening here. This step is calling the FOG server’s tftp service to retrieve the files to show the menu. problem is that the tftp/dhcp service is running on a different interface that is not on our production network. Maybe I can put the files it needs inside the NFS share and edit the script so that it points to the NFS share?
-
@brakcounty said in Boot FOG on client PC using a special partition?:
blotted ip is not received from DHCP rather set statically on the server.
I don’t understand this if you are just booting the iPXE boot loader you took from the FOG server then it is surely getting this IP address from dhcp, because that’s how it works.
What is this step trying to do? Is it connecting to the FOG server to pull the menu?
The ipxe.efi and all of the iPXE boot loaders delivered by FOG work the same way. They use the dhcp option 66 to locate the fog server once iPXE is loaded. So at this step iPXE is chaining (loading) the contents of default.ipxe from the fog server. The default iPXE file, which is just a text file, tell iPXE to call the boot.php file which builds the iPXE menu.
-
@brakcounty Ok so now you need to clarify a bit.
- Your FOG server has multiple interfaces?
- When you installed FOG you told it which interface is for imaging?
- You have a dedicated imaging network?
- The pxe booting computer (in this case) is connected to your imaging network?
-
- yes one for management, the other for imaging.
- eno1 is for management, on my production network. eno2 is for imaging, isolated with DHCP and TFTP.
- Yes refer to point #2/.
- The PC that I am testing with is on my production network, and I am using a USB drive with the ipxe.efi renamed to bootx64.efi in /BOOT/EFI.
I was wrong you were right I misread the blotted IP. It is actually the IP address of our SCCM server that provides boot files. Not sure how that happened. Maybe the PC requested a PXE packet and the DHCP server relayed that request to the SCCM server. Just a note, SCCM PXE booting only works on our department’s subnet so we can image using SCCM if we want, but only on our IT dept’s network. So this won’t work. I want to be able to get to the FOG menu via USB and pull images from the FOG server. Once that works, then I can figure out how to create a bootable partition and somehow get the FOG management client to do this automatically/magically.
-
I just confirmed that the images on the NFS share /images are accessible on the management interface which is on our production network. Now we have to find a way to get the FOG menu without using pxe or ipxe.
-
@brakcounty Ok everything then is working as it should. Not what you want, but how it should.
Now why are you attempting to image a computer on your business network and not the imaging network? The fog server is configured to only provide the correct IP address to things on the imaging network. The FOG program does not support imaging on two different interfaces (I say that knowing there is a hack not supported by the developers around the problem).
-
It is for convenience and also better workflow efficiency. Right now, I am the only one using Acronis pulling images from my NAS but the supervisors wanted me to build them a FOG server, so I did. Now we’ve all been using FOG here at our imaging lab but it would be nice to be able to image onsite at a clients office, instead of either pulling the drive/PC back to the lab to image. I can image a PC in about 7min across the network at a clients office with acronis. I want the rest of our team to be able to do that. I use an Acronis iso that is somewhat old now and that I paid for. Acronis doesn’t offer deployment unless we purchase Snap Deploy. FOG is free, so we are dedicated to that solution.
-
@brakcounty said in Boot FOG on client PC using a special partition?:
FOG here at our imaging lab but it would be nice to be able to image onsite at a clients office
A mobile fog server would work here (laptop loaded with FOG and dnsmasq). But this issue is beyond the scope of trying to deploy to a system not on the imaging network. iPXE and FOG is only designed (programmed to support a single interface for imaging). There are hard coded IP addresses in the fog configuration as well as in config files that point to the IP address of the designated imaging interface.
If you wanted to discard iPXE from the imaging process (and loose some functionality) you can boot FOS Linux (the OS/Engine that captures and deploys images) directly from usb. You see the FOS Linux engine being transferred to the target computer on the imaging network as bzImage and init.xz. With that said, in this hack you have to define the IP address of the FOG server since FOS Linux would normally get that from iPXE (which is not available in this solution). So its possible to define the management interface of the FOG server in the config file for this USB boot. The instructions are listed here: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image Read through the instructions completely and watch out for the caveats.
Also look at the chat bubble for a few more hints.
-
@george1421 So I changed the IP in the grub.cfg file to my FOG server on the production side, and booted the USB, chose deploy/capture image (the first option on the boot menu), and got this error:
-
@brakcounty Ah you DID NOT read the caveats with this process. You MUST schedule the task first before picking option 1
-
Ok created a task and tried it again, and now it looks like the task is trying to mount the nfs share via the imaging (isolated network) interface 10.0.0.10
Is there a way to make FOG try to connect to two different nfs shares? Like if one fails try another? -
UPDATE!!!
I added a storage node and specified the interface and ip of my prod network and successfully deployed an image using the USB FOG. Now I added an entry to the GRUB menu called “Boot from HDD” but I don’t know the command line to boot from it. I have used “sanboot --no-describe --drive 0x08” in an ipxe menu file with a different setup but GRUB isn’t recognizing sanboot. -
@brakcounty As we usually don’t use GRUB in FOG for booting there are not that many resources on this topic in the forums. For that you need to search external sites. Here is a list of different GRUB configs used for chainloading to a Windows installation on disk: https://wiki.gentoo.org/wiki/GRUB2/Chainloading
I have not see the
ntldrused much yet. Most Linux installations that setup dual booting with windows use thechainloadercommand I think. Try different ones and you should be able to boot from disk through this.
