@Valer
@Tom-Elliott may have already fixed this, but if you’re using refined that would also need to be signed. We should be able to just have it signed by our new secure boot system and then it should be happy.
But also, the newer version of ipxe has proper support for SANBOOT in uefi mode, so you may be able to skip over refined and just use SANBOOT to boot to disk, try SANBOOT as the exit mode on a host and see if works, if it does you can change your global default and have an easier time.

@Tom-Elliott said in How to upgrade to FOG 1.6?:

Client state What the task does
Setup Mode (platform key cleared) Enrols outright. Nothing to confirm, nobody at the keyboard.
Normal (keys present, Secure Boot off) FOS stages the MOK request itself, non-interactively. Someone answers the blue MokManager screen once on the next reboot.
Already enforcing Secure Boot Cannot run — the machine will not boot FOS in the first place. Use the live USB route for those.

One minor correction, with secure boot enabled on a new machine, if you boot to the signed shim you can use the Mok enrollment boot issue without needing to disable secure boot, but you do have to be physically at each machine to enroll.

@csurepair I think Elite is referencing snapdragon elite? I actually don’t see any intel options for the laptop 7.
So you may need it to boot to the arm pxe file, but you’ll also need a new image for arm64 I imagine.
Microsoft also did something like this with the surface GO for business, there was a surface go 4 but all of a sudden no more surface go 4 being made and the product line was dead. They made a similarly priced (at the time, not anymore) 12" surface tablet but snapdragon based. We opted to not change our entire cpu architecture, so sadly I don’t have any experience with getting this working. I know @rodluz has done a lot with getting arm working with FOG and may be of more help if booting to arm kernel and init doesn’t work.

@csurepair Is this surface laptop an intel cpu, or is it a qualcomm cpu?

@Strahd I would try updating PHP to 8.3, @Tom-Elliott managed to test it and it worked with 7.4 but I’d still suggest updating your PHP for best results and best security practice. I found (though didn’t test) a guide online right quick https://php.watch/articles/php-8.3-install-upgrade-on-debian-ubuntu#php83-ubuntu-quick there are many others out there.

I would also go in the database and see what your schema version is

mysql -u root fog
select * from schemaVersion;

318 is the latest I believe, if yours says 318 and is stuck in a loop, maybe you can try forcing it down and then trying the schema update again. i.e.

mysql u root fog
update schemaVersion set vValue=317 where vID=1;

Then open your fog server, it will redirect you to update the schema, and see if it takes then.

Also any time you’re attempting an install and it fails, if you could grab and share the error log it mentions i.e. /root/fogproject/bin/error_logs/fog_error_1.6.0-beta. 3064. log that would be very helpful.

There’s something specific to your instance that we need to find and fix. Maybe you have a firewall running sudo ufw status ?

@CanadienITGuy Just for your and anyone’s fyi the autoexec.ipxe... Not Found is not an error. It’s more of an info message than a warning or error.
I actually have tested adding an autoexec.ipxe, even just an empty file to remove that message but even an empty file or a file that is even just a symlink or copy/paste of our normal ipxe/boot menu files causes things to break in the process.
The autoexec.ipxe is meant for adding customization to the ipxe process without needing to re-build the ipxe binary. But my testing with it within the fog workflow was that it’s best to just let that message exist and to see it as it being not found means the process will not be altered from your expected Fog ipxe workflow

@siarkowski I believe I have found the cause of this.
A while back, right after the version you reverted too, we added an improved queueing system which is working perfectly in 1.6. However when we ported it backwards into 1.5.10.x I made a simple syntax error (the wrong $task->id vs $task->get('id') ). I have fixed this in the latest dev-branch.

This should also greatly improve the experience of the imaging task queue (see also https://github.com/FOGProject/fogproject/issues/736 and https://github.com/FOGProject/fogproject/issues/691) I thought I also wrote a post somewhere in the forum walking through the updated process that fixed some longstanding date math issues, but I can’t find that now.

Point being, if you would be so kind as to update to the latest dev-branch version and see if it fixes the issue, that would be very helpful.

@eliaspereira This should be fully fixed in the stable release of 1.5.10.x coming on the 15th of this month and in the dev-branch as of now.
I thought it was already fixed back in September, and it has been working in 1.6 since then but we just got a report of a related issue here https://forums.fogproject.org/topic/18081 which I believe I just fixed.

@tian @DBailey635 @eliaspereira Apologies for missing this post. This was fixed in August-ish of last year, see also:
https://github.com/FOGProject/fogproject/issues/736

I found this searching for a post I wrote about it, as I’m pushing another fix for this for a bug just found in 1.5.10.x

If you update to the latest dev-branch (or what will be stable on the 15th of this month) or give the working-1.6 branch aka 1.6-beta a try, you’ll find the queuing problems fixed.

@bond007fink @jayrehme
By “Latest Update” do you mean the December updates for Win 11 or do you mean the latest release version of 25H2 ? I haven’t tested 25H2 yet.

@pbriec Sorry that your post got lost in the shuffle, I saw it pop up with @raul’s response.
I imagine/hope you got past this in the last year but just in case, the fix would most likely be resetting the host encryption from the web ui (removes some token related database entries on the host record) then restarting the fog service on the client.

If that didn’t do the trick, then restarting the fog service along with resetting the hots encryption should fix it.

@CoNickt @avh2025
Not all usb ethernet adapters are created equal. I would usually say to just bite the bullet and get the vendor specific adapter but it looks like you already did that. I have usb and usb-c adapters that work fine but different uefi firmwares behave differently. i.e. Microsoft surface just has to have its surface branded adapter for native boot to work. HP will work sometimes with the dell or lenovo pxe capable usb-c adapters. We also recently got 2 different hp laptop models where one had to use snponly.efi and the other was fine with ipxe.efi. I maintain a table of models and which adapters work with what we have. Lots of things do just work once you have a collection of usb adapters. Unfortunately, it’s an issue of hardware vendors adding proprietary limitations, but luckily between fog and ipxe you can typically get it working pretty smooth.

Generally if you’re able to pxe boot though, it should find the adapter within pxe. It could be a case of it being too “new” an adapter that requires a different driver not in ipxe. In that case though, I would try using snponly.efi as it may have different behavior with less things loaded in the pxe side. It may also be a driver or setting needed in ipxe that could be handled in a custom compile of ipxe, there’s some info on that here https://docs.fogproject.org/en/latest/compile_ipxe_binaries

It’s also possible to use a tool such as rEFInd to get to a uefi cli console. If you load the ipxe.efi and or snponly.efi and then if you can obtain them the efi driver for the adapter you can do a fs0: to enter the usb disk (it may be fs1: or fs2: you gotta ls on each disk to find the right one) then load usb-network-driver.efi then ipxe.efi to ensure the usb network driver is loaded in the efi for that session and then boot direct to the pxe file which will start the fog network boot. It’s a bit of a hassle but it usually works for me when all else fails. I have an old startech usb 2 ethernet adapter I do this with. This has worked universally but it’s not an ideal solution, but can be poc that it can be done on any device.

I hope my rant was helpful.

@bond007fink @jayrehme
I do a monthly update to my image (single disk resizable) with the latest updated added to the iso I use to install. So I’m using the November iso with the December updates embedded for win 11 24H2 x64 and I had no issues with resizing.

So it may be a config issue on your end or it could be a more specific use case due to a windows upstream change.
Can you give a little more information on the hardware you’re capturing from and what your settings are on the image definition in fog?
I can try to recreate to some extent.

@george1421 said in Broken iPXE boot loader:

@Mightmar I wonder if the devs for iPXE has changed something in the ipxe source code to cause this error message about autoexec.ipxe not found. This should be supplied by the fog project add on files. I’ll take a look at the compiler to see if something has changed. You should not see this error.

Reinstalling 1.5.10 will fix the error of the latest build of iPXE. Also you mentioned about a later version of FOG. Yes you can install that over 1.5.10 without issue. It should also have updated (but not the newest version of iPXE).

This is the first post I found searching autoexec.ipxe so replying here for future searchers.

This was an addition in a recent ipxe version, and is meant to be a way to add ipxe based functionality without needing to recompile ipxe in order to edit an embedded script (https://github.com/ipxe/ipxe/discussions/1237#discussioncomment-9847219), I can’t find the post/doc again but I remember reading in one place that ipxe added it as part of the hopes of getting a signed ipxe shim so users could use the signed shim and then use this script to add what they can’t embed. While technically we can create a blank file in /tftpboot/ i.e. just

#!ipxe

which will remove the error during boot, this can then cause kernel panics when loading into FOS. Why it does this is a bit of a mystery at the moment, maybe it’s adding to or replacing another part of our pxe menu scripts that causes something in loading the kernels to lose access to ramdisk drivers. But adding it can break everything, so for the time being, just ignore the error.

@gaptoothgonni Well darn, have you tried booting with snponly.efi instead of ipxe.efi? It wouldn’t make a ton of sense if that worked but something else to try.
If it’s booting to the wim though, it should just be getting the drivers from the wim unless ipxe somehow changes how they’re presented, which I don’t think it does but that’s also the only difference between where it’s working. Might be worth looking at https://github.com/ipxe/ipxe/discussions and seeing if anyone has had similar issues. Since you’re just using FOG to create the ipxe boot menu, it’s not likely anything within FOG that’s causing this. You could try ipxe’s pre-built boot files, though they won’t have the embedded fog stuff https://boot.ipxe.org/ but maybe will make a difference. There’s other ipxe efi files you can try too, or try an older one ( I think we still include some legacy ones in /tftpboot)

@pilipp_edv That should be enough I imagine, thanks for being thorough. I’ll take a look at the kernel config when I get a chance.

@pilipp_edv
Glad you got it figure out.
In case you aren’t aware, you can download that bzImage as a different name like bzImage-mmc and use that case sensitive name in the Host Kernel field on any host you have with the mmc and your other hosts can use the default latest.

Would you be willing to share more info on the make/model of these computers and or the make/model of the mmc controller and such? Although it could just be down to what driver versions are included by linux at the kernel level with different versions of the kernel, we can also check if there was a config change in what we include in the kernel between then and now that could have caused this.

@chunter2 Ah, yes that would do it.
That just becomes the default value when creating new hosts.
If you set it via a group, it will update those values on all hosts in a given group, but it doesn’t do that dynamically/perpetually.

@ramone As far as I am aware, no one ever volunteered to take up the docker image maintenance. It’s essentially dead.
I think it’s possible in theory, you would just need volumes for the fog directories that need to be static between updates like the database and images, though there would surely be other fun issues with ports to work out. I personally see the desire for it if you’re in an environment where you already have lots of containers as a standard in your infrastructure, but I like having it just on its own server.
Is it not an option to start with a docker image that doesn’t already have a database on the default port? Or are you saying the docker host already has a database on said port?
I’m also sure we could figure out using an external database as storagenodes already connect to an external database. I would think that using docker for adding storage nodes might make some sense as you could put them all on one server and use volumes to mount disks from different sources.
However, the more virtualization and containerization you add, the more complication arises. Already once just on a virtual server you may not be able to use multi-cast imaging unless you’re able to add igmp snooping in your virtual networking. I don’t know if containers have that same limitation or other limitations that could be introduced.

This isn’t really a great answer I realize, and I apologize for that, but there’s a lot to consider with changing infrastructure.

Anyway, something you might try is to create a /opt/fog/.fogsettings file before installing and put in these settings

snmysqlpass='password'
snmysqlhost='remoteHost'
snmysqluser='fogmaster'
mysqldbname='fog'

Then try the installer, no idea if it would work, but something to try as far as using an external database.