@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.

@wayne-workman

Going from 1.5.0 to 1.5.2 resolved the issue.

Glad that helped. The beauty of an active forum where ones struggle becomes others solution. Pretty cool.

@andythemayor Lol, my bad. I thought you were OP. I didn’t read…

Also, changing the memory to 256 resolved the issue, thanks for the help!

I am having this issue with 1.5.2