I know I’ve been out of this for a little bit. I check in here or there, but just been extremely busy.

I don’t want to stop contributing, I just am taking time for myself after my workly duties.

I have to give a big gratitude and thanks for everyone here trying to help out whether by code, by helping the rest of the community, or documentation.

@Sebastian-Roth I know you’re busy but you’ve kept the project rolling even with the minimal availability you have. Thank you.
@george1421 I’m sure you’re busy, but I still see you posting and helping where possible and amenible. Thank you.
@Wayne-Workman I know you’re helping where you can as well. (Of course I can’t exactly post everybody because I’ve been busy and honestly not keeping up with the forums as much as I probably should.)

@everyone Thank you. Thank you for still believing in this project. We’re doing the best with what we have. Please understand in we’re lacking, it’s most likely unintentional. I know I’m just busy.

https://news.fogproject.org/fog-1-3-5-and-client-0-11-11-officially-released/

https://news.fogproject.org/fog-1-5-0-rc-11/

TLDR; Rerun the fog installer if you have lost “Database Connectivity” to your fog server, or run the ALTER USER syntax shown below.

So Ubuntu 16, among others I suppose, enable a “security updates” to be applied automatically as a “default” to things. Why, well it makes it simpler to ensure your Ubuntu systems are in compliance and patched for any potential exploits. This causes unknown and unexpected issues.

I figured it’d be a safe thing to express that there could be problems (as many of you have already experienced) that when these updates go up (with or without your knowledge) it can break functionality in unexpected and inopportune ways.

The quickest fix is to simply rerun the fog installer which should correct the problem.

As a note, it seems this problem is specific only when the mysql account is the 'root' user AND the password is blank.

The “fix” if you must do it manually is to open a terminal and obtain root:
Super (Windows Key) + T then sudo -i (in most cases).

From there, open mysql with mysql -u root

NOTE: MySQL MUST be run with ROOT.

Run:

ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY ''; AND
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';

It’s okay if one of them fails. This is going to fix Most people’s issues.

I would highly recommend removing the unattended-upgrades as many of these “sudden” issues came as a security patch ubuntu pushed out. By default Ubuntu typically set’s this for you as enabled and it can cause havoc on you as you (the admin) may not have “done” anything.

To prevent this problem from happening in the future you could run:

apt-get -y remove unattended-upgrades (AS Root again).

FOG is still actively being developed. It’s not necessarily readily apparent, but we can assure you things are still being worked on. These updates may not be communicated in a way that everybody just knows, but can easily be seen if one were to look at our repository site.

Between our own schedules and lives, we can get very busy. We try to keep things updated and help out on the forums even during lull periods. This might mean we aren’t pushing an RC or release as frequently. It may mean we’re working on other things for the project, such as can be seen if looking at our github site.

Our forums are heavily active, and this should point as an indicator to our “status” as well.

If anybody would like to see an increase in developers donating their time to making this free software, consider donating either with monetary support or by spending personal time to help with development.

FOG is an open source project - it’s even in the name. It is driven by people donating their time and resources. The releases of FOG revolve around when developers can spare a few hours throughout the week. Sometimes that will mean releases will be further, sometimes that will mean releases will be faster. That’s just the nature of our project, and many other open source projects.

Hey everybody,

I know you see me here on occasion from time to time. Life decisions have made it more difficult for me to do things I would normally be doing. Rest assured, I am still around, and while I’m not quite as active as I was in the past, it’s not because I don’t want to be.

I had to move, and as part of that I have none of my normal development stuff readily available. Part of the move made me not have a laptop, until today.

I need to setup my dev environment again, so it may take a little bit, but I will be back up.

https://news.fogproject.org/fog-1-5-10-41-officially-released/

While this maybe spur of the moment, it should officially release 1.5.10 with all relevant bug/security fixes encapsulated (among a few other features.)

This has brought a new methodology of releases in that bug/security releases should be done much more regularly.

dev-branch, historically, was a place where new development occurred (hence its name) but over the last couple of years or so it’s mainly been a bug/security thing, not really a true development approach.

This is OKAY, in my head. Why:

Well we have the master branch which is the ‘baseline’ of a verions. We have the dev-branch, which allows us to work on bugs/security issues. We have the working branches for what will eventually become master. Working is our “dev branch” but keeps proper seperation of things in my opinion.

Basically:
master -> basis for dev-branch (which merges into stable on a regular cadence - still being worked out)
working -> basis of forward development

So we effectively have:
production
staging
development well seperated.

THis may mean on the regular automated releases, no announcement or news article will be created, and I think that’s okay.

Hopefully exciting we have a release after 1.25 years

Thank you!

That’s correct. The main reason fog is constantly moving forward is because the codebase is improved upon. Major bugs tend to be addressed for the next release. We don’t do an LTS because there’s really two main people working on fog in a consistent manor. Those two are @Joe-Schmitt and myself. Debian and Libreoffice have the team too be able to perform such a feat. Their product is Opensource but they have an employment team which can afford them that luxury. FOG has a team but we make no money and as such are required to work full time jobs. We work on FOG in our free time. I’ve had the ability to even work on it from work because we used the software.

Maintaining many different versions is difficult. And we don’t have a support team. WYSIWYG and I think we’ve done pretty well on support, even if we don’t have the ability to do dedicated support for our product. 1.5 was a major step toward modernizing the GUI. 1.6 will vastly improve on this. It was only recently we kind of came up with a road map on how best to proceed. Of note, 1.5 will be maintained until 1.6 is released. 1.6 is focused on making he GUI much more modern. 1.7 will be focused mostly toward fixing and refactoring the FOG client. 1.8 will focus on making the FOS system more modular and usable. I don’t know yet for 1.9. 2.0 will bridge the gap for our rewrite based on the work from 1.5 and up. While we do plan to try to do backports where possible, it’s much easier to ask people to update to the latest version than it is to try to maintain many different versions with backports in mind. At least for what FOG does.

I doubt this will appease anybody, but it’s what I think needs to be said. We are working hard and provide support for our product as best we can. The community makes fogs support system, I think, one of the best around. Add to that and you can almost always have a developer working side by side to help and fix issues as they come up, I don’t think it’s unfair to ask users to update to a specific version. Even if there are bugs, we will always try to correct what we can, when we can. (And normally it’s a pretty quick turn around).

I’m not perfect and I’ll give you that. We don’t even have a test suite to know if things are working as intended. We have to rely on the community and suggestions are great, just understand our answers won’t always be what people want to hear.

https://news.fogproject.org/fog-1-4-0-officially-released/

https://news.fogproject.org/fog-1-4-4-officially-released/

@rdr You found a real bug. Sysprep is not needed, and it would not have helped.

Cause: the image carries the agent’s key and certificate from MMF-LAB2-00.
The agent compared the machine’s SMBIOS identity with that key only when it
had no certificate. A deployed copy has one, so every PC connected as
MMF-LAB2-00 and took its name.

fog-agent 0.1.7, released today, makes the check on every start.

To fix the PCs you already deployed:

• Go to FOG Configuration > FOG Settings > General Settings and set
  FOG_AGENT_DESIRED_VERSION to 0.1.7. Every enrolled agent updates itself,
  including each PC that thinks it is MMF-LAB2-00.
• After the update, each PC sees that it is not MMF-LAB2-00, makes a new
  key, and enrolls as itself. FOG matches it to its host by MAC.
• If FOG deployed to that host in the last 24 hours, the enrollment is
  approved automatically. If not, approve it under Hosts > Pending Agents.
  The agent then renames the PC to its name in FOG.

Please post back whether the names come right.

@Balage80 Thanks for confirming the enrollment fix.

UEFI boot: I think the cause is two new lines in default.ipxe. They read Secure Boot state from the firmware. iPXE reads it by stepping through every firmware variable, and some firmware never ends that list, so iPXE hangs there.

Please test this: take the new 979-byte default.ipxe and delete only these two lines. Keep everything else.

param secureboot ${efi/SecureBoot}
param setupmode ${efi/SetupMode}

Does UEFI boot with that file? Please also post the make, model, and BIOS version of the machine. Note that re-running installfog.sh writes a new default.ipxe, which replaces a manual edit.

Pending MACs: these are not related to default.ipxe. They come from the legacy FOG Client’s Host Registration module. That module reports every adapter Windows sees, including Wi-Fi, Bluetooth, and virtual Wi-Fi Direct adapters. FOG stores each unknown MAC as pending, up to FOG_QUICKREG_MAX_PENDING_MACS per host (default 4). iPXE cannot see those adapters. You can delete the pending MACs. To stop new ones, add MAC fragments to FOG_QUICKREG_PENDING_MAC_FILTER (comma separated), or turn off Host Registration.

@rdr the fog agent is brand new and is attempting to modernize how the client did things. I wasn’t fully ready for people to be testing it live quite yet, though glad to have people doing so.

I suspect the identity.json is from that of the original machine and it’s using that as the marker for all the machines you’ve deployed to. Since that identity was for that machine, all machines are currently thinking they are that machine.

@Balage80 This is fixed in working-1.6 (PR #1755).

The agent routes were being blocked by the FOG_API_ENABLED setting. With the API turned off, every /fog/agent/v1/ request got a 308 redirect to the login page, so the agent could never enroll. Now the agent routes work whether that setting is on or off.

To update: pull working-1.6 and re-run installfog.sh. After that, you can turn FOG_API_ENABLED back off if you want. Enrollment still needs an approval in the UI.

The legacy FOG Client 0.13.0 problem has a different cause. If those clients still loop on requestClientInfo after the update, please post the fog.log from one of them.

@Balage80 Can you please make sure FOG_API_ENABLED is set/ticked in your FOG UI:

FOG Configuration -> FOG Settings -> API System -> FOG_API_ENABLED

Hi Rahman,

Thanks for the report. Both problems are fixed in the working-1.6 branch.

1. A username can now be an email address. The user form accepts “@”, and mixed-case names from the identity provider save correctly.
2. Delete no longer asks for a password. It asks you to confirm, and the button shows how many items will be deleted. The FOG_REAUTH_ON_DELETE setting is removed.

To get both fixes, update to the latest working-1.6 and re-run the installer. You do not need a plugin update. Until you update, you can turn off FOG_REAUTH_ON_DELETE in FOG Configuration to stop the password prompt.

@azm9s Good that legacy boot works now. For UEFI, your first tcpdump already shows one problem. It stops UEFI clients on every board, with Secure Boot on or off.

First: remove option 60 from your Windows DHCP server.
Your DHCP offer contains option 60 = “PXEClient”. UEFI firmware reads this as “this server is a PXE boot server”. It sends a second request to 192.168.65.35 on UDP port 4011 and waits. FOG does not listen on port 4011, so the firmware stops before it downloads any file. That is why no boot file worked. Legacy network boot does not do this, so legacy works. You only need option 60 if WDS runs on the same server as DHCP.

Second: set option 67 for UEFI to secureboot/snponly-shimx64.efi.
Your version (1.5.10.2253) installs this file. Check that it is there:

ls /tftpboot/secureboot/

It is signed by Microsoft, so it boots with Secure Boot on or off. You do not need to disable Secure Boot. Do not point option 67 at secureboot/ipxe.efi directly. With Secure Boot on, the firmware rejects it. If the menu loads but the network does not start, use secureboot/ipxe-shimx64.efi instead.

To keep legacy and UEFI working at the same time, use Windows DHCP policies. Vendor class PXEClient:Arch:00000 keeps your current legacy file, and PXEClient:Arch:00007 gets the file above:
https://docs.fogproject.org/en/latest/kb/how-tos/bios-and-uefi-co-existence

If UEFI still fails after these two changes, run this on the FOG server while the PC boots, and post the output:

tcpdump -i eth0 -n -vv ether host fc:9d:05:76:7c:00

@kratkale

Multicast. The version number does not show what fails. Queue a multicast task, start the clients, then post:

• the output of tail -n 40 /opt/fog/log/multicast.log
• a photo of one client screen

–public-web-cert. Correction to my last reply: this flag helps only when your web server sends a complete, publicly trusted chain. The flag removes FOG’s own CA from the check, and curl then uses the system trust store. That check also failed. So the system store cannot verify the chain your web server sends. Run this on the FOG server and post the output:

openssl s_client -connect fog.mm.htlwien10.at:443 -servername fog.mm.htlwien10.at </dev/null 2>/dev/null | grep -E '^ *[0-9]+ s:|^ +i:'

It shows who issued the certificate and which certificates the server sends.

Power management. The server sends the schedule in the same format as 1.5. The FOG Client runs it on the PC, at 18:55 PC time. Check that Power Management is enabled in FOG Configuration > Service Configuration and on the host. Then post C:\fog.log from one PC. The lines that start with PowerManagement show whether the client got the schedule.

Snapin after cloning. No C:\fog.log means the FOG Client service has not run yet. The server only queues the snapin. The client starts it. Add net start FOGService after the client install line in SetupComplete.cmd.

All Snapins. FOG shows All Snapins when a host has more than one snapin queued. The Active Snapin Tasks tab lists each snapin by name. The “/ of (/min)” text in the Progress column is a display bug. It is fixed in 1.6.0-beta.5346.

@kratkale That’s not a bug and it’s not stopping you — press Enter and the upgrade will finish.

What it’s telling you: your server presents a certificate that FOG didn’t issue (a real one for fog.mm.htlwien10.at, from acme.sh/certbot or your school’s CA). During an upgrade the installer makes a few HTTPS calls to itself, and it verifies those against FOG’s own CA. Your certificate doesn’t chain to FOG’s CA, so those calls fail. The only thing you actually lose is the automatic pre-upgrade database dump.

So take a dump of the fog database yourself first, with mysqldump or from phpMyAdmin — whichever you normally use. Then press Enter and let the installer run.

To stop this happening on every upgrade, point FOG at the certificate you are actually serving. Symlink both halves of your ACME pair into FOG’s leaf directory:

/opt/fog/pki/web/leaf/.webLeaf.pem  ->  your fullchain file
/opt/fog/pki/web/leaf/.webLeaf.key  ->  its matching private file

FOG checks whether those resolve outside its own PKI directory. Once they do, it treats the certificate as externally managed: it stops regenerating it, and it stops replacing your system trust store when it calls itself — so verification just works. Running the installer with --public-web-cert declares the same thing up front.

Once you are through you will be on 1.6.0-beta.5332 or newer, which carries the multicast, snapin-labeling and State column fixes. Let me know whether multicast starts for you.

Thanks for the detailed writeup — there are two separate things going on here, and one of them is our bug.

The Booting from SAN device 0x00 ... Input/output error line is on us. sanboot --drive 0 means “the first disk carrying \EFI\Boot\bootx64.efi” under UEFI, but under BIOS iPXE hands that number straight to int13, where 0x00 is the first floppy and hard disks start at 0x80. We’ve been emitting the same exit string for both platforms since July 2024, so every legacy client opens its exit by trying to boot a floppy that isn’t there. Fixed in https://github.com/FOGProject/fogproject/pull/1741 — BIOS clients will go straight to 0x80 again.

To be clear though, that isn’t what’s stopping you: your log shows it does fall through to 0x80, so your failure is after that point. The fix just removes a misleading error that sends people hunting a disk fault that doesn’t exist.

Two things would help me nail down what’s left:

1. For the legacy-mode “won’t boot to disk” part — what was the image captured from? If the source machine was UEFI/GPT, the disk you deployed has an ESP and no MBR boot code, so BIOS sanboot --drive 0x80 has nothing to jump to even though the firmware’s own boot menu may still find and boot it via its UEFI path. That would explain “direct hard drive boot works, PXE-to-hard-drive doesn’t” exactly.

2. For the UEFI immediate-reboot — a script containing only echo and sleep rebooting means iPXE itself is dying before anything we generate matters. Nothing FOG produces is in that path yet. Can you grab a stock ipxe.efi from https://boot.ipxe.org/ipxe.efi, drop it in /tftpboot, point DHCP at it and boot the 5060 with the same minimal autoexec.ipxe?

• Stock also reboots → it’s the 5060’s firmware, and legacy mode is the answer for that box.
• Stock survives and ours doesn’t → it’s our iPXE build config, and I want an issue open on it. We pin our own iPXE fork and overlay three config headers, and we’ve already had one console regression out of that recently, so it’s a real possibility.

That one test tells us which side of the line this is on.