@servicedesk-pianezza Yes, FOG writes that boot code, and I can show you where. Your finding holds up against our
source and against a reproduction here.

Where it comes from. On capture, saveGRUB() in funcs.sh copies the first 1 MiB of the
source disk into d1.mbr with dd — LBA0 included, boot code and all. On deploy,
clearPartitionTables() runs sgdisk -Z, which does clear the MBR, and then restoreGRUB()
writes d1.mbr straight back over it. The next two commands are sgdisk -z, which destroys
the GPT structures only and leaves the MBR bytes alone, and sgdisk -gl, which rewrites only
the protective partition entry. So the captured Windows bootstrap survives the whole
sequence, and gdisk supplies the entry in its own convention: EndCHS ff ff ff and the exact
sector count.

I replayed that sequence here on a loop-backed disk with one of our own Windows 11 resizable
images. The result matches what you found byte for byte in shape:

LBA0 : 33 c0 8e d0 bc 00 7c 8e ... (Windows MBR stub) 0x1BE : 00 00 02 00 ee ff ff ff 01 00 00 00 af 32 cf 1d

Why it is not simply a bug. On a BIOS-booted GPT Linux disk that same region is GRUB’s
boot.img, and d1.grub.mbr exists precisely so we keep it. We cannot blanket-zero LBA0 on
every GPT restore. On a Windows GPT image it is dead weight — Windows only boots GPT through
UEFI — so a targeted change is available to us. But we should change the right bytes.

Which byte is it? Your diskpart disk differs from ours in three places at once, so we do
not yet know which one the firmware chokes on. Three one-liners settle it. Start from a fresh
deploy that hangs, run one of them, power off, power on, press F2. Redeploy between tests so
each one is measured on its own:

# 1 - the bootstrap, nothing else dd if=/dev/zero of=/dev/nvme0n1 bs=1 count=446 conv=notrunc # 2 - the size field -> sentinel printf '\xff\xff\xff\xff' | dd of=/dev/nvme0n1 bs=1 seek=458 conv=notrunc # 3 - EndCHS -> the diskpart value printf '\xfe\xff\xff' | dd of=/dev/nvme0n1 bs=1 seek=451 conv=notrunc

Each writes inside LBA0 only and leaves the GPT untouched. Test 1 is the one I expect to
matter, on the theory you already stated — a CSM path in that firmware reading or validating
a bootstrap it should be ignoring.

Name the byte and the fix is small: for a GPT image whose OS is Windows, clear that field
during the restore and leave Linux images alone. That also gives the two 2020 reports on this
hardware an explanation, which is worth having on its own.

@Valer I think we need to understand what this plugin is doing.

CSS isn’t something we’ve allowed to be injectable though it could be.

You can still use your own CSS but that’s more at the FOG Configuration -> FOG Setting -> FOG_THEME, but you would need to put it on your server in a location you type the path too here.

https://docs.fogproject.org/en/latest/development/plugin-development

This is a good toolkit for understanding how to build your own plugin.

@Valer Hi Valer,

You can see my tutorial on using Secure boot with Shim, and my thoughts on what 2.0 means for Secure Boot with FOG here: http://forums.fogproject.org/post/158170

@Sebastian-Roth Can I bother you with this quick question ^^^

@george1421 Great, thanks for the info!

@george1421 seems like in this post it is a similar interest they were implying by putting FOS on a bootable partition of the hard drive

https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/4

Hello,

Fix Members tab for accesscontol plugin and some display elements for site plugin (11807ac) : https://github.com/FOGProject/fogproject/pull/647

Regards.

@AUTH-IT-Center Subree is updated to be properly listed as Subtree

@AUTH-IT-Center fog has some hooks and events capable but those are relatively new and not quite as granular as I’d like to see them, though I suppose with the effort of 1.6 it may be worth while to try to find all the possible hooks/events (they can be either and/or both technically) as will as the attributes available for each one. That may help with the event notifications. I warn it does not exist currently.

@csa Did you had success making your own custom task type ?

@Bhav duplicate thread here: https://forums.fogproject.org/topic/17521/not-booting-to-pxe-uefi

@Tom-Elliott Apologies, I don’t know what went wrong there but somehow I got an incomplete version of your changes. git is a confusing beast to me :). I’ve now checked again that I’m running dev-branch and I can confirm that all the warnings have gone.

Thanks again.

@Sebastian-Roth perhaps I can achieve the same outcome with snap-ins?

I have batches of Ubuntu machines that I multicast image. I have a bash script in the image that essentially prefigures the machine but it currently need to be run manually as it require two user inputs unique to each machine.

The reason I wanted the IP of each machine was so I could write a script to SSH into each machine from my PC, run the script and populate the unique inputs from a CSV.

It’s not so clear to me the limitations of snap-ins - is this a correct use case?

@aviel1540 Sure you are welcome to build your own UI. The best of documentation we have you can find here: https://news.fogproject.org/simplified-api-documentation/

@TaTa FOG does not do SSO though you are invited to make it happen. Tell your company to get involved in this open source project, put one developer on this for a few weeks. 🙂

I changed the code to PHP and now it works, so I think it was something security related from the browser.