Posts made by DBCountMan

I copied all the files with the folder structure to the partition I created. Set the part type to EFI System, filesystem to FAT32, told the BIOS/UEFI to boot from bootx64.efi in /BOOT/EFI and landed at a grub rescue prompt. After playing out the process in my head I realize that full automation won’t work because the way the menu is set up to autoboot into Windows after 5 seconds will prevent a deploy or capture task from ever starting. I’d have to be at the PC to select the Deploy/Capture option on the FOG Menu. The USB option still works though so all is not lost.

Got it working! This worked for me after making sure the drive was changed to GPT and I also labeled the efi parition as “EFI”:
menuentry “Windows” {
insmod chain
insmod ntfs
insmod part_gpt
set root=(hd1,gpt2)
chainloader (hd1,gpt2)/efi/microsoft/boot/bootmgfw.efi
}

Just realized that the set root part is redundant. I am partitoning the drive now to copy the files from the FOG USB key then tell the UEFI on the PC to boot from this new GRUB partition first. Looking good!

that didnt work for me. said ntldr and drivemap not a command.

I found the Windows partition it is actually (hd1,msdos1). I ran "ls (hd1,msdos1) and it showed filesystem ntfs label “Windows” and the UUID. But when I try to run the command “chainloader (hd1,msdos1)/EFI/Microsoft/Boot/bootmgfw.efi” or “chainloader (hd1,msdos1)/EFI/Microsoft/Boot/bootx64.efi”, says file not found.

Correction: This drive was MBR with only one partition. Sorry about that.

It probably is the USB drive. I don’t think this particular environment is seeing the hard drive in the PC. I know for a fact that the Windows drive is GPT and EFI because I converted it to GPT before I imaged it, also made sure the image itself was created as GPT. I am able to boot from the Windows EFI partition normally.

@Sebastian-Roth The windows partition I’m trying to boot from is a GPT-EFI bootable system. Is that “+1” always supposed to follow the chainloader entry?

Great thanks! I already found and tried this:
insmod part_gpt
insmod chain
set root=(hd0,gpt1)
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
boot

No luck. Says the file could not be found.

The ls command shows hd0 hd0,msdos hd1 hd1,msdos, hd2 hd2, msdos. I tried all three hd entries and pointed to /EFI/Microsoft/Boot/bootmgfw.efi no go, but much further than I was thanks to you and @george1421.

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.

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?

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

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.

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.

@george1421

1. yes one for management, the other for imaging.
2. eno1 is for management, on my production network. eno2 is for imaging, isolated with DHCP and TFTP.
3. Yes refer to point #2/.
4. 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.

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?

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?

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

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 have an image that was created as follows. Convert disk to GPT, Pxe boot (efi) into sccm server, pull stock windows 10 image. Clean it up. Then captured it via pxe booting (efi again) into fog. This happens when trying to deploy it.