@Sebastian-Roth said in Persistent Groups Not Working - FOG 1.5.9.235:

Could you please do me a favor and update your Ubuntu 20.04.1 - FOG 1.5.9 - MySQL 10.3.34 setup to the latest dev-branch (which does not have the fix included yet)?

Haha, that would not have triggered the issue because updating from 1.5.9 to dev-branch will not switch your DB table from MyISAM to InnoDB! Only new dev-branch installs are on InnoDB.

I did some extensive testing and it’s definitely the table engine InnoDB causing the initially reported problem. So it’s definitely good we got that fixed and from my tests there does not seem to be an issue with the new code, even on MyISAM tables. So I think we are good to go with this.

@RTOadmin Are those topics related? https://forums.fogproject.org/topic/16715/printer-assignment-problem

May I ask you to not do double/cross posts? I know we have not answered in more than a week but opening another topic is not going to help. No offense! Just want to give you a heads up.

@Foggy-0 I have done a test using a clean Ubuntu 20.04 install and FOG 1.5.9. Uploaded a Firefox MSI (56 MB) with no trouble at all.

Let’s see if we can figure this out for you. Create a PHP info helper file like this:

echo "<?php phpinfo(); ?>" > /var/www/fog/info.php

Then open the URL http://192.168.3.20/fog/info.php (put in YOUR server IP instead) and search for post_max_size. What is it set to?

Remember to delete that newly create PHP script afterwards.

@Scootframer said in Fog hangs while trying to upload:

[262168.127909] nfsd: peername failed (err 107)!
[262263.362858] nfsd: peername failed (err 107)!
[262524.491146] nfsd: peername failed (err 107)!
[262585.932952] nfsd: peername failed (err 107)!
[262592.077249] nfsd: recvfrom returned errno 104
[263814.772339] nfsd: peername failed (err 107)!
[264045.179522] nfsd: recvfrom returned errno 104
[264840.851890] nfsd: peername failed (err 107)!
[264957.591855] nfsd: peername failed (err 107)!
[265277.089716] nfsd: recvfrom returned errno 104

Yeah definitely restart your whole FOG server as suggested by @JJ-Fullmer as well.

@kalafina The fog-client is a 32 bit application as far as I know. So you might get around by installing the 32-bit Dell Command | PowerShell Provider v2.7.0 found here: https://www.dell.com/support/kbdoc/en-us/000177240/dell-command-powershell-provider?lwp=rt

@RTOadmin Please mount the partition, run ls -alR /mnt/... and post output here. With more eyes looking at this we might find if this is just a minor typo issue.

@premier Turns out this was a bug in the code. This is now fixed in latest dev-branch version. With the new official release on the door step your should update to 1.5.10 as soon as it’s out.

PS: If you’d kept up the topic and offered more information we might have been able to fix this way earlier.

@Jasper507446 Thanks for the details posted and your patients. Bug is found and fixed in latest dev-branch version. With the new official release on the door step your should update to 1.5.10 as soon as it’s out.

@Scootframer Do you get anything in the server logs?

dmesg | tail
tail /var/log/syslog /var/log/messages
journalctl -f

@pjv While the fog-client has an implementation for AD join and rename (see code) I am not sure this is working. The C# code actually calls a bash script (osxbind.sh) which I have no idea about.

@Scootframer So capturing an image has worked before just fine as we see from the images directory. It’s on a local LVM storage, XFS format. Does not look like something causing trouble in general.

What happens at this stage is simply a chmod -R 777 /images/a4bb6d84ebf4, so setting access rights to allow full access for everyone on this directory. I really have no idea why it would hang here. In the step “Preparing backup location” just before this one the directory is being created, which obviously does not hang or error out.

You might wanna try a debug capture (go to where you would schedule a normal task but in the last step you can tell to run in debug mode). Boot up the PC and hit ENTER twice to get to the shell. Then start the process by running the command fog and start stepping through it. Then just before the “Setting permission location” step you wanna stop the run via ctrl+c. Then run chmod -R 777 /images/a4bb6d84ebf4 and see if that’s returning or not.

@RTOadmin What does the file and directory structure in that new partition look like?

@Scootframer Please run the following commands on your FOG server console and post output here:

lsblk
mount

@george1421 said in Chainloading failed, hit ‘s’:

So if I had to point fingers, I would say its iPXE at the root of the issue, but the question is why, and only on this one hardware.

Maybe try a different iPXE binary as well as compiling the latest version (as suggested by George), like ipxe.pxe, in your dnsmasq config.

@Foggy-0 said in Snapin creation (size of file):

I modified post_max_size / upload_max_filesize / memory_limit to 4000M

The php.ini setting in question is post_max_size. Which config file exactly did you edit? I think there is more than one. The php-fpm one and probably one for php-cli as well.

service apache2 restart or even reboot all Fog

The php-fpm service needs a restart. But server reboot should do the trick as well.

@abulhol Any news on this?

@RTOadmin said in Boot pxe from partition instead of USB:

… and booted form it with the following error

How exactly did you tell the Mac to boot from that partition?

@george1421 said in Persistent Groups Not Working - FOG 1.5.9.235:

When I originally wrote this the whole action part of the script is done in mysql as a trigger. The FOG web site code doesn’t know this code exists, so to speak.

Sure enough but my thinking was this could be a problem mit InnoDB only which we do use as default since some time. But could be MySQL version causing this too. I will find some time to test soon.

I’m not sure I understand the change requiring on duplicate key in that a key field should not have duplicates such as with a hostid or groupid.

In most cases this is not neccesary. But for example when I did several tests in a row (removed the host from the group and re-added the host the INSERT without ON DUPLICATE KEY UPDATE would fail because the location association already existed - as it’s not removed when a host leaves the group. With the ON DUPLICATE KEY UPDATE added it’s all good. Same for the other INSERTs!

From the structure of the edits in the patch it looks ok.

Ok, thanks! Merging the code then.

@RTOadmin I have not done it myself but would say it should be possible. Just deploy to a test machine and manually play with a boot partition.

Maybe this article is of help to you: https://wiki.fogproject.org/wiki/index.php?title=FOG_on_a_MAC#Using_bless (just use bless to point to the iPXE binary on your disk)

@brakcounty Try out different ones, like intel.efi for example.