@sebastian-roth Sure I’ll rebuild the 5.9.3 (quickest path because of the kernel patches) in about 5hrs. I’m out of the office until after lunch time Easter USA time. My build server is powered off at the moment or I could build it remotely.

I was thinking the same thing last night about the network group not being in the kernel since the network cards were added in 4.20 and our build settings for 5.x are based on 4.19.

I don’t think using the 5.10rc builds are the right thing to do at the moment.

@zc0rp I didn’t ask the question correctly to get the answer I need.

If you take the programs from setup.exe to readme.txt and throw them on a usb flash drive and take that to a different computer. Can you launch the program on a second computer and have it work?

Second question do you an options of using the linux version of this software?

The issue is this cd is using this symobi operating system. I’m going to think it is some kind of linux/msdos like variant. This kernel.map is the kernel and addon.map is the initrd (virtual disk image).

@zc0rp So tell me how you use this software? Is it like ghost in that its just a windows / dos based program that will run as long as you have a boot media? It does look like a microsoft os based application?

The thought is if it is just a ms os application we could move the files to a winpe environment and boot it in there. We can deploy a winpe image with FOG.

Can you take all of the top section files to the readme.txt and move to a usb flash drive and then run the software from there?

I see this symboi directory. This IS your OS. It looks like hdclone supports two different os’ this symboi OS and a linux OS.

@george1421 Well you did give me everything I needed the intel vendor ID is 8086 with a device ID of 15F3.

That driver was first introduced in linux kernel 4.20 and 5.0. So that network adapter will not be found with any of the 4.19.x and older linux kernels. So for FOG any of the 5.x versions of the FOS Linux kernel should work for that device, if the device number is truly 15F3.

I just looked and I do have a 5.9.3RT one off kernel. That should work for that network adapter.

@will Can you give me both parts both the vendor ID and device ID? I can look to see what kernel has the driver. The kernel numbering looks like one of my one off kernels but I didn’t think I release a 5.9.3 version with the realtek drivers. Either way I need either the windows hardware ID or setup a debug deploy/capture to this target hardware then pxe boot. After several enter key presses you will be dropped to a fos linux command prompt. At the fos linux command prompt key in lspci -nn | grep -i net The numbers I need are in the square brackets.

@pjb1983 Well I have success, but still confused why the instructions were wrong. For background the tftp service can be managed by xinetd (normal) but it can also be launch by systemctl directly. It appears with ubuntu 20.04 both methods are setup but only the service route is configured to run.

So exit /etc/default/tftpd-hpa

Make the tftp options look like this:

TFTP_OPTIONS="-s --blocksize 1368"

Once that is done restart the tftp service
sudo systemctl restart tftpd-hpa

Looking at the pcap I see it working as intended (may not be fixing your problem but the block site being adjusted according to the settings).

I can see the client asking for a 1468 block size. The tftp server saying ok but the block site is 1368. Then it sends only 1368 bytes at a time.

So why 1368. That is the mtu 1400 - 32 bytes for the ethernet header == 1368.

@sebastian-roth said in Is it possible to connect to the Fog server remotely?:

octet blksize 1456

This is a TFTP thing. Nothing to do with MTU really.

I may be off on this, but the tftp client asks the FOG server for the file and what the block size is. Since the block size is larger than the MTU the block will need to be fragmented between two packets. The fragmented udp packets are what the remote client is choking on. At least this is what I’m thinking.

In the pcaps that have been done so far, we see the target computer getting the right pxe boot file name and it asking the fog server for that file and the fog server sending that file but we are seeing a tftp timeout (file never arrived)

I’m not sure where the OP got this pcap from but the numbers align

13:03:04.667062 IP 192.168.5.121.2071 > 95.0.0.85.69: 35 RRQ “undionly.kpxe” octet blksize 1456
13:03:04.692814 IP 95.0.0.85.52966 > 192.168.5.121.2071: UDP, length 15
13:03:04.693826 IP 192.168.5.121.2071 > 95.0.0.85.52966: UDP, length 4
13:03:04.718623 IP 95.0.0.85.52966 > 192.168.5.121.2071: UDP, bad length 1460 > 1400
13:03:04.718623 IP 95.0.0.85 > 192.168.5.121: ip-proto-17
13:03:05.719924 IP 95.0.0.85.52966 > 192.168.5.121.2071: UDP, bad length 1460 > 1400

We know the tftp bock size is sending 1456 and we are getting a bad length 1460 > 1400. The numbers seem to align. Then again, I’ve been wrong too many times to count before, so…

@pjb1983 said in Is it possible to connect to the Fog server remotely?:

octet blksize 1456

This is the problem. We need a value less than 1400. I have a ubuntu 20.04 fog server in my home lab. I’ll work with it tonight to see if I can get that block size below 1400. I know we’ve seen this issue before, because the first thing that came to my mind was network MTU.

@pjb1983 I could have almost predicted that. Changing the VPN MTU is not really an option.

So you updated the max size from the tftp server. Lets see what the tftp server is telling the target computer.

Lets use this tutorial but for the port capture just use port 69

https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

With the reduced max block size the tftp server should report the size you set in the configuration. You can review the pcap with wireshark.

@john-l-clark Did you happen to change the linux user fogproject’s password at any time. Either in linux or in the web ui? This account and its password is managed by the FOG Installer.

You can follow this script to resync this passwords.
https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

@pjb1983 So following the link I provided did you try to reduce the maximum packet size to something below 1400 (the mtu)? Something like 1385 would be a start.

@dangbird said in UEFI Boot Install of XenServer Close but no Cigar:

Let me know any specifics of how I can contribute in return.
I will work on a “Load XenServer from Scratch using FOG” write up at a minimum.

This is perfect payment in kind. Thank you

@dangbird When I created the grub.cfg file I used putty to connect to the FOG server and used vi and pasted the text directly in from copying it from the web page. I didn’t change anything. Just watch your case on the file path, because case is important.

As for grub you may not have luck switching to http if grub wasn’t compiled with http support. tftp may be your only option. Just saying.

Now also be aware, while I was playing I also placed a grub.cfg in a directory called /grub because I was testing a number of paths. Being thrown into the grub shell means that it can’t find the grub.cfg file. But if you are getting a syntax error that means it must be finding the grub.cfg script.

Lastly all of my testing was done on an ESXi VM. I did not try on real hardware.

@tech04 When we have issues with refind we recommend to roll back to 0.11.0. I’m not sure its going to fix your issue but its worth a shot. Also make sure your firmware is up to date on the target computer.

What is happening is refind is stalling out trying to boot on that hardware. This is an issue specifically between refind and the hardware.

@george1421 and for the bonus round bringing the two configurations together to give you one menu for both bios and uefi booting.

Note: I did not test this only glued the code together. YMMV

iseq ${platform} efi goto os.xen.uefi

kernel tftp://${fog-ip}/EFI/xenserver/xen.gz dom0_max_vcpus=1-16 dom0_mem=max:8192M com1=115200,8n1 console=com1,vga
module tftp://${fog-ip}/EFI/xenserver/vmlinuz xencons=hvc console=hvc0 console=tty0
module tftp://${fog-ip}/EFI/xenserver/install.img
boot || goto MENU

:os.xen.uefi
chain tftp://${fog-ip}/EFI/xenserver/grubx64.efi || goto MENU

@dangbird Ok got it to boot in uefi mode.

I didn’t play around any and test different options once I decided to ‘follow’ the instructions.

This is just phase 1 but I can get it to boot. Phase 2 is making it a single menu to boot both bios and uefi. But lets make sure we can get uefi running on your campus.

This is what I have for my FOG iPXE menu parameter

chain tftp://${fog-ip}/EFI/xenserver/grubx64.efi

Now the path MUST BE EXACT as I defined in the /tftpboot directory. You can play with getting http working on your own dime.

So in the tftpboot directory create the /EFI/xenserver and move these files into there.

grub.cfg grubx64.efi install.img vmlinuz xen.gz

You will have to create grub.cfg from the web site you lined. I just pasted this into that file

menuentry "XenServer Install (serial)" {
 multiboot2 /EFI/xenserver/xen.gz dom0_mem=1024M,max:1024M watchdog dom0_max_vcpus=4 com1=115200,8n1 console=com1,vga
 module2 /EFI/xenserver/vmlinuz console=hvc0
 module2 /EFI/xenserver/install.img
} 

pxe booted into the FOG iPXE menu and selected Xen installer menu.

When it loads the VM went dark for about 8 seconds then started booting vmlinuz. It was a long enough pause that I went “crap it didn’t work again”, but then the linux kernel started up.

@dangbird said in UEFI Boot Install of XenServer Close but no Cigar:

I set my DHCP to provide grubx64.efi and can get a Grub menu from FOG but think I am barking up the wrong tree.

Actually this is the tree I’m climbing at the moment.

No problem on the burn of files. I don’t need them post working/giving up.

@dangbird I’m thinking that we need grub to do the magic here. I have a few ideas, let me work with it for a bit. I need to go and grab a few more files from the file share.

@tech04 said in HP EliteBook 840 G7 stuck at "rEFInd - Initializing...":

Are you saying to configure Option 67 with snponly.efi

yes

@dangbird Ok I can pxe boot it using my menu in bios mode, but in uefi mode it fails. I did this on a ESXi VM. The only thing that changed between fail and working is UEFI -> BIOS change.

If under linux I run file xen I get this

file xen
xen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=562b9323885fffea752a2e4f1308833a8fbcf8e0, stripped

for vmlinuz I get

vmlinuz: Linux kernel x86 boot executable bzImage, version 4.19.0+1 (mockbuild@a50e0282e69b) #1 SMP Fri Apr 12 12:44:47 UT, RO-rootFS, swap_dev 0x6, Normal VGA

Notable that these are both 32 bit kernels and I’m suspecting not UEFI compatible. iPXE rejects both xen and vmlinuz in uefi mode. Basically saying it doesn’t know the file format.

Do you have an installer image that is UEFI format?