@Jias94 Issue 1, yes this is expected. 2, 3, yes, yes. 4. Yes. 5. Have you tried updating? 1815 likely had the issue of what you’re describing but i"m pretty sure this is corrected in the latest stable.

Groups are just “mass updaters for Hosts”

You might be more interested in “Persistent Groups Plugin”.

@kratkale You can do the same thing with “Hard Drive” paramater of the Host in question.

If you know the wwn, serial, or block size of the disk you intend, it should figure out which drive you intend. Of course this is specific to the machine you’re attempting ot image, but this same functionality is possible in FOG.

@mashina Ah, thank you for that and sorry for my denseness. Indeed this is a bug and I’ve replicated and figured out where this is occurring.

I have pushed a few mroe adjustments in an attempt find and fix more bugs (thanks AI review and whatnot)

Please pull and let me know if there’s any other issues.

@mashina Can you describe?

I’m not sure I follow what you mean by a “host not associated to a group”?

Do you mean a Storage Group without a single Storage Node associated to it?

@Bhav There is not at this point in time.

Secure boot is meant to be… well, secure.

There are people attempting to get there, but I can say, right now, FOG just isn’t there right now.

On the forums you can see this at:
https://forums.fogproject.org/topic/17949/fog-secure-boot-with-shim

Which might help lead you in the direction as well hopefully.

@heix75 No.

Not because it’s not a QOL improvement (it is) but because what you see in 1.5.x.x is NOT what is the end goal.

If you want to see what the UX is moving toward install the version of FOG on working-1.6.

You’ll understand (I hope), then, why I’m saying this.

@Exsival When you say “Causing the fog server to crash” what exactly do you mean?

If it’s just a “saying” I can understand that but from a technical standpoint what this means is completely different and would need logs. If all you mean is the machine in quesiton is hanging, that’s a different issue altogether. I highly doubt the whole FOG Server is crashing.

@lucasgfaj have you turned off secure boot?

@JCS-RVK Based on the limited information I see:

VGA RAM on yours is 8MiB vs 16MiB (doubt this would be the issue):

Of other note is the “Secure boot -> Propogate Certificates” which seems to be missing on yours?

Also His VM has 8 cpu limits and memory is much higher (4/16 vs 4/4 on yours):

I’m not saying these are the definitive causes of the problem you’re seeing, rather just pointing out the differences I’m seeing at a glance.

Why one side works, vs the other, I don’t know (using this XCP-ng specific kernel of course)

@devle Can you post your apache error log or php-fpm?

Please see my signature to see where to locate those.

@JCS-RVK Roger thank you.

I know @BPSTravis was able to test with XCP and this particular kernel, so if you’d be willing to maybe share the VM Configuration less any ‘secret’ data?

@JCS-RVK https://www.reddit.com/r/Ubuntu/comments/1jc7bzj/install_hangs_after_efi_stub_measured_initrd_data/

I’m using this link, I know it’s a thirdparty link but wanted to show my thoughts here.

Based on what I’m seeing -> it would seem to me that the output is working just fine, but sending to a different Video output port than the expected one when the machine boots.

Since it’s waiting on input, the machine appears to be “Hung” but it’s not really, so maybe (without making any other changes) If you’re able connect a monitor (or maybe multiple monitors) to all the Video ports on the machine and see which one is directing video to.

yes, I know this can be clumsy becuase one video card might have multiple output ports.

I hate this issue because it never seems to have a solution, but maybe that’s because there (technically speaking) wasn’t anything wrong. The kernel has decided to send the output somewhere else.

@JCS-RVK said in EFI Stub Errors on XCP-ng Virtual Machine Attempting 'Perform Full Host Registration and Inventory':

EFI stub: Measured initrd data into PCR 9.

Do you have nomodeset as a kernel argument set somewhere?

Maybe on the Host kernel args or Global Kernel Args?

@JCS-RVK Would you be willing to disable your TPM on the XCP-ng device and see if that helps?

@boombasstic You’re able to test this on your own already:

Change your branch from stable -> dev-branch

cd /path/to/installer
git checkout dev-branch
git pull
cd bin
sudo ./installfog.sh -y

This will install whatever is “bleeding edge” on the development (which eventually roll up into the stable automatically on the 15th of each month).

@devle I’ve made a couple of edits, though I still cannot replicate the problem you’re seeing.

You shouldn’t see the errors any more (just saying), though I don’t know if these things will fix whatever problem you’re seeing.

@boombasstic Can you check DB with: SELECT * FROM HISTORY; after your entry?

When I test in 1824, I’m not seeing the problem. So it’s possible a future set of updates fixed the problem you’re specifically looking at.

When a MC task cancels (or completes) the session name is expected to be cleared out because you may need to reuse the session name down the road.

I’m seeing the clients and time are being set correctly.

Maybe I’m not understanding what exactly you’re doing?

Similarly, I started 2 multicast sessions for the exact same image, and I’m unable to replicate what you’re seeing.

i also cancelled one then started a new session and that worked.

To be fair (like I said) I’m on 1824 so maybe we unknowingly fixed the problem you’re hitting right now?

@devle I’m the developer for FOG so I’m almost always at the “latest” because i’m the one making them.

The version I’m at currently is ending in 2283 (so about 6 commits ahead of you.)

Yes, cron tasks are expected to have stMinute, stHour, stDOM, stMonth, stDOW filled out and delayed tasks would not have this filled out (and the stDateTime would have the timestamp of when that task is expected to kick off.)

@devle The first one appears to be set to run at 15:00

I don’t know what timezone you’re in, but I suspect your server’s timezone is showing UTC.

It’s interesting but it shows you should be seeing them trigger at 2026-03-26 15:00 (~ 1.5 hrs from right now, and 1.75 hrs from right now)

So it does appear scheduled tasks are working appropriately since restarting the service at least?

Also, i might suggest updating the latest working-1.6 as that will kick the tires around other services as well.

You are able to set the UI datetime FOG Configuration -> FOG Settings -> look for TZ_INFO and update to your relevant Timezone.

It does seem, maybe, your FOGScheduler service may need a good kick though?