You should be able to use the original refind.efi from 1.6.0 as this is one of the older versions. Whether it works I don’t know, but I do know of at least one person who uses this old version (0.9.4 I believe?) with their HP machines. They also needed to use the 10 second delay files due to NICs being power save ready.
@jmeyer There is no real check. At the moment we install mariadb on fresh installs but stick to mysql on upgrades (which is set in /opt/fog/.fogsettings) because Ubuntu does not properly migrate your database from mysql to mariadb yet (while Debian has long ago).
@jmeyer Sorry for the late reply. Couldn’t get to this any earlier. Is this still an issue for you? I have had a look at the code but can’t make sense of this yet. I suppose we’d need the start of the output - the first “Attempting to check in” output line to understand this.
But looking through it I have a feeling that maybe one of the settings is wrong in your setup. Please connect to the database and run the following query:
shell> mysql -u root -p
mysql> use fog;
mysql> SELECT * FROM globalSettings WHERE globalSettings.settingKey IN ('FOG_DEFAULT_LOCALE', 'FOG_HOST_LOOKUP', 'FOG_MEMORY_LIMIT', 'FOG_REAUTH_ON_DELETE', 'FOG_REAUTH_ON_EXPORT', 'FOG_TZ_INFO', 'FOG_VIEW_DEFAULT_SCREEN');
Get the full output and post here (as text or picture).
@jmeyer I don’t seem to be able to explain this properly. I am not talking about disk size and start sectors although this might be an issue as well. But even if you get this right it still might not be able to boot in the VM as of difference in (virtual) hardware.
By the way, is your image UEFI or legacy MBR? Configure your VM accordingly.
We have received 3 type of Acer computer this year X2640g, X4640G and N4640G.
Both X are working fine with undionly.kkpxe but N isn’t.
N is only working with ipxe.pxe.
This tells me that the ‘N’ system is a uefi system and the ‘X’ systems are bios (legacy) systems. You must use the right iPXE kernel with the proper firmware or it won’t work.
As for the error above. It appears that the undionly kernel can see the network adapter, but not communicate on the network. I too suspect that this is a spanning tree issue. The problem is that spanning tree takes 27 second to begin forwarding traffic. The 10 second delay kernel is not sufficient to bridge this gap. Its best to enable one of the fast spanning tree protocols on this switch port. OR as a test, place a dumb switch between this target computer and the building switch. This dumb computer will keep the building switch port in the forwarding state while the target computer boots. If inserting the dumb (unmanaged switch) between the building switch and the target computer works, then you do have a spanning tree issue.