@AlexPDX said in Location Plugin Not Working as it should ...:

So…i had to instal phpmy admin and find that there wos a problem in the data base …

What exactly was the issue? How did you fix it?

@Sebastian-Roth thank you very much for your help !
You put me on the way !
Everything is fine now, after I ask the people who are managing the proxy to “open the tap” !! (and sorry for my English !)

@Sebastian-Roth Thanks so much for the detailed explanation. It worked like a charm!

@Sebastian-Roth Interesting. I’ll keep that in mind. Thanks.

@hancocza said:

maybe you have a better way of doing this?

In your case you better just comment or remove those five lines from the PHP code. The fog-client code is made to check if “url” ($location in the PHP code) is empty and defaults to the values specified in settings.json on the client.

Not sure if there should be a change to use the hostname instead of IP if specified in the .fogsettings file

Using DNS name is adding another layer of complexity and I wouldn’t want to add that as default for every FOG user. You can run FOG without setting up proper DNS and I see this as a good default to not add another hurdle for most of our users. If you want to switch to DNS/hostname you wre welcome to do so.

If there are issues in the code that we need to fix preventing you from using the hostname instead of IP, let us know. Best to open an issue on github and point out where things are going wrong.

@Mark-Shelton As seen in the picture the version of partclone is 0.2.89 which is the version we used in FOG 1.5.7. Sadly it’s not able to deploy images that were created with the newer version of partclone (0.3.13) which is now used in FOG 1.5.8.

Partclone 0.3.13 can deploy older images created by version 0.2.89 but not the other way round. Please upgrade your Raspberry Pi FOG install to FOG 1.5.8 (manually fixing the udpcast compile issue) or FOG development version (dev-branch has the udpcast compile fixed already).

@dmathews If you are going to start over, once the linux server is built. Create the /images directory by hand and then create the mappping of /dev/sdb1 to /images THEN install FOG. It will create everything correctly then and no changes will need to be made to FOG because the disk was added at the OS layer.

@AlexPDX Please open a new topic as your request has nothing to do with the initial post as far as I can see. Just copy and paste your text from this.

@Mark-Shelton Great, thanks for the feedback. I just added a fix to the code.

@Quazz said in Snapin replication no working:

systemctl start FOGSnapinReplicator

10x dude …that did the trick 🙂 now its all working again

After some extended research I figured out this was caused by the build script not re-generating the trusted root part of the code compiled into the iPXE binaries. It’s really easy to fix and I pushed a fix to both dev-branch and working-1.6 so we hopefully never run into this again.

cd path/to/fogproject/bin/ touch ../../ipxe/src/crypto/rootcert.c rm /tftpboot/undionly.kkpxe ./installfog.sh

On that way I learned a couple of things about iPXE booting over HTTPS and so I hope we can find most upcoming issues more quickly from now on.

@AlexPDX So if you look on the storage node(s), are those image files there?

@astrugatch Good to know this was caused by browser caching. I can imagine more people running into this. Thanks!

@cbittencourt So just for clarity you had secure boot enabled and you turned it off to resolve the issue?

@Sebastian-Roth Thank you for all you and everyone does. I agree with you this was a good choice to make a second topic out of. This is working well now and I greatly appreciate all the assistance!

@george1421 said in PXE Boot not working properly from Storage Node:

So the root cause of this:

The fog install script does not honor https for storage node installs?
The fog installer did not provide the necessary command line switches when installing the storage node to enable https?

As far as I can tell right now the only issue was that the storage node was not installed with HTTPS enabled in the first place and the buildipxe script in 1.5.7 has a bug that would not compile the cert into the binaries correctly (fixed for 1.5.8 already).

@anwoke8204 said:

it attempts to pass off to the hard drive, but it doesn’t, just goes back to the fog menu

I am wondering on what happens if you switch from PXE boot back to just plain boot from disk? Does it boot Windows 10 properly then?

I have tried both bios and uefi. and I get the same issue.

What exactly to you mean by that? Did you play with the exit type settings for both in the web UI or did you switch the BIOS/UEFI firmware settings on the host? If you played with the firmware settings on the host I am really wondering if your image is UEFI or legacy BIOS? You can’t have a pure UEFI image and boot that on a legacy BIOS only machine or vice versa.

Which exit type is set in the web UI? Have you tried all the different ones like SANBOOT and so on?

Be aware there is a global setting for exit type as well as a per host setting.

@mp12 Looks good! I will update the official binaries tomorrow. Thanks for all the testing! Marking as solved.

Hi,

DB cleanup did the the trick.

Thanks

@Sebastian-Roth I removed the last two partitions and worked like a charm. Thanks!