@daniel4567 The user and password should be set to that of a user who can actually login to the fog ui.
You should follow the information here as well:
https://forums.fogproject.org/topic/4433/is-it-possible-to-remove-the-fog-quick-image-password/22
@Zourous The file is already available as part of the base install.
We build:
snp.efi
snponly.efi
ipxe.efi
realtek.efi
Probably a few others, but it’s already in the tftp folder
@jgibson60 For a temporary try, maybe try the realtek.efi driver file?
@UserBxl Does the base image have FOG Client installed? Is the service disabled and re-enabled after the sysprep process completes?
@UserBxl Typically this is due to the way the base image was created. Either drivers on the new system is interferring or the FOG Client is running things before sysprep has the time to finish setting things up.
Usually this is user error.
@jeremyvdv if you’re using UEFI, option 67 should NOT be undionly.kpxe (this is non-uefi)
You could try:
ipxe.efi
@Lenain This is a task, so I believe the task id for wol only is 4.
I forget the exact syntax, but this should do the job you need.
@Sebastian-Roth Should be done, though I didn’t update the version in working-1.6
@Sebastian-Roth I can check, but can you provide the github link for the changes you made?
Just for simplicity of course lol.
@Skreadz https://www.molnar-peter.hu/en/ubuntu-jammy-netinstall-pxe.html
There will likely need adjustment to make it ipxe compatible, but this seems like it’s still possible.
@Skreadz I don’t understand what you’re requesting exactly?
@Richarizard504 Is it possible it’s requesting the resource from a different server than the one you know the files are on?
@Richarizard504 404 means the file does not exist on the server it’s requesting it from.
@WT_101 There were a lot of changes between v1.20.1 and v1.21.1 though we (FOG) don’t manage the repository of ipxe itself.
Here’s the code where I believe things might’ve broken the boot capabilities, but this is still just a best guess based on the changed code, not really an “assured” here’s what’s definitely broke.
A git bisect might be useful so we can see potentially where things are good -> bad and indicate to ipxe development so a more proper fix might be addressable.
https://github.com/ipxe/ipxe/compare/v1.20.1...v1.21.1#diff-9ec49bac9202333b51ea932869865503ace555e43797e9e26898e4a5b813944e
@hutch Have you guys tried using the Exit Type of just “EXIT”?
Refind has loaders that might be adjusting the memory space that the initramfs is trying to load into at the same time Refind exists.
Please note that the reason all these exit types exist in the first place is we have no idea of how things will work best. Some systems Exit works fine, for others refind is a better option. It’s a great ol’l guessing game and nobody knows the right answer.
@pacodijou You likely need to rethink how FOG operates.
The fact that you got into FOS itself (which is where you’re at) at least shows DHCP is working and passing the Options 66/67 appropriately, but it’s failing to get access to the fog server.
Based on what I can see, the DHCP items are working properly, assuming 192.168.75.10 is the fog server since that’s also where it’s trying to connect to look for access directly to the fog server.
Do you access the fog server at url:
http://192.168.75.10/fog/index.php?
@zuchowra This often happens because of either the DHCP server isn’t presenting boot options, but more often it’s because you ahve multiple things responding with what server should be used. The system has no idea which one to use, so it requests you manually enter it.
Please check your dhcp server to ensure the boot option is sending option 66/boot server name