@Matthieu-Jacquart said in Error trying to restore GPT partition tables. Exit returned code 4:

For lastlog command it returns an error : No such file or directory

I cannot imagine the command lastlog is not installed. I just verified on a fresh clean minimal Debian 9.9 install. Probably try typing the command instead of copy&paste. Because sometimes characters like the dashes -- come out differently if copy&pasted.

@Onirix I have just done a complete fresh clean Debian 9.9 setup and installed FOG without any issue. We might be able to figure out what’s wrong in your case but I’d think you’ll be way faster if you just start over again from scratch. Do a clean install and use FOG 1.5.6 from the beginning. I am fairly sure this won’t cause any trouble for you.

@Scott-B Are you able to access the FOG web UI just fine while it hangs at that stage? Also check the PHP FPM log (see my signature).

@processor Not sure if I asked in another topic but how many hosts do you have?

@Matthieu-Jacquart Please run the parted -l /dev/sda command on the machine you capture the image from. The output you posted looks like you did this on a machine you are trying to deploy to. Sure this won’t give us the needed information. As well we need the full output on the screen! If there are characters missing (right or left or bottom) we might miss some important hint.

About the installer complaining about the user every time: This is because we check lastlog to see if the account was used to login to the machine. Please run: lastlog --user fogproject --clear to get rid of the entry in the lastlog file. After that the installer should not complain anymore. I will add that to the information output of the installer soon.

@mechalas Hope you had a backup of your machine/that file.

You probably read about the blexports option in /opt/fog/.fogsettings as well.

This is bad, bad behavior. I can’t emphasize enough how bad this is.

Not sure I feel encouraged by the sound of this to change this behaviour in the installer. The FOG dev team is very sparse at the moment and has been for months. I am ripping my arms of to fix things here and there and just can’t spend more hours of my free time on this to find and fix all things before anyone else does!

@Onirix I probably need to test with Debian 9.9 myself to figure this out. Not sure when I will get to this.

@Matthieu-Jacquart said in Error trying to restore GPT partition tables. Exit returned code 4:

what I don’t understand with foguser account is that I have to delete it each time I run isntall.sh script, if not I’ve got an error message

Can you please post the exact error message you get. I am fairly sure you don’t mean the sgdisk error in the picture, right?! Probably you get “The account “fogproject” already exists and has been used to logon and work on this machine.”

PS: Turns out I forgot to update a database setting when we renamed the account. So you need to manually do that as well. Please go to FOG Configuration -> FOG Settings -> TFTP Server and update TFTP FTP USERNAME to fogproject.

About the partition layouts. We changed the was FOG finds fixed partitions a little bit and I guess your layouts are now failing to be resizable with the new method. Let’s see if we can figure out why.

For the first one:
We have the first three partitions that I would think should be marked as fixed and not altered. The first one is the recovery partition. Second the EFI boot partition and third is the so called Microsoft Reserved Partition (MSR). Find all the type UUIDs here: https://en.wikipedia.org/wiki/GUID_Partition_Table
Now the forth partition is the one where Windows is installed and which I would expect to be found as resizable by FOG. But this is obviously not the case as we see :2:3:4 in the d1.fixed_size_partition file which I find strange! Can you please schedule a debug capture task on your master machine, boot it up and when you get to the shell run parted -l /dev/sda, take a picture and post here.

Now the second layout:
This is an interesting one. Here the EFI boot partition is last. As we detect this as fixed. Moving a boot partition would cause trouble in the old MBR days and we are still a bit conservative in deciding if we alter a partition or not because we hope to not break too many things. Now with the EFI boot partition being behind the Windows partition we are simply unable to resize your Windows partition in this layout. But this is nothing new for this kind of partition layout. FOG has not changed in that case in the last years.

It would be great to be able to handle those kind of partition layouts better but it’s a complex topic and many things can go wrong. So it would be a lot of work which we can’t do right now.

@lenune Please stop adding external links to your post if you can’t explain us how this is related to FOG!!

@dongtuuyenblackpeony Sounds very strange because the iPXE menu/task execution simply is selected via the MAC address of the client machine. That should be no different whichever state the machine is in. For example, you could even wipe the whole disk or install Linux on the drive and it should still behave same on the PXE boot!

Sorry, don’t want to sound rude but have you used FOG to capture/deploy images before? Just want to make sure you know the process.

@Matthieu-Jacquart The two things are not related from my point of view.

You need to know that we changed the FTP user account from fog to fogproject in version 1.5.6 because we don’t want people to use that account as it’s a service account and messing with it causes issues. Just leave it alone!

The error you posted the picture “Error trying to restore GPT partition tables” is most likely a partition layout problem. Please post the conetents of the text files d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions.

As well you might try a debug deploy. When you hit the error and get back to the shell just run the same command (sgdisk -gl /images/Profs-LV/d1.mbr) manually, take a picture and post here.

@Onirix What do you mean by same error? The “Setting up and starting TFTP and PXE Servers…Failed!” when installing or the error when booting a client machine?

@lenune How is this related to FOG?

@fry_p said in Increase PHP Memory limit:

I find it odd that it is only trying to use 8192 bytes

The error message might be a bit misleading. What this means is that it tried to allocate 8192 bytes beyond* the limit you specified in the ini file and there stops with a fatal error.

We added a search/pre-filter interface to the reporting for 1.5.6 (thanks to @Fernando-Gietz!). I had forgotten about this but now I wonder if you still get the memory exhaustion even if you try searching for a particular host oder username?

@george1421 Trying to read up on this topic I figured that this is not new. Samsung itself has been involved since March 2017!! But seems like this is still the case even with newer kernel versions and other Samsung drives: https://bugzilla.redhat.com/show_bug.cgi?id=1624611

As far as I understand it the lower you set the value of default_ps_max_latency_us the more power is consumed. Not sure if we want to set this by default for everyone.

@jlthompsonpsd Can you please post the exact machine model you have as well as run smartctl -i /dev/nvme0 in a debug capture task console and post a picture of the output here?

@fry_p said in Increase PHP Memory limit:

I am wondering if my table is much too large for the report to handle. Is there a way I may wipe the table up until 5/24/2018, or a year before today?

I am sure we can help you with this. Let’s try to find out how many entries you have in that table and then clean it up a bit.

shell> mysql -u root -p
Enter password:
...
mysql> use fog;
...
mysql> SELECT COUNT(*) FROM userTracking;
...
mysql> SELECT COUNT(*) FROM userTracking WHERE utDateTime < '2018-05-25';
...

The last two queries should give you the numbers of all entries as well as the entries before 5/25/2018. Just to get an idea before we wipe it all. You may want to have a look at some of the entries as well. The following query should give you the last ten entries (seen from the beginning) up until the 24th of May 2018 in reverse order (the very latest of that day at first):

SELECT * FROM userTracking WHERE utDateTime < '2018-05-25' ORDER BY utDateTime DESC LIMIT 10;

Now if you are sure you want to delete those older entries you can go ahead an use DELETE instead of SELECT:

DELETE FROM userTracking WHERE utDateTime < '2018-05-25';

Use the DELETE with caution! Make sure the prior SELECT query actually shows the entries you want to get rid of and not other ones.

@mcturnan87 said in iPXE boot Lenovo m725s:

We do have the same NIC in our laptops and they are getting to the FOG ok.

Just wanted to mention that same NIC model doesn’t mean same behavior per se. Quite often the NIC itself is a different minor version or has a different flash ROM version. As well UEFI firmware is playing a major roll here. Different firmwares can mean different behaviors. See if there is a UEFI firmware upgrade for your machines.

@fry_p Quite often there are a couple of PHP inis. See if you can find them all using this command:
find /etc -type f -exec grep "memory_limit" {} /dev/null \;

@EduardoTSeoane How many pending hosts do you have (each day) so that you’d need to do this in a group sort of thing?

@EduardoTSeoane What exactly do you mean with “approbate” PCs?