Subcategories

• General

  General Developer questions relating to FOG.
  388 Topics

  5k Posts

  T

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

• Feature Request

  Request a new feature to be implemented.
  632 Topics

  4k Posts

  T

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

• Bug Reports

  Report a bug with FOG.
  1k Topics

  12k Posts

  T

  @servicedesk-pianezza Confirmed, and your fix is the right one. Thanks for the clear report.

  The check was using the 24-character Base24 alphabet. That set is what you use to decode an older key into its binary form, and N is not one of its digits. It is not the set of characters a key is printed with. Windows 8 and later put N in the key itself, so any key carrying one was refused at entry.

  There was a second half of the same bug. The browser keeps its own copy of that character list, for the masked display of a saved key. So even where a key with an N got stored, the page showed it as five groups of dots instead of keeping the first and last group. Both copies now say the same thing, and a test compares them character for character so they cannot drift apart again.

  The test also runs Microsoft’s published KMS client keys through the validator, and checks that the characters Windows leaves out (A E I O U L S Z 0 1) are still rejected and the length is still exactly 25.

  It is in PR #1773 against working-1.6: https://github.com/FOGProject/fogproject/pull/1773

  It will be in the next beta build. If you would rather not wait, the one-character edit you already made is exactly what landed.