@WielandPP1 Thanks for the log line. It shows the cause exactly.

PHP 8 is supported, so you do not need a different PHP version. The problem is a missing PHP extension. On Linux Mint, the installer adds the ondrej PHP repository. In that repository, php-fpm installs PHP 8.4, but php-ssh2 installs the ssh2 extension for PHP 8.5. Your web server runs PHP 8.4, so ssh2_connect() does not exist and the snapin upload fails.

To fix your server now, install the ssh2 extension for PHP 8.4 and restart PHP-FPM:

sudo apt-get install php8.4-ssh2 sudo systemctl restart php8.4-fpm

Then try the snapin upload again.

We are also fixing the installer in working-1.6 and rc-1.6.0:

The installer installs the ssh2 extension for the PHP version that PHP-FPM runs. On Linux Mint, the installer uses the distribution’s own PHP, as it already does on Ubuntu and Debian. If the extension is missing, the upload shows “SSH Connection has failed” instead of a 500 error.

@Tom-Elliott I figured it was more-so on the internal end of things that we had to take care. But, wanted to make sure. Thank you for your response!

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.

@piaFOG26 One more item, about the “Access Denied” in the disk usage box on the VM dashboard.

Your VM and your master node are two full FOG servers, and each has its own database. The master node only trusts requests from the storage nodes in its own database, so it refuses the VM. I fixed this in FOG: a request signed with a shared node key is now accepted. The fix is on dev-branch now and reaches the stable release on November 11.

To use it, both servers must have the same key. First, finish the schema update on the master node. Then:

Make a key on either machine: openssl rand -hex 32 On the VM, open Storage Management, then edit the master node (NComun). Paste the key into Node API Signing Key and click Update. On the master node, run this from the fogproject folder you installed from: sudo php bin/fog-node-key.php --set <the same key>

If you need it before November 11, install dev-branch on the master node. The fix must be on the master node, because that is the server that checks the key.

@delacroix fixparts went missing from FOS during a Buildroot update. The fix (fos#195) landed yesterday, and the first build with it is EXP_20261021-160109. I checked that release: /usr/sbin/fixparts is present in init.xz, init_32.xz, and arm_init.cpio.gz.

Your debug task boots the init that your FOG server serves, not the one you downloaded. Put the new file in place on the server:

cd /var/www/html/fog/service/ipxe mv init.xz init.xz.old wget https://github.com/FOGProject/fos/releases/download/EXP_20261021-160109/init.xz sha256sum init.xz

The hash must match the init.xz.sha256 on the release page (it starts 8e3457ad4268add5). To check the content without a boot:

xz -dc init.xz > /tmp/init.img debugfs -R "ls -l /usr/sbin" /tmp/init.img | grep fixparts

Then run the capture again. If fixparts is in that listing and the capture still fails, please post the output of fixparts /dev/sdX (or /dev/nvme0n1) from a debug task.

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

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

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

@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

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

@Paladin1 Thanks for the report. You’re right, the docs were out of date.

The installer now asks Install/update the FOG database schema now? (Y/n) and does the schema update itself when you answer yes, which is the default. The browser step only applies if you answer no.

The “Denied” you saw is expected on a new install. With no FOG users yet, the schema page only accepts the link the installer prints, which ends in &fogtoken=.... On an existing install, you log in as an admin instead.

The install pages are updated for both versions:

1.5: https://docs.fogproject.org/en/latest/1.5/installation/server/install-fog-server/ 1.6: https://docs.fogproject.org/en/latest/1.6/installation/server/install-fog-server/