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/

@robertkwild for that particular fog server, correct. Once enrolled it’s good.

@Paladin1 Thanks, that explains the registration error. Registration reads the machine’s disk, so it needs a disk attached. With no disk it stops with that message every time. That is expected, so you do not need the debug task.

For your question: neither. Do not reinstall anything yet.

The BIOS boot mode on this machine applies to both the network boot and the installed OS. Your image is a UEFI install, so this machine has to network boot in UEFI too. We can try a different iPXE file for UEFI that loads its own network driver. That can avoid the firmware error.

On the FOG server:

1. Edit /etc/kea/kea-dhcp4.conf.
2. In the classes FOG-UEFI-64-1, FOG-UEFI-64-2, FOG-UEFI-64-3 and FOG-Surface-Pro-4, change "boot-file-name": "snponly.efi" to "boot-file-name": "ipxe.efi".
3. Run sudo systemctl restart kea-dhcp4-server.
4. Set the target BIOS back to UEFI and network boot it.

Tell us if you get the FOG menu or the same ASSERT. If it fails, change the file back. A re-run of the installer also puts snponly.efi back.

@Paladin1 Thanks, that answers it.

UEFI: Legacy boots and UEFI does not, so the ASSERT is the XPS 8400’s own UEFI firmware. FOG and iPXE cannot fix that. Use Legacy boot for this model.

Menu timeout: In the web UI, go to FOG Configuration > iPXE General Configuration. Set “Menu Timeout” to a larger number of seconds. The default is 3.

Registration error: “Could not determine a suitable disk automatically” means the registration found no disk at that moment. Your capture on the same machine did find a disk, so I need a little more:

• Does registration fail every time, or did it fail once?
• In the BIOS, what is the SATA mode: AHCI, RAID, or ATA/IDE?
• Please run a debug task on that host: Hosts > (the host) > Basic Tasks > Advanced > Debug. At the shell, run lsblk, then dmesg | grep -iE 'ata|sd'. Post a photo of both.

@robertkwild To be clearer on the delete case:

• The key stays. It lives in the laptop’s firmware, so deleting the host in FOG does not remove it. You do not need to enroll again.
• Deploy works without the host. “Deploy Image” on the PXE menu shows for unregistered machines. It asks for your FOG login and the image.
• Capture needs the host. You schedule a capture from the host’s page, so register the machine again first (Quick Registration, one boot).

@robertkwild Glad it’s all showing now.

You need enrollment only if Secure Boot stays ON in the machine’s firmware.

With Secure Boot on, the firmware runs only what it trusts. Out of the box that means Microsoft-signed code. The FOG kernel (FOS) is signed with your FOG server’s own key, which the machine does not know. Enrollment adds that key to the machine’s trusted list. After that, the machine boots FOS, so capture and deploy work with Secure Boot left on.

With Secure Boot off, the machine runs anything, and you can capture and deploy without enrolling.

So the choice is:

• Enroll once per machine and leave Secure Boot on. The key lives in the firmware, not on the disk, so a reimage does not remove it.
• Turn Secure Boot off for imaging and back on afterwards. That is a trip into the BIOS on every machine, every time. On a BitLocker machine, changing the Secure Boot setting can also trigger a recovery key prompt.

@robertkwild Good progress. The server sends the full kernel (200 11063696), and registration booted FOS, so the earlier timeout was a one-off. If it comes back, post the screen and the access log line from that moment.

The empty Secure Boot fields on the host page are expected. The “Enroll Secure Boot Key” menu item enrolls the key in the laptop’s firmware through MokManager. FOG is not part of that step, so nothing reports back to the server.

Two ways to fill them in:

• Let FOS check and record it. On the host, create an “Enroll Secure Boot” task and PXE boot the laptop. FOS sees the key is already trusted, enrolls nothing, and records the state, the date, and the certificate fingerprint.
• Type it in. Set “Secure Boot Enrolled” to today’s date and “Enrolled Via” to mok, then click Update. mok means a person confirmed the key in MokManager, which is what you did.

I’d use the task, because it checks the key instead of trusting a typed value.

@robertkwild The enrollment step worked. This new error is a network timeout, not Secure Boot.

4c0a6092 means the server never answered the kernel (bzImage) download. iPXE checks the Secure Boot signature only after the download finishes. So this error says nothing about the key yet.

Please run these two commands on the FOG server and post the output.

First, check that the server can send the kernel at all:

curl -s -o /dev/null -w '%{http_code} %{size_download}\n' http://10.110.10.60/fog/service/ipxe/bzImage

Then try Quick Registration on the laptop again, and right after it fails, run:

sudo grep bzImage /var/log/apache2/access.log /var/log/nginx/access.log /var/log/httpd/access_log 2>/dev/null | tail -n 5

If the log has no line from the laptop’s IP, the request never reached the web server. If it has a 200 with a small byte count, the transfer started and then dropped.

To answer your earlier question: once a Secure Boot task boots past bzImage into FOS, the key is enrolled. If it were not enrolled, you would get a security error after the download, not a timeout.

@robertkwild No, only need to enroll if you want to use Secureboot (after enrollment)?

@robertkwild Good, that screen is MokManager, so the fix worked.

1. Pick the last entry, iPXE. That is the network copy of the key.
2. Pick MOK.der.
3. Optional: View key 0 shows the certificate. Check it names your FOG server, then press a key.
4. Pick Continue, then Yes.
5. Pick Reboot.

Do not wait on these screens. MokManager reboots on its own if it sits idle.

After the reboot, PXE boot as normal. A Secure Boot task should now load the kernel.

@robertkwild Thanks for the screenshot. That error is a bug in the installer, not in your DHCP options.

020c618f means the FOG web server answered HTTP 401 for mmx64.efi. On a fresh install, the installer copies MokManager into the web folder before it downloads the Secure Boot files, so mmx64.efi is never there.

To fix it now, run the installer one more time. The second run finds the downloaded file and copies it. Then pick “Enroll Secure Boot Key” again.

To confirm before you re-run, check that this file is missing:

ls -l /var/www/html/fog/service/secureboot/mmx64.efi

Tracked in https://github.com/FOGProject/fogproject/issues/1868.