@robertkwild The issue most likely is not coming from the flip of Secureboot On/Off.

Unsigned or test-signed boot drivers. This is where a real BSOD can happen. If the machine has bcdedit /set testsigning on or nointegritychecks, and a boot-start driver depends on that (an unsigned storage or RAID driver, some sketchy anti-cheat, a dev build), turning Secure Boot on makes those settings get ignored. If the storage driver doesn’t load, you get INACCESSIBLE_BOOT_DEVICE. That one only happens in the off-to-on direction.

@Tom-Elliott All good! Thank you and keep up the awesome work!

@rogalskij Glad to be of help and your finding did notice an issue that was also addressed on the dev-branch so thank you!

@Dominique I can’t promise that, no.

1.5.10 is the original release, and it is a long way behind now. It was built and tested against PHP 7.x. It may run fine on PHP 8, but I don’t know which PHP 8 version, if any, would be safe for it.

What we do know works on PHP 8 is the current stable branch. Here is how the branches fit together:

master is the official 1.5.10 release. We don’t work on it directly. dev-branch is where all the bug fixes and maintenance happen. stable gets everything from dev-branch rolled into it once a month.

So stable is 1.5.10 plus a few years of fixes, PHP 8 support among them.

If you want to move to PHP 8 before 1.6.0 comes out, I’d do it in this order:

Snapshot the server first, so you can roll back. Update FOG to the stable branch and run the installer. Do this while you are still on PHP 7.2. Then move PHP to 8.2. On Red Hat 8 the installer will not do that for you; it installs whichever PHP module is enabled. Run dnf module reset php then dnf module enable php:8.2, then dnf distro-sync. Re-run the FOG installer, so it picks up the new PHP packages. Test the web console, a host registration, and a unicast and a multicast deploy before you call it done.

Since this is production, your plan to wait for 1.6.0 and try the RC in a test environment first is a good one too.

@piaFOG26 Are you able to confirm if things are now working for you?

@Paladin1 Thanks, that explains the registration error. Registration reads the machine’s disk, so it needs a disk attached. With no disk it stops with that message every time. That is expected, so you do not need the debug task.

For your question: neither. Do not reinstall anything yet.

The BIOS boot mode on this machine applies to both the network boot and the installed OS. Your image is a UEFI install, so this machine has to network boot in UEFI too. We can try a different iPXE file for UEFI that loads its own network driver. That can avoid the firmware error.

On the FOG server:

Edit /etc/kea/kea-dhcp4.conf. In the classes FOG-UEFI-64-1, FOG-UEFI-64-2, FOG-UEFI-64-3 and FOG-Surface-Pro-4, change "boot-file-name": "snponly.efi" to "boot-file-name": "ipxe.efi". Run sudo systemctl restart kea-dhcp4-server. Set the target BIOS back to UEFI and network boot it.

Tell us if you get the FOG menu or the same ASSERT. If it fails, change the file back. A re-run of the installer also puts snponly.efi back.

@Tom-Elliott said in Login to delete image not passing correct username.:

@mmaus Would you mind updating to the latest RC or even the working-1.6 branch, if that’s too much a leap, what about upgrading to dev-branch? (It will become stable on Sunday if I recall the timing correctly.) See if we already fixed the problem you’re seeing?

I attempted to migrate to the 1.6…my server looks like it just migrated from 1.5 to the same 1.5 version, but it does look like it cleared up whatever issue it was having. Feel free to close this ticket.

Thanks

@Fog_Newb The per-node ports change has landed: https://github.com/FOGProject/fogproject/pull/2062

Each storage node now has an SSH Port field and an FTP Port field in Storage Node Management. If you leave a field blank, the node uses FOG_SSH_PORT or FOG_FTP_PORT. If that setting is not set either, it uses 22 or 21. Every SSH and FTP connection to that node uses its port. That includes the capture move, replication, snapins, the file deleter, the log viewer and the dashboard check.

It is on dev-branch now, and it reaches stable with the next stable update, along with the exports and key changes. On your single server, the global setting you already have is enough.

@fgaudin Thanks, that output finds the cause. It is a bug in the 1.5.10.2482 installer.

The old IP address comes from /opt/fog/snapins/ssl/.srvpublic.crt, not from req.cnf. That file is the source of the published srvpublic.crt. When the file exists, the installer keeps it, even with -K. So -K made a new key, but it published the old certificate again. That certificate has the old IP address and the old CA. It also does not match the new key. FOG 1.6.0 fixes this: it removes a certificate that does not match the key.

The /etc/sudoers.d/fog-secureboot.tmp error has a second cause: sudo is not installed on your server, so /etc/sudoers.d does not exist.

Do these steps on the server:

Install sudo: apt install sudo Remove the old certificate: rm /opt/fog/snapins/ssl/.srvpublic.crt Run the installer without flags: ./installfog.sh -y Run the check again. It must say OK:
openssl verify -CAfile /var/www/html/fog/management/other/ca.cert.pem /var/www/html/fog/management/other/ssl/srvpublic.crt

You deleted .fogCA.key and .fogCA.pem, so the server has a new CA again. On each client, delete “FOG Server CA” in certlm.msc again, then restart the FOGService.

If step 4 does not say OK, post its output and the Creating client communication certificate lines from foginstall.log.

@Tom-Elliott sorry tom yes i am, sorry for the late reply, tbh i think its just hp machines that do this

@fierke A correction to my last post. The fix is now merged into working-1.6 and rc-1.6.0. Update your checkout and re-run the installer. The installer now writes default.ipxe without those two lines, so you do not need to comment them out again.

You are right that this can happen on other machines too. Any UEFI firmware that never ends its variable list hangs the same way. The update fixes it for all of them.

I would still like the show efi/SecureBoot result and your BIOS version when you have time. That confirms the cause before the iPXE side ships.

@Tom-Elliott Thanks fo the quick reply!
I did rerun the installer today and it seems to be working now, thanks a lot for the quick feedback and fix!

@Fog_Newb Thanks for the detailed report. Your diagnosis was right on all three points.

1b, runs a day late: the chart read TIMESTAMP columns as DATETIME. In the 26 hours after the move to UTC, that made a UTC time look like New York time. Your fix is in, and it covers the imaging, storage, inventory and fleet charts. This one also corrects itself once the 26 hours pass.

1a, 1.5 history missing: the upgrade added the image name column but did not fill it on old rows. A new schema step fills it from the task’s image. A run whose task or image was deleted cannot be recovered.

2, the tooltip: the asterisk on new captures is expected for the first 26 hours, and then it goes away. The tooltip wording was wrong. It now says the value “can be in America/New_York time or in UTC”.

PR: https://github.com/FOGProject/fogproject/pull/2056. It reaches the Patches channel when it merges to dev-branch. Run the schema update after you update, so the history backfill runs.

@Tom-Elliott As always, thanks for the answer and quick fix 😊

Thanks @Tom-Elliott . That actually makes a lot more sense now. 😁

I saw the greyed-out “Mass edit” button, but hadn’t worked out that I had to select multiple items (turn them blue) from the filtered list of hosts in order to be able to use that button to set values across multiple entries. Once I did, it worked as intended.

@Tom-Elliott

Thank you!

As you thought, it was a double DHCP server… Even though .6 was in bridge mode, the DHCP server on it was still enabled, unlike the other MikroTik switches we have. Disabling it brought the iPXE booting back. I’ve run a re-inventory task and am now running an image capture task.

I’ll have to keep a future eye open for that as we expand our classroom network.

Cheers!

@Tom-Elliott
thanks it was lighttpd so i purged it

@Tom-Elliott I wondered if that was the case, thank you.

This is a bug in the version check on 1.5.10.2482, not in your install. Your version is current, and you can ignore the banner.

The check takes the first tag in GitHub’s tag list as the latest stable release. Newer tags (an archive tag and the 1.6.0 release candidates) now sort ahead of 1.5.10.2482, so every stable install shows this warning.

The fix is merged to dev-branch (https://github.com/FOGProject/fogproject/pull/1823). It asks fogproject.org for the current versions instead. It ships in the next stable release.

Hi @Tom-Elliott
After moving from RC-2 to RC-4 the plugin, the WinPE image and the step that closes the task at the end of the WinPE flow all kept working. Only the Apache part needed a change.

With RC-4 the whole vhost sits inside FOG’s managed block, so my earlier Alias plus rewrite exception was gone and /fog/winpe_3400/wimboot started answering 308 (FOG’s rewrite rule sends it to the API). Instead of putting the exception back, I now serve the files from /winpe_3400/ (no /fog/ prefix), with an Alias and a <Directory> in a separate conf-available file enabled with a2enconf. FOG’s rewrite rule only matches /fog/, so it never sees these requests, and nothing in 001-fog.conf should need restoring after an update. The only change in the plugin is its WIMBOOT_HTTP_PATH constant.

Checked after the change: the Latitude fetches wimboot, BCD, boot.sdi and boot.wim from the new path (all 200), WinPE starts, and a full deploy on the Latitude 3400 and one on an HP with the normal FOS/Partclone flow both completed and closed their tasks.