@tneuber What server OS is this? Did you change php.ini settings? Are you able to use the Web UI without issue? The message seen on screen is a PHP message. Take a look at the PHP ini file on your system an set an appropriate timezone. Depending on your OS the INI can be in different locations. On my debian server I have it in /etc/php/7.0/apache2/php.ini. Should be somewhere along this line on yours as well.

OU Drop Down option is kind of confusing to setup, but it does work.

Each OU is separated with a |

The “default” OU is marked with a ; at the end.

What this means is:

OU1|OU2;|OU3|OU4

Will create a dropdown of:
OU1
OU2
OU3
OU4
with OU2 being the default selected one.

Hopefully this helps.

Mind you all this is is a dropdown, you still have to make the choices and update the hosts/groups in question for this to apply.

@sebastian-roth The issue was changing the LAN boot selection from UEFI to CSM Boot. Thanks all!

@george1421 said in Feasibility of upgrading from 1.3.5 - Network issues:

@joshghz said in Feasibility of upgrading from 1.3.5 - Network issues:

So to clarify, RSTP has to be enabled on all client ports/switches, not just the one the FOG server is connected to?

Yes client ports only, (typically) the fog server never winks the network link at all while running. This issue is exactly between the pxe booting computer and the building switch.

Yeahhhhhh, that’s what I was afraid of. I’ll have a chat with him at some stage, but I’m going to guess this endeavour may have to wait until we get the Merakis.

Thanks anyway! It was really helpful to suss this out. 🙂

@coxm said in Dashboard Bandwidth graph not showing traffic:

For reference POR (Master) and ATL (Storage Node) are on 1.4.4
PHX (Storage Node) is on 1.5.2

Though I am not an expert on the inter FOG node communication I’d advise you to run the same version of FOG on all your nodes and see if that helps.

@vince-villarreal Try to add a group and see what the ID is.

I have found the problem, it was the type of speech mark round the password.
Thanks to those that viewed.

@dbrown You can fix this in php-fpm config.

The path should be /etc/php-fpm.d/www.conf
Edit that file and towards the end of the file add these two lines:

php_admin_value[post_max_size] = 100M php_admin_value[upload_max_filesize] = 100M

Save and close the file then issue this command
sudo systemctl restart php-fpm
That will bump the max upload size of the files to 100MB

@snaggel So we figured out the port on our switch was a trunk port. we cleared the configuration on the port. we also enabled portfast on it. we tested and it registers the host and loaded images. just wanted to let everyone know. thanks again. now on to getting it activated through KMS.

@wayne-workman I want to reclassify the last point you made so hopefully easier reading.

A Storage Node Definition can only belong to one group. However, if you create a second storage node using the same information as a peer siting node, except changing the name of the node, it can belong to another group. The code has been adjusted to read all nodes.

I know this may seem arbitrary in explanation but it more directly points out that a node definition can only be in one group.

The latest parted magic iso image I can find (free) is 2013. So I looked through that iso and based on what I see I have an observation.

The error message mentions unable to mount the squashed file system file.

I don’t see where you are transferring that file system via iPXE? I do see that file on the iso in /pmagic/pmodules directory.

I would be interested in reviewing the following files from the 2018 iso image.

/boot/syslinux/syslinux.cfg /boot/pxelinux/sample_pxelinux.cfg

Lastly are you trying to iPXE boot this image on a uefi or bios based image?

So fog wipe gives you a timeout of 60 seconds (if you decide not to wipe the drive).

Changing it in the fog settings doesn’t make any difference. Any way to disable that timeout or change it ?

Then it gives an error about updating the database (even if the hdds partition table is zeroed), any way to disable that as well ? thanks alot.

@Raymond-Bell Anything in apache error logs?

@foguser9856 said in X1 Yoga Black screen after init.xz:

Is that something I can change?

Unfortunately that is one of the caveats of booting this way. You loose the dynamics that iPXE provides.

But booting FOS via USB does tell us that there is nothing wrong with the kernel or the inits. It appears to be the handoff between iPXE and FOS, or you have flaky firmware on that yoga.

Has the firmware been updated to the latest release on the yoga?

@quazz

So I tried re-capturing the image from my VM and it finally finished but took forever. I left a ping running on the host and the server and never had any lost packets. I had some higher ping times going to the VM were average with one very high number. But never any packet loss.

I decided to try and capture the image to a brand new image and not one I had used previously. I noticed my transfer rate was higher and it ultimately finished capturing the image.

Could the delay simply be the difference between imaging a Windows 10 machine versus a Windows 7 Machine? This is the first image I have created of a Windows 10 machine.

Let me know if you have any thoughts on this.

Thanks again for making me think more about it. 🙂

Cheers!

@fmaster007 the … translates to the path of your fog installer, not the path on Linux of /lib

You can use a dns name and create a split horizion dns where you make fogserv.domain.com at each school point locally to the local fog server.

The issue is as Wayne said, Once the client touches a fog server it becomes tattooed to that fog server. Now if you know that ahead of time you can synchronize (i.e. copy the ssl certificate from your master FOG servers to the other remote fog servers) then have the clients reach out via dns name. If you have any clients that have touched one of the older non master fog server, you will have to reinstall the fog client on the target computer.

Can one of the @developers or @moderators or @testers check to see if this bug exists in 1.5.2 please? I’m not able to do it at the moment.

I found out that the error was caused because the fog account was not recreated when we upgraded. All is well now except for name changing and getting them on the domain automatically. I think that is also a password issue.

@ddavis
If rebooting the server does not fix the problem it could be an apache problem, you could run a

tail -f /var/log/apache2/error.log``````

let this run and see what you get when you try modifying your changes.