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/

Hi @efbCREED — a couple of things are going on here, and the good news is the behavior you’re seeing may not be broken at all.

First, your capture is filtering out where the boot filename actually lives.

Because you’re using pxe-service= menu entries in proxy mode, dnsmasq does the handoff in two steps:

1. The initial ProxyDHCP offer on port 67 carries the PXE menu (in the vendor-encapsulated options) and a boot-server list — it deliberately does not include the boot filename (option 67). That’s exactly the “four handshake-y parameters” you’re seeing.
2. The client then sends a Boot Server Discover and the actual filename comes back on UDP port 4011.

Your filter was port 67 or 68, so it never captured 4011 — which is very likely where the file is (or should be) going. Re-run with:

tcpdump -i eno1 -v port 67 or port 68 or port 4011

That will tell us whether the filename is being served on 4011 and the client just isn’t completing the exchange, or whether it never gets there.

Second, I’d simplify the config. Your file mixes two different handoff mechanisms (dhcp-boot and pxe-service), and the four dhcp-vendorclass lines you defined are never actually referenced — the pxe-service lines use dnsmasq’s built-in arch keywords instead, so those vendorclass lines aren’t doing anything.

The config we recommend for proxyDHCP drops the menu approach and matches on architecture directly. This puts the correct filename right in the port-67 offer (so it’s trivial to verify with the tcpdump you’re already running) and chains iPXE → FOG’s boot.php once iPXE is loaded:

# /etc/dnsmasq.d/ltsp.conf   (adjust <server-ip> throughout)

port=0
log-dhcp
tftp-root=/tftpboot
dhcp-range=<server-ip>,proxy
dhcp-no-override

# Detect the client's PXE architecture (DHCP option 93)
dhcp-match=set:bios,option:client-arch,0
dhcp-match=set:efi32,option:client-arch,6
dhcp-match=set:efibc,option:client-arch,7
dhcp-match=set:efi64,option:client-arch,9

# Detect when iPXE itself is asking (DHCP option 175)
dhcp-match=set:ipxe,175

# Serve the right network boot program per architecture
dhcp-boot=tag:bios,undionly.kpxe,,<server-ip>
dhcp-boot=tag:efi32,ipxe.efi,,<server-ip>
dhcp-boot=tag:efibc,ipxe.efi,,<server-ip>
dhcp-boot=tag:efi64,ipxe.efi,,<server-ip>

# Once iPXE is running, hand off to FOG
dhcp-boot=tag:ipxe,http://<server-ip>/fog/service/ipxe/boot.php

A few notes:

• Use undionly.kpxe for BIOS, not .kkpxe. The kk variant is only needed on the handful of older NICs that need the UNDI stack kept resident — undionly.kpxe is the right default.
• The tag:ipxe line must come after the per-arch lines. dnsmasq applies the later match, so this ensures a machine that’s already running iPXE gets sent to boot.php instead of being handed the .efi again (which would loop).
• Make sure those files actually exist under /tftpboot (undionly.kpxe, ipxe.efi) — they ship with FOG, but worth confirming.

After you drop this in, restart dnsmasq and PXE-boot a client with the tcpdump above running. You should now see the filename land in the port-67 offer for the client’s architecture. If you still get nothing, paste that full capture (67/68/4011) here and we’ll take it from there.

Which firmware is the client — legacy BIOS or UEFI? That narrows down which line above should be firing.

@Alun Thank you and added to documentation and within the installer to try to more cleanly account for this.

@jmeyer So this issue is fixed on the latest now is what you’re saying?

@jmeyer Can you please get me some more information?

1. Is /etc/kea a real, populated directory? Right owner/perms?
   ls -ld /etc/kea; ls -la /etc/kea

2. What’s the OS, and is a MAC layer confining kea-dhcp4?

Debian/Ubuntu:

cat /etc/os-release | head -2; aa-status 2>/dev/null | grep -i kea; dmesg 2>/dev/null | grep -i 'apparmor.*kea' | tail

RHEL/Fedora:

cat /etc/os-release | head -2; getenforce; ausearch -m avc -ts recent 2>/dev/null | grep -i kea | tail

Plus the tail of the install error log around the DHCP step (/opt/fog/log/error_*.log or wherever the run pointed $error_log).

@jmeyer I’m trying ot take a look, but kea is a new thing since isc-dhcp has been deprecated and is nearing its potential EOL.

So we moved toward KEA as the dhcp server, and while it has been added, I can attest I don’t have enough methods of testing.

I suspect the issue is related to different OS baselines:

(e.g. Fedora/RedHat stores config in /etc/kea, but Debian/ubuntu is deciding to store in /etc/kea-dhcp-server - or something I don’t know, just trying to show the issue)

I’m working on trying to validate in the background.

@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.

@Cpasjuste if you have github you likely have ability to have copilot to help read the repo and help you build the README if you find it lacking.

Just thoughts, but thanks for this.

@kratkale What you see in the text field are place holders, just example views, if you were to hit update/save, those things aren’t what will be set.

THe reason you see “(varies)” is because the hosts in the group have some things where their host Primary Disk is set, but not all hosts have the same values.

As for your odd snapin issues please try these commands on the Database:

delete from snapinAssoc where saSnapinID <= 0;
delete from snapinTasks where stSnapinID <= 0;

As for the domain join issue:

The “captured” host should not be joined to the domain until after the image has been captured.

The error you were seeing was joining domain “Code = 87”

That is not FOG writing an erroneous error, but rather the error from the Domain controller directly.

This may mean your environment is expecting to be set to a specific OU within the domain?

https://forums.fogproject.org/topic/11971/unable-to-join-domain-error-87

This is an old (albeit similar) topic with the same type of error you had seen so maybe it’s fix may help your fog client as well?

This, of course, isn’t strictly necessary, since your snapin method appears to be working anyway.

As always, please update to the latest and greatest as it should help with the prevention of odd jobs just getting created as well. After you clean up things of course.

Thank you!

@vanfifty1 I feel like this was something you produced on GIthub as well, is this correct?

I’m just wanting to link things. As it’s usually usually me doing all the development now-a-days again, (but thank you AI) I can try to have Claude take a look.

I’m currently working on 26H1 update download at least thru a vm, but just wanted to give a heads up.

@kratkale Is it possible DHCP IPs are all used up and the device that fails doesn’t have a proper IP address to be able to even communicate with your FOG Server?

It is very odd that one machine works where another seems to fail.

Nope, because 401 isn’t the same as that’s a client side error saying “we failed to prove we can talk to the fog server.”