Categories

• Technical Help

  Get help with your FOG system.

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

  115k Posts

  C

  Hello everyone,

  I’m hoping someone has seen this before. I’m at the point where I believe I’ve ruled out the common server-side issues.

  Environment
  FOG 1.5.10
  CentOS 7.9
  Apache/httpd
  ISC DHCP
  HTTP boot
  Server IP: 10.29.33.2
  Target hardware:

  28 × MSI PRO B760M-P DDR4 desktops (MS-7E02)
  Intel 13th Gen
  Realtek NIC
  UEFI boot
  These same desktops were successfully imaged from this FOG server last year. The major change this year is that the master image was captured from a different teacher computer.

  Failure
  PXE boot proceeds normally:

  iPXE starts
  default.ipxe loads
  boot.php loads
  bzImage… ok
  Could not select: Exec format error
  https://ipxe.org/2e008081

  The system never reaches FOS Linux or Partclone.

  Things already verified
  Apache working
  boot.php generates correctly
  default.ipxe looks normal
  init.xz present
  bzImage downloads successfully
  SHA256 checksum verified
  HTTP Content-Length matches file size
  Downloaded kernel matches server copy exactly
  Rebooted server
  Verified httpd, dhcpd, database services are running
  Tried both current kernel and archived 5.15 kernel

  Manual iPXE testing:

  imgfree
  imgfetch http://10.29.33.2/fog/service/ipxe/bzImage
  imgstat
  imgexec bzImage

  Kernel downloads completely (~10.7 MB), but imgexec immediately returns:

  Exec format error

  Question
  Has anyone seen an EFI/iPXE compatibility issue with:

  MSI PRO B760M-P DDR4
  13th Gen Intel
  FOG 1.5.10
  that causes Exec format error immediately after downloading the Linux kernel?

  Are there newer recommended iPXE binaries or known BIOS settings that resolve this?

  Any ideas would be greatly appreciated.

• 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

  8

  @Cpasjuste

  Thank you, I appreciate that. And yes, I did spend a lot of time on it.

  I agree that it bypasses the official installer in order to make use of Docker environment variables; however, at this stage, I don’t believe that FOG is going to change so dramatically that it’ll break it often.

  I will add that if this could get adopted as an official docker image, we could work with the FOG team to make sure nothing gets to pushed to the FOG code that would break the container until we can adjust the container as well.

• Developers

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

  General Feature Request Bug Reports
  2k Topics

  21k Posts

  T

  @Valer Thanks for the report and the writeup, that’s a good catch. You’re right about the cause. Debian 13 dropped the sysv-rc-conf package since it’s fully on systemd now, so the installer chokes trying to apt-get it. We never actually use that tool on a systemd system anyway, it only ever got called on the old non-systemd paths, so it was just dead weight on Trixie.

  I pushed a fix to working-1.6. It leaves the package off the list on Debian 13 and up, and it also strips it out of a cached .fogsettings so an in-place upgrade doesn’t drag it back in. Older Debian keeps installing it like before so nothing changes there.

  If you want to get moving before you pull the update, you can either grab the latest working-1.6 and rerun the installer, or just open /opt/fog/.fogsettings and delete sysv-rc-conf from the packages line, then run the installer again. Either one gets you past it.

  Let me know if you hit anything else on Trixie.