@sebastian-roth Thank you. That fixed it.

My workaround that has worked so far was to make the source image drive small, 28GB in my case, and it seems to always work now so long as the target drive is bigger, a complication with the last partition not wanting to be any closer to the beginning of the drive as it was on the source disk (i think), but it can be further away with no issues:

https://forums.fogproject.org/topic/14571/imaging-windows-10-v2004-with-uefi-gpt-partitions-onto-31gb-or-smaller-drive-and-failing/3

@sudburr Ok, I tested and updated my version of the script below (derived from yours).

Again, make sure you have backups of your /images and the certificate files before you run this script!! I won’t be responsible for any trouble caused by this script!

@sudburr Just so you’re aware - we are still working on the 1.5.x version of FOG. Long term aim is to finish that, merge all the things into the 1.6 branch (Tom does this every now and then with all the fixes we add in 1.5.x) but we’ll most certainly release one or two more 1.5.x versions before we call it “finished”.

@sudburr that’s where i was confused. I was thinking it would boot uefi no problem, but for whatever reason you needed it to legacy boot for imaging.

@sebastian-roth That did the trick! That server can now update its kernel.

It’s interesting to see how two different causes have similar results.

I was in the throes of migrating all our images over to 10v1709 so I was only just barely able to accomplish what I’ve detailed above before I had to return the unit to its owner.

@sudburr said in TFTP error oh my (ESX Server):

PXE-T00: Permission denied

It looks like this might be a file permission issue (if not selinux). The permissions on the /tftpboot directory should be 655 or 755. Make sure the parent folder /tftpboot as well as all of the files have these rights.

@tom-elliott Just looking at rom-o-matic 1b67a is the latest release. I’m not in a place right now to see what boot version is in 1.4.4. I can check later tonight. But I would suspect that 1.5.0RC9 will have the fixed version of ipxpe where/when/since ipxe7156.efi was removed from fog.

@wayne-workman hyphen was needed for legacy client

@sudburr I’m not sure what is going on or what you’re trying to do - but virt-manager typically only connects to hosting systems via SSH, not the guests. Virt-Manager provides direct console access to guests, but SSH to the guest is not involved in this, it’s via ssh to the host.

@sudburr The reboot isn’t necessary, but otherwise great job on the post below - it’ll help many folks in the future.

< /facepalm >

Looks like I picked the wrong week to quit amphetamines!

@sudburr Would you be willing to send a copy of your database to one of the developers or moderators? If I had a copy of your DB, I can figure out what’s causing the issue.

Good to know. I won’t be able to test right away though. I’m busy doing summer stuff right now. I’ll get back to you as soon as possible.

< facepalm >

Oh geez … okay, ignore everything. There is no problem other than that the switch servicing that bench had been reprogrammed. The ports used had been set to the wrong vlan; a vlan serviced by a FOG server that didn’t have the intended accounts.

… oy

@sudburr Right, I don’t touch the repo, this i leave up to you. I try to leave the installations as virgin to the OS as possible.

This isn’t a bug. This happens on fresh installs because there is nothing to work from.

While I can remove the message, it’s a way for us to know if this is a fresh or upgrade.

It does not impede installation in anyway. I understand it’s not “pretty”, but it ultimately work.

Default capture method is now in the “FOG Configuration Page->FOG Settings->General Settings category.”