@Matthieu-Jacquart Ok, new inits are ready. Download 64 Bit and 32 Bit and put those in /var/www/html/fog/service/ipxe/ dir on your FOG server. Probably good to rename the original ones instead of overwriting.

As well you need to check the RAM SIZE option in FOG configuration, FOg settings. Need to be 275000 with the newer inits.

With those I hope you won’t have the random issues anymore.

@Matthieu-Jacquart I have tested a fair bit and it seems like some or most of the issues you reported here seem to be related to the problem we are tracking down in another topic as well. I am testing fixes at the moment.

But there is still one thing that doesn’t make sense for me. Your d1.fixed_size_partitions being set to :2:3 just doesn’t add up for me. My guess is that with reverting back to 1.5.5 you are still using the “old” inits that use label based detection of fixed partitions.

I will let you know as soon as the new init’s are ready so you can test!

@JGwinner You might wait a couple more days till we finally release FOG 1.5.7. The changes will bin in that.

By the way, people have installed FOG on Raspbian. It’s not that fast hardware but it does work. But I have to admit that we have not tested the installer in a while and it might through errors on current Raspbian…

@JGwinner Debian 10 was only released a couple of days ago and we had to fix some things in the installer. This is in the so called dev-branch and not an official FOG release yet. You can install on Debian 10 like this:

sudo su -
git clone https://github.com/FOGProject/fogproject/
cd fogproject
git checkout dev-branch
cd bin
./installfog.sh

Hint: As mentioned in the other topic (you probably did not see this?!) you shall not run the installer in a sudo environment but a proper root shell! (reference)

@TBCS Are all the Yogas in a specific part of your network (one switch/room/subnet)? It’s kind of unlikely this is caused by the Yogas being UEFI systems. What could be the case is that the network driver for the NIC used (probably an external adapter, right?) is kind of buggy and not allowing for a proper NFS connection. But as we check network connection on bootup it’s also very unlikely.

I guess George is on the right track here. Your network seems to not handle the default 0.7 second timeout well and therefore you see random failures. Try manual mounting as George suggested a couple of times in a row to see how often it fails.

mkdir /testfs
mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs
umount /testfs
mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs
umount /testfs
...

Then add the timeout option as well and see if it’s doing any better.

mount -o timeo=10,nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs
umount /testfs
mount -o timeo=20,nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs
umount /testfs
...

@awellis Couldn’t get to look into this until now. Just too many other things needed attention.

I’ve just tested printer management in Windows 10 (though 1803!) again and from my point of view it works well. Not saying that there is no problem but seems like I am not able to properly replicate what you see so far.

In the picture I see as printer driver you have C:\prn...inf and I am wondering if the INF file is really located in that place?! As well the printer name in the picture does not match the one we see in the logs. Just trying to make sense of this.

The interesting thing I see in the log from the computer you seem to not have the printer added:

 7/3/2019 11:54 AM Client-Info Client Version: 0.11.16
 7/3/2019 11:54 AM Client-Info Client OS:      Windows
 7/3/2019 11:54 AM Client-Info Server Version: 1.5.5
 7/3/2019 11:54 AM Middleware::Response Success
 7/3/2019 11:54 AM PrinterManager PrintUI return code = 0
 7/3/2019 11:54 AM PrinterManager PrintUI return code = 0
 7/3/2019 11:54 AM PrinterManager PrintUI return code = 0
 7/3/2019 11:54 AM PrinterManager PrintUI return code = 0
 7/3/2019 11:54 AM PrinterManager Adding printers
 7/3/2019 11:54 AM Printer Adding: 1064-printer
 7/3/2019 11:54 AM PrinterManager PrintUI return code = 0
 7/3/2019 11:54 AM PrinterManager Restarting spooler

Here it calls the printUI command several times. My guess is that it removes other printers here. So I am wondering which printer setting you have in that host’s settings? Edit the host and go to the “Printers” tab at the top. Is it set to “FOG Managed Printers” or “Only Assigned Printers”? While it should work in both cases I am just wondering about your setting?!

Please try the following: Open the Windows Services view (start menu type “services.msc”) and stop FOGService. Now open the Print Management dialog (start menu type “Administrative Tools” -> Print Managment) and manually delete printer and driver and make sure it’s all gone (hit F5…)! Now back to the Services start FOGService again and keep an eye on the Print Management as well as the FOG log (I use powershell command: Get-Content -Wait C:\fog.log). Does it add the printer and tell so in the logs?

Copy & paste the logs here again. Possibly I need to add more debug output at some point.

@fry_p On first read this doesn’t sound related to me but we’ll see. I know you are very busy right now but would you mind opening a new topic with this one as well and post more information there? Picture of the error would be great!

@ckasdf Sorry for the long delay. Things are piling up here and we can’t work through it all in time.

You are right that results should be visible. I just pushed a change to the scripts so that the output of the command checking the disk is not suppressed. As well I added that users need to press a key to proceed. It’s still not perfect but at least this will help people to see the results.

Would be also great to have that in the reports section of the web UI but I fear we don’t have the time to implement that right now.

@jmeyer Sorry for the late reply. Couldn’t get to this any earlier. Is this still an issue for you? I have had a look at the code but can’t make sense of this yet. I suppose we’d need the start of the output - the first “Attempting to check in” output line to understand this.

But looking through it I have a feeling that maybe one of the settings is wrong in your setup. Please connect to the database and run the following query:

shell> mysql -u root -p
Password:
...
mysql> use fog;
...
mysql> SELECT * FROM globalSettings WHERE globalSettings.settingKey IN ('FOG_DEFAULT_LOCALE', 'FOG_HOST_LOOKUP', 'FOG_MEMORY_LIMIT', 'FOG_REAUTH_ON_DELETE', 'FOG_REAUTH_ON_EXPORT', 'FOG_TZ_INFO', 'FOG_VIEW_DEFAULT_SCREEN');
...

Get the full output and post here (as text or picture).

@Cheetah2003 Just in case you come along this alter on and wonder. While you are right that it’s not great that this can happen I reckon it’s very rarely the case anyway. We have highly generalized SQL queries that do the table updates (like adding the MAC) and it’s not easy to think about just any situations where people do strange things.

We have database maintenance commands in the wiki which do clear the problem if you have created it: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL#Database_Maintenance_Commands

....
DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC`);
...

This line will clean out the lost/hidden) host entry for you.

Also another suggestion: Make this stuff work on a multi-homed server. That would be really great.

There are so many different scenarios around that it’s nearly impossible to make this generally possible. People would use this with different subnets across routers, also use VLANs and all that. So I think if we add multi-homing for one specific scenario we make three people happy but still while putting in a lot of work this won’t work for the other 20 guys wanting a kind of different multi-homed setup.

We don’t encourage people to do multi-homed but still we try to help people set this up under some circumstances.