@Strahd Have you been able to make progress?

@Tom-Elliott Tom, looks like everything has been resolved after going from 2144 to 1.5.10.2218! No errors and I was able to capture no problem. Thanks

@Valer This should be fixed in latest/greatest

Working 👍

@JJ-Fullmer This was it, thank you!!

Everything I read kept telling me this machine was x86 based and there is no hint in the BIOS or the serial number lookup tool, of it running an ARM processor(other then “Elite”). We are going to return these machines to the vendor, so problem solved for us.

Would be interested in hearing about future support for ARM in FOG because I’m sure this isn’t the last time we will cross paths with it.

@Tom-Elliott Just a thought, was reading through the docs and I noticed that because of the adhereance to stock iPXE 2.0 netbooting with HTTPS is disabled by default. This may be a little too complicated so I’d get avoiding this, but you could probably work around this by nesting shim and iPXE to boot a custom signed iPXE. It would work something like this:

Netboot iPXE 2.0 normally with it’s shim Use autoexec.ipxe with the shim command to reload that shim Using autoexec.ipxe chainload a custom build of iPXE 2.0 that has the FOG certificate bundled and trusted.

If the binary chained isn’t already trusted, I believe you should be able to use some scripting to then automatically chain in mokmanager or fallback to chaining via http.

Provided you use the normal FOG signing keys, this should work fine, though it does mean having two shims. It may be worth it to close that small gap in HTTPS. Both the shim and custom iPXE could be chain loaded via TFTP. It does add a little more complexity to the signing and boot process but I figured it was worth mentioning, as having HTTPS wherever possible does seem valuable.

@Tom-Elliott I did update to version 1.6.2254 and the first multicast that worked was the first one I tried after the upgrade. This second one is now hanging like the one that prompted this thread.

Where in the logs can I find any clues?

@Tom-Elliott Hi! I updated my FOG server to latest beta-branch version: 1.6.0-beta.3197. I also updated my storage node to 1.6.0-beta.3197. This fixed the invalid path issue I was having. Thank you for the help!

1a0e5491-b776-49fe-9fbf-d2bc40087f78-image.png

@Tom-Elliott

Thanks so much for your help with this. Happy to feed back any info I can so please do let me know if there’s anything else you need me to test. Will be on annual leave for a couple of weeks after this and have no access to the systems but I think this confirms your suspicion. Please see results below from a Dell OptiPlex 3070:

Addresses on this machine:

NIC: 01:00.0 (Realtek RTL8168h)
Root port: 00:1c.0

UEFI mode:

setpci -s 01:00.0 CAP_EXP+10.w = 0142 (last digit 2 = L1 enabled)
setpci -s 00:1c.0 CAP_EXP+10.w = 0c42 (last digit 2 = L1 enabled)

Legacy/CSM mode:

setpci -s 01:00.0 CAP_EXP+10.w = 0040 (last digit 0 = ASPM off)
setpci -s 00:1c.0 CAP_EXP+10.w = 0c40 (last digit 0 = ASPM off)

Dell’s UEFI firmware enables L1 on both the NIC and root port. The Legacy/CSM path leaves both off. The only difference between the two readings is those two ASPM bits. Everything else in the register is identical.

Thanks for the nudge to run these. Anything else needs testing please do let me know. We love using FOG and it’s invaluable in our set of schools that we work in at least so please do keep up the great work!

@toschulz So I suspect the problem is due to a divergence of db schema between dev-branch/stable + working-1.6

If you can update yoru Mysql directly:

sudo mariadb -u root fog (if no root password of course - if you have a root password add -p

UPDATE schemaVersion SET vVersion=0;

Then refresh your screen, click the install/update, and hopefully the error will go away.

The way the schema is configured is it will attempt (idempotently) to rerun every single SQL query in the schema chain.

This should fix the problem you’re seeing.

I believe there’s a column on the login history piece being requested that may just simply be missing which would cause the issue with datatables.

@Tom-Elliott thanks Tom - using the excellent fog-docker from 88fingerslukee - so will wait to hear his response

@Tom-Elliott Hi, Yes with the proposed fix, it works now.

@Tom-Elliott
The fix worked perfectly! The menu issue is now resolved.

Thanks for the support!

@Tom-Elliott Hello Tom yes I have installed the compatible Fog client from the Fog server on the reference machine, sys prepped and captured the image and now I am deploying.

@Tom-Elliott
Updated to latest dev-branch and snapins are working now
Thansk for help.

What version of FOG are you running?

@Valer I think we need to understand what this plugin is doing.

CSS isn’t something we’ve allowed to be injectable though it could be.

You can still use your own CSS but that’s more at the FOG Configuration -> FOG Setting -> FOG_THEME, but you would need to put it on your server in a location you type the path too here.

https://docs.fogproject.org/en/latest/development/plugin-development

This is a good toolkit for understanding how to build your own plugin.

@rpycroft Please attempt to update to 2231.

I have figured out the issue. I was looking in the wrong place in BIOS for the secure boot setting which was on. Turning off secure boot fixed the process which runs perfectly now.

Encountered the same issue, version: 1.5.10

I can successfully capture the image and then see the size of it in the web panel but then it’s not being moved to /images/ by fog. Requiring me to move them manually which works but I’m kinda concerned.

FTP works fine even though I am afraid I don’t understand why I need FTP to move some files inside a directory on a singular server.