@AngryITGuy First let me say I don’t use FOG for image deployment any more since I’ve moved to a different IT group, but if this situation hit my desk I would go through a similar process as below

I have more questions than answers for you. But the good thing here is FOG is imaging these systems and can deploy windows 10 to the hardware without issue. Right away we can rule out fog’s foundational support system being broken because it can deploy win10 and win11 to other hardware and win10 to this stone hardware.

When I debug something new or strange I try to build a truth table in my head of different experiments to see what works and what not works. Something like:

Deploy and boot win10 Dell laptop: Yes
Deploy and boot win11 Dell laptop: Yes
Deploy and boot win10 Stone laptop: Yes
Deploy and boot win11 Stone laptop: No (kind of)

So now to the unknown questions (and I assume these stone laptops are in uefi mode, you mentioned ‘bios’, but your boot loader is ipxe.efi.

On this stone laptops do you have pxe setup as the default boot source or is it the hard drive? This question is to see if the boot is failing if you are booting through ipxe.efi or if the firmware is having a problem finding the boot partition. If you are booting through iPXE see if changing the boot order to the hard drive solves the issue (for this test).

You will need to turn off secure boot for this next step. If you swap the hard drives between the dell and stone computer, does the stone computer boot normally repeated times? Does the dell computer reboot repeated times OK? This check is to see if the problem moves with the hard drive. The question is around if fog combined with the disk controller hardware on the stone doing something to damage the boot sector for win11 when it deploys. The dells works, can you get the stone computers working by deploying to a dell and then transplanting the hard drive to the stone?

If you deploy win10 and then upgrade to win11 on a stone laptop (verify its working 100%) and then capture and deploy to a same make and model computer. Does it boot correctly on the second computer? Can you deploy it to the same computer it was captured from and does it work? This will test if there is something wrong with your win11 image you are trying to deploy to the stone computer.

Lets see how the above goes before we plot the next test.

Just to recap

Test booting through iPXE vs firmware booting directly to hard drive Swap the hard drives between the dells and stone computers see if the problem moves Try to capture and deploy using the same hardware. First to like computer if no work, try to deploy to same computer image was captured from.

@sega said in FOG Multicast on different VLANs:

So some people already tried it?

Yes and so have I. You would need some way to dynamically change the network adapter defined in the global FOG settings to change the network adapter. You might also need to change a file called /tftpboot/default.ipxe to point to different interfaces. You might be able to get around this by setting up multiple tftp servers on the fog server, where each tftp server bound to a different interface and had a different home directory, that would be more of a long term change. And then you need to work out a way to update the imaging network interface in the fog settings depending on what interface you wanted to image using. There may be more crafty ways about doing this, but this is just off the top of my head.

@george1421 I would need help with where I can edit and which files to add a script for quick inventory.

Thank you very much for the detailed explanation of the problem and for adjusting the code.
I’m not on the dev branch yet, but I’ll make sure to switch and use debug mode to trace the function.
It’s likely that the tip about using the serial number as the Primary Host Disk will need to be incorporated into my process.

At the moment, I have a large number of Windows 11 reinstallations to handle due to the end of support, so it will probably be a few weeks before I have time for this.
I’ll post an update in this thread once I get to it.

@mrowand The whole point of the checkAuthAndCSRF is to prevent unauthorized access. Based on the message I’m seeing, the 403 forbidden is happening because it’s crossing origin to get the data or the CSRF token isn’t passing correctly:

Here’s the code that validates:

// Optional defense-in-depth: Origin/Referer check for state-changing requests public static function checkOrigin(array $allowedOrigins): void { $method = strtoupper($_SERVER['REQUEST_METHOD'] ?? 'GET'); if (!in_array($method, ['POST','PUT','PATCH','DELETE'], true)) { return; } $origin = $_SERVER['HTTP_ORIGIN'] ?? null; $referer = $_SERVER['HTTP_REFERER'] ?? null; if ($origin) { foreach ($allowedOrigins as $allowed) { if (stripos($origin, $allowed) === 0) { return; } } http_response_code(403); echo _('Forbidden (disallowed Origin)'); exit; } elseif ($referer) { foreach ($allowedOrigins as $allowed) { if (stripos($referer, $allowed) === 0) { return; } } http_response_code(403); echo _('Forbidden (disallowed Referer)'); exit; } // If neither header is present, you can decide to be strict or lenient. // Often lenient to avoid breaking weird client setups. }

I suspect your console has more information leading to the specific error that was hit.

ultimately the code is working as expected and there’s something in your environment causing the issue. Now, to be fair, you said you installed Stable, and Dev-branch has a fix of which I admit I missed.

If you’re willing/able to install the dev-branch I suspect you’ll see this is working much better.

@boombasstic This is known and will be fixed automatically on the 15th, but please if you need to switch to the dev-branch and install it. Then you should be able to export reports.

@phant0mbot said in Dell OptiPlex 3000 Thin Client:

have tried both SAN and GRUB exit options

boot loader == snponly.efi

These are in contradiction with each other. SAN boot and Grub are bios boot methods. snponly.efi is a uefi boot loader. Since you are getting into the fog iPXE menu we can assume the hardware IS uefi based since it is booting snp.efi. Try a uefi exit mode of rEFInd (refind) to see if that will boot from the hard drive. The default value can be set globally in the fog configuration->fog settings page. Don’t force a bios attempted boot from a uefi booted computer, that never works.

@Jchinn412 The answer is it depends on how you have your disk structure setup

Post the results of these two commands.

lsblk
df -h

It maybe easy or harder (but not impossible) depending on how you have the disk created.

@ecoele The fact that dev-branch is in 1700’s this informatino seems to indicate your’e still running the latest stable.

Once you switch to dev-branch you need to pull in the changes:

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

Should get you installed.

You may also need to (from the browser) do a “CTRL + SHIFT + R” to do whats called a hard refresh in the browser to get all the latest/new javascript information.

@Tom-Elliott Thanks, going to switch back to 1.6 very soon.

@Fog_Newb Yep, it’s as I suspected:

The Line:

Subsystem sftp /usr/lib/openssh/sftp-server

should be changed to:

Subsystem sftp internal-sftp

Then restart ssh services: systemctl restart sshd

Then your Storage Node testing should succeed!

@rhysb92 We need more information.

i ask because I have just built a new VM, and installed dev-branch/stable and it completed and I was indeed able to login with the fog/password combination where i then changed the PW.

So I feel like we’re missing some key information.