Categories

• Technical Help

  Get help with your FOG system.

  FOG Problems Hardware Compatibility Windows Problems Linux Problems Mac Problems General Problems
  12k Topics

  114k Posts

  J

  Master Node
  Fog 1.5.5
  Debian 9

  Storage Node (proimage02)
  Fog 1.5.10
  Debian 13

  Below is the output of /opt/fog/log/fogreplicator.log

  Most concerning is the line " sh: 1: Syntax error: “(” unexpected " or any of the “file does not exist” lines. Those errors show for each image FOG finds to replicate

  This has never worked for me- I just set up the FOG storage node server a few days ago and connected it to the master FOG server.

  [06-17-26 10:16:18 am] * Found Image to transfer to 1 node
  [06-17-26 10:16:18 am] | Image Name: HP280-G1-WIN10-2026
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1.fixed_size_partitions (proimage02)
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1.mbr (proimage02)
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1.minimum.partitions (proimage02)
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1.original.fstypes (proimage02)
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1.original.swapuuids (proimage02)
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1.original.uuids (proimage02)
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1.partitions (proimage02)
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1p1.img (proimage02)
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1p2.img (proimage02)
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1p3.img (proimage02)
  [06-17-26 10:16:19 am] # HP280-G1-WIN10-2026: File does not exist d1p4.img (proimage02)
  [06-17-26 10:16:19 am] | CMD: lftp -e ‘set xfer:log 1; set xfer:log-file /opt/fog/log/fogreplicator.HP280-G1-WIN10-2026.transfer.proimage02.log;set ftp:list-options -a;set net:max-retries 10;set net:timeout 30; set net:limit-total-rate 0:1280000; mirror -c --parallel=20 -R --ignore-time -vvv --exclude “.srvprivate” “/images/HP280-G1-MT-WIN10-2026” “/images/HP280-G1-MT-WIN10-2026”; exit’ -u fogproject,[Protected] 192.168.16.30
  [06-17-26 10:16:19 am] | Started sync for Image HP280-G1-WIN10-2026 - Resource id #27390
  sh: 1: Syntax error: “(” unexpected
  [06-17-26 10:16:19 am] | Sync finished - Resource id #27208
  [06-17-26 10:16:19 am] | Sync finished - Resource id #27236
  [06-17-26 10:16:19 am] | Sync finished - Resource id #27316
  [06-17-26 10:16:19 am] | Sync finished - Resource id #27353
  [06-17-26 10:16:19 am] | Sync finished - Resource id #27390

• Announcements

  Get the latest news on what's happening.

  Security Advisories
  184 Topics

  825 Posts

  A

  @Tom-Elliott I really appreciate that you are putting effort into providing more frequent releases, which makes it easier for everyone to deploy new security fixes in time. Keep up the good work!

• General Topics

  View tutorials or talk about FOG in general.

  General Tutorials
  2k Topics

  19k Posts

  K

  @Florent Hi Florent,

  I actually have been meaning to look into this some more, but the likely answer is no, or at least, not entirely. The way that support works is, you download a signed iPXE 2.0 binary from iPXE and a copy of their signed shim. That shim is signed with the Microsoft keys and trusts the iPXE signing keys. What this means in practical terms is, all the steps above would still need to occur, it’s just that the signing of the iPXE binary is managed by iPXE, and you don’t need to enroll a key to boot iPXE.

  That said, I would imagine this only covers you for booting iPXE, any chainloaded binaries would still need to be signed either with Microsoft’s key or a MOK key you’ve enrolled on the machine. In FOG’s case this means the FOS kernel has to be signed and trusted on the system, in addition to any other binaries (for example memtest, refind) you plan to boot via FOG.

  The other likely blocker is the build itself. Naturally, only iPXE can sign binaries that the iPXE Shim will support. Currently the FOG installer actually builds a slightly modified iPXE binary from source. While I’m unsure if these are all that different from the pre-built binaries from 2.0 in terms of support and functionality, it would at the very least need to be changed to instead pull the iPXE 2.0 binaries.

  I don’t think any of these are particularly hard to overcome or deal with though. The bottom line is, 2.0 makes it easier, but only to a point. To get real proper Secure Boot support in FOG, they’ll likely need to generate their own signing keys, and start signing at least the FOS kernels (if not iPXE itself) and update FOG to include shim support somehow.

  That said, for basic support, I doubt they would need to go the full mile and get a Microsoft approved signing key, I think distributing a certificate/key you can enroll via MokManager and using a pre-existing signed shim (like the iPXE provided one) would more than suffice for most usecases. I’m not sure how difficult it would actually be to implement any of this into FOG, that’s a question for someone who knows PHP and is more familiar with the FOG codebase than I.

  Sorry if that’s a bit long winded, it’s not an easy topic to distill. Hope that helps though.

• Developers

  Report bugs, request features, or get the latest progress.

  General Feature Request Bug Reports
  2k Topics

  21k Posts

  J

  @Tom-Elliott Thanks for the clarification! I’ll try upgrading to the latest stable version, I was planning on doing this anyway.

  I’ll look into the Persistent Groups plugin and see how it works!