Sorry for the 8 month reply. It worked as you pointed out! I have switched to RHEL 9.5

Here is how it was done if someone is interested:

Download the RHEL9.5.iso to the fog server (mine is running Ubuntu)
sudo mkdir /mnt/rhel_iso
sudo mount -o loop /path/to/rhel-9.5.iso /mnt/rhel_iso

Copy the contents to var:
sudo mkdir -p /var/www/html/rhel9.5
sudo cp -r /mnt/rhel_iso/* /var/www/html/rhel9.5/
sudo chmod -R 755 /var/www/html/rhel9.5

Get the vmlinuz and initrd.img from the /var/www/html/rhel9.5 to /tftpboot/rhel9.5 (create /tftpboot/rhel9.5 folder)
sudo cp /var/www/html/rhel9.5/images/pxeboot/vmlinuz /tftpboot/rhel9.5/
sudo cp /var/www/html/rhel9.5/images/pxeboot/initrd.img /tftpboot/rhel9.5/

Before you move on, go to http://your-fog-server-ip/rhel9.5 make sure you can see the directories of the iso content you dropped in /var/www/html/rhel9.5

Set up the Menu on the Fog UI (Here is mine)

kernel tftp://10.10.10.6/rhel9.5/vmlinuz
initrd tftp://10.10.10.6/rhel9.5/initrd.img
imgargs vmlinuz initrd=initrd.img ip=dhcp inst.repo=http://10.10.10.6/rhel9.5/ splash quiet
boot || goto MENU

@Tom-Elliott said in Capture UEFI image on hyper-v VM:

6.1.89

Thanks, this worked for me.

When tasking a host, I’d get the same as @Baessens (Hyper-V).

I went to kernel update and installed 6.1.89 as per Tom’s suggestion and I was able to get past and into image deployment!

@fogcloud Hello,

Thanks for the info. I tested the cloning after modifying the nfs.conf file. It doesn’t work. I haven’t found any specific resource on this subject.

Is this the modification that was made?

/etc/nfs.conf

[nfsd] port=20048

Sincerely, Axel.

@cjiwonder Well this is the strangest pcap that I’ve seen in a while. I finally found a uefi computer pxe booting at 8.3 seconds (you have a very active dhcp network). And the request is from 192.168.200.1.

Your dhcp server is telling the client to get ipxe.efi from 192.168.200.3. Is that your fog server? The dhcp transaction looks normal and from the dhcp side should work.

It looks like you used wireshark on the same subnet as your dhcp server? I would have expected to see broadcast messages from the pxe booting computers instead of unicast messages between the routers and dhcp server. That’s OK because we now know that the dhcp server is sending out the right boot file information (assuming that 200.3 is your fog server). If you would have used the tcpdump command from the fog server we could/should have see the target computer requesting the file to download. That would tell us if the file was actually being sent to the pxe booting computer. But from the dhcp side it looks good.

@george1421 post can be marked as solved.

Do I do that or is this done by a Moderator?

Thanks for clarifying on iPXE and FOS Linux.

@george1421 said in iPXE "Boot from hard disk" not working with RAID.:

Why refind is working is it is configured to find “windows” and boot it out of the box.

I tried configuring refind to boot grub and it partially works.
Grub shows and I can boot windows from it, but when booting Ubuntu Server I get error: failed to install protocols even though I manually installed grub with --disable-shim-lock and disabled secure boot.
Looks like it’s not secure boot related, but more like driver issue and I probably should try that iPXE chain load thing.

@george1421 said in iPXE "Boot from hard disk" not working with RAID.:

What you need is for iPXE to chain load grub.efi from the first partition so that the grub menu starts up correctly so you can dual boot.
I guess that I need to modify default.ipxe?
Could you direct me?

@Tom-Elliott
I could send you any log-info you guide me.
Too bad no one could help this problem.
I had so time consuming setting up this great project.
Do you might now anyone else i could send a message maybe?A remote session somehow?
Thanks for the effort anyway.

I had a problem when capturing an image when the computer was in legacy mode, when it was in UEFI mode everything worked. Then I reinstalled FOG on PROXMOX and I didn’t check Legacy mode anymore, but now I just tested imaging in legacy mode and everything works. That’s why I thought it was somehow dependent on whether fog was installed in UEFI/Legacy mode. Topic to close then.

@Tom-Elliott Thanks for the clarification, but please let me know if I can at least somehow avoid resizing the current partitions (especially boot partition), such as by checking Multiple Partition Image - Single Disk (Not Resizable) - (2)?

Hello,
I have a prod server and a test server
To differentiate them, I would lid like to change the default “blue theme” to a green theme.
Which lines should I modifi in de fog.css files ?

Hello, it looks something is wrong with you backend.
Are you able to open from the browser:

http://192.168.1.22/fog/service/ipxe/boot.php http://192.168.1.22/fog/service/ipxe/bzImage

?

@george1421 seems like in this post it is a similar interest they were implying by putting FOS on a bootable partition of the hard drive

https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/4

fishing for ideas on where best place to start on a project like this. I think it be very valuable functionality if able to achieve it.

@JJ-Fullmer

I saw this a while ago! Pretty impressive. Right now, we’re working to integrate the FOG API into Oracle NetSuite, but I do use Powershell quite a lot as well and could definitely see a benefit here. I will check it out.

Thanks,

@kentasmith Try changing your DHCP option 67 to another one of the boot files available (link below). We had this error and this resolved it. Think changing it to ipxe.kpxe instead of undionly.kpxe helped.

https://docs.fogproject.org/en/latest/installation/network-setup/dhcp-server-settings/#option-67

@COE Typically if the permissions on the /images directory get messed up you can reinstall FOG and it will fix the permissions.

If you run the chmod 777 /images that will make the directory world writable but not the existing files / folders under that directory. If you use chmod -R 777 /images it will change everything under that directory to world writable.

But before you do that, the linux user fogproject should have read write access to /images. The password for that user is found in the hidden file /opt/fog/.fogsettings That is the user account fog uses to move files around while imaging.