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.

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/

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

@Greg-Plamondon and @Clebboli are the Storage nodes associated to the same storage group?

For example:

Site 1 -> Default Group
Site 2 -> Default Group

Or are each storage node associated to their own Storage Groups?

The idea of storage groups is to spread the load of imaging. So if all storage nodes are part of the same storage group, then it makes sense the “jumping to different storage nodes within the group”.

While seemingly unexpected, the idea of jumping to other nodes within the same storage group is intended to balance the workload around as best it can. Sure this can probably be better handled, though I don’t know when I might get around to refactoring it. Just saying what I suspect might be happening.

@Clebboii said in Location Plugin - PHP Warning and Location Assigned Node not working:

PHP Warning: Undefined array key “REQUEST_METHOD” in /var/www/html/fog/lib/plugins/location/hooks/addlocationapi.hook.php on line 121

I’ve pushed an update to the dev-branch regarding this issue.

I don’t know if it will definitely fix it, but it should help prevent continued writing of this error.

As for the issue of slot and hopping, I’m not sure how I can simulate this issue. Is this a new issue or something that was noticed and we’re not really sure when it began and/or has always been there?

@shieldsj Can you please provide the exact error from the error logs? What version of FOG are you running?

I suspect the machine you’re attempting to capture the image from does not have an image assigned to it, but without really anything other than there was some error without any real context, not sure what else we can do to help currently.

@SotY The files of console.h/general.h/settings.h were updated 2 - 4 months ago. I don’t think anything here is the cause of the failure. I’ve attempted building and am seeing the same error.

This leads me to think something changed with ipxe code particularly surrounding USB_HCD_USBIO and efi built binaries. It seems the efi builder has a native compiler point for it’s own USBIO that’s being constructed separately from the “common” source.

If you just build the binaries without the USBIO configured, does it break things? I know you found a fix and wanted to try it, but it seems mcb30 (main developer of ipxe) made a change that seems to make the usbio drivers act differently in the past. What those changes were, I do not know at this time.

I am more surprised, in my quick review of things, that this even worked before as the components I see erroring haven’t change significantly.

If I change the usbio_driver line to efi_usbio_driver in the drivers/usb/usbio.c file, and re-run the builder, things build successfully. (Including the ncm–ecm-axge.).

If that works, I can put my diff file and copy it with the build script but I’m scared something I’m doing in the driver/usb/usb.c file might be unintentionally making things worse (not better) even though I’m getting successful builds now.

@sideone No worries. That just let’s us know in your specific case at least, it’s not booting in UEFI mode at least for NIC devices, so thank you!

@sideone THis issue seems completely different from the context of this. I understand, or at least believe the reason this was asked here is because of the “Boot Loop”? portion?

In either case:

If you want to see what I mean, just create an empty file in /tftpboot called autoexec.ipxe (sudo touch /tftpboot/autoexec.ipxe) and the error of “autoexec.ipxe” will disappear. It will not fix the issue you’re seeing, but this message is not, itself, an error. Just the last thing that happens, if I 'm reading the clues correctly.

Do you know what type of NIC the machine that sticks for 5 minutes is using? If it’s realtek or intel, you could try the realtek.efi or intel.efi tftpboot file?

@aurfalien Assuming this is a legacy machine, undionly tries to use the native undi driver of the machine, but you can try other drivers:

ipxe.kpxe might be a good startingpoint and contains more direct drivers for a bunch more devices?

@Small0145 Sure, but it still seems like the golden image had this issue. How it got there I don’t know. I would suggest attempting to boot windows, perform the chkdsk/scandisk as needed. Then shutdown (may need to re-sysprep) after running this command. Windows 11, to my knowledge, can be a little bit strange sometimes.

@Small0145 powercfg /h off

Most of the time, the reason people see this is “shutdown” goes into a special mode called “Fastboot” which works similarly by flipping the dirty bit on the drive.

The command I posted here should prevent “fast log” so when you shutdown, the machine ACTUALLY powers off without any dirty bit.

@skyhawk3355 FOG has been able to be loaded into 256mb of ram for quite some time.

It was originally configured for 128MB of ram, but that was in 2007.

If we know how much RAM is on the actual machine?

I believe all our kernels and init need at least 200mb of ram to operate.