@GregorS Should be fixed apologies. Trying to fix XSS issues.

@kratkale You don’t need the clonezilla to see this information though admittedly it’s not exactly straight forward.

You can load FOG into debug mode and it will drop you to a shell where you can then run the lsblk command as well.

That said, if booting to clonezilla isn’t that difficult a thing, then it’s all good either way.

@kratkale I’m unsure I understand?

If the Group Primary Disk is empty, nothing should be changing on the hosts within the groups.

Just update the group’s Image, and save.

@kratkale I don’t know what you are asking.

what’s nvme1n1 this boot cycle, might very well be nvme0n1 next cycle.

While you may see some level on consistency, SERIAL based devices (PCI, SATA, USB, etc…)

All load their identifiers (/dev/sda, /dev/nvme0n1, etc…) on a first come first serve basis.

What’s /dev/sda1 this boot may be /dev/sdb1 next boot and so on. There’s 0 method to guarantee they will always get the same label which is why many Linux machines use a UUID for the fstab file now instead of their path names (which was used for a long period of time).

FOG just returns the list of devices lsblk sees in the order lsblk sees it.

@kratkale I didn’t know you were updating the serial of a group of devices, you should not do that. Groups are just mass updating hosts with the information you provide for the Host base settings (snapins, primary drive, kernel, etc…).

@kratkale That seems correct to me, yes. If this is a drive you’re testing proof of, I’d first just replace the actual second disk with something you don’t care to lose to test.

What I don’t want is you to just trust me at my word for the sake of things and lose actual data.

Another method you can use in case this isn’t sufficient, it’s a little more involved I suppose is to simply unplug the disk you don’t want being written, but that’s a part of the problem. At a glance you of the hardware you have no idea what drive is which. That’s the basic problem you’re running into now:

nvme0n1 this time might be the right disk, but next boot nvme0n1 might be the student disk. It’s all dependent on who starts up and responds first.

@kratkale Like I said, if you know which nvme drive has the student data, and which is expected to be the OS:

On a registered host you can explicitly call out which drive using “serial, wwn” or otherwise.

You type in the wwn or serial number: lsblk -pdno PATH,SERIAL,WWN,SIZE --nvme respective of your device. (I lowercase them for simplicity.)

Find your “primary” drive, and put in either one of those details in the form field and give it a shot. It should work and will leave the other drive completely alone so long as the type of image you’re using is “single disk” style.

@Mr_K This seems to be a routing issue:

Your fog server lives at 192.168.0.3

Your machine is getting an IP of 192.168.1.148

Your router providing 192.168.1.X is likely unable to route 192.168.1.X -> 192.168.0.X

@neodawg Can you provide the systems php error log, for Alma I think its RPM based so you would -> go to the page and see this -> get the last 100 lines or so (sudo tail -n 100 /var/log/php-fpm/www-error.log) This should tell us where it’s failing.

If you’re also able, can you tell us what version of FOG you’re running?

(Login to fog, bottom right hand corner should tell you the version you’re running.)

@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?