@astrugatch Okay thanks and sorry there was that issue.

Can you pull and try installing again?

Thank you!

@astrugatch Yes please.

I don’t know why stable is showing 2254, I see stable supposed to be 2253 but either way they were far enough away from each other.

YEs dev-branch would be wonderful or even better working-1.6 but I can understand the apprehension.

@astrugatch I’d recommend updating git pull if you can? 2254 is a ways back as I understand things for dev-branch. We’re all the way up to 2421 already if you can see if the issue you’re seeing is still happening or already fixed?

@maxcarpone I would ask you, if you’re daring/willing (it’s considered beta but uses the same pipeline with a lot more modern ui, I need people testing, and Fog_newb can likely attest the new ui look and feel though I think they ran into an issue and needed to get functional right away so the snapshotted back)

Upgrade to working-1.6.

I have a goal (along with @JJ-Fullmer ) to try to get working-1.6 to be master/stable branch by October.

1.6 has been “stagnant” since around 2017 and was in relatively stable grounds back then even.

With AI (as you undoubtly can see I’m using to help drive some things) it’s allowed us to get a lot more coding/refactoring and will hopefully present a much better experience of things on the UI side. Without testing I cannot fix UI bugs though.

AI can do some cool things, but it doesn’t know what “wrong/right” looks like, and JJ and I are only 2 people.

There are others on working-1.6 but more feedback is always good.

@maxcarpone You found it, and you were right. The & was the whole thing. It’s now fixed in
code, so you can put your original password back.

First, a correction to my earlier reply. I said the boot-menu password was
involved. It isn’t — the credentials you type during full registration are
entered in the FOS init and posted to service/auto.register.php, which is a
completely different path. Ignore that part of what I wrote.

What was actually wrong. Registration-with-deploy was HTML-escaping your
password before comparing it against the stored hash.

The registration handler read the username and password out of the request
after running it through a shared helper (stripAndDecode()) whose last step
is htmlspecialchars(). That is the right thing to do to a value you’re about
to print into a web page, and exactly the wrong thing to do to a value you’re
about to check against a password hash. So a password containing any of

&   <   >   "   '

reached the password check as its HTML entity form — yours was compared as
&... — and could never match. A leading or trailing space was lost too.

And your timing was exactly right. You said it worked up to 1734 and broke
by 2390. The escaping was added in 1.5.10.1830 (commit 05403ee0,
19 May 2026), which sits right inside that window. It was part of a
security-hardening change, and applying that sanitiser to a credential was an
unintended side effect of it.

That also explains everything else you saw:

• a brand new user worked, because you’d have given it a simple password
  with none of those characters in it
• fog worked in the web UI, and at service/checkcredentials.php, because
  neither of those goes anywhere near that helper
• only registration-with-deploy said “Invalid Login”

For anyone else finding this thread: it is not a keyboard-layout problem,
which is where I’d have looked next. Accented characters pass through untouched
— they aren’t HTML specials. It’s specifically those five characters.

Fixed on both branches, both merged:

• dev-branch (1.5.10) — https://github.com/FOGProject/fogproject/pull/1398
• working-1.6 — https://github.com/FOGProject/fogproject/pull/1397

The decode now lives in one place that registration and checkcredentials.php
share, so the two can’t disagree about the same password again, and it no longer
escapes anything. Verified end to end rather than by reading the code: real
POSTs to service/auto.register.php against a real database, on the unfixed
tree and the fixed one. Passw0rd is accepted by both; a password with an &
is rejected by the unfixed tree with your exact “Invalid Login” and accepted by
the fixed one.

Once you’re on a build carrying that, your original & password will work
again. No need to keep the changed one.

Still outstanding — the two MariaDB instances. That’s unrelated to this bug
and I’d still like it sorted, because two database servers on one box is a real
problem waiting to happen:

systemctl list-units 'maria*' 'mysql*'
ss -lntp | grep -E '3306|mysql'

If both are listening, the one FOG is talking to is whichever
/var/www/fog/lib/fog/config.class.php points at — and the other one is holding
a stale copy of your data that will look convincingly real the first time
something connects to it by accident.

On the blank/null task rows from your earlier queries: on your box there
were zero active ones. The blanks are completed and cancelled history for
hosts and images deleted over the years (about 300 hosts and 459 images since
2017), which is expected and harmless. The reaper added in this round only
touches tasks that are still active and can no longer run, so it won’t go near
that history.

@Jeremy That mount error is our bug. FOS was passing NFS mount options without
actually telling mount it was NFS, so when the storage path doesn’t come
through, busybox falls back to trying every local filesystem in turn and each
one rejects nolock — the ext2/ext4/vfat lines were never really involved.
Fixed and merged, and there’s a new experimental build below with it in. Test it
when you get a chance and let me know how it goes.

Two things when you do. Add isdebug=yes to your bootargs — mode=debug isn’t
our debug switch, so right now you’re getting rebooted back to U-Boot before you
can read anything. And send me the output of these from the failing boot:

uname -a
cat /proc/cmdline
cat /proc/filesystems

Your error listed f2fs, and our arm64 kernel is built without f2fs and without
module support, so it can’t have produced that. I think that boot was running
your kernel8.img with our init rather than our kernel — which would mean we
still haven’t actually tested the kernel fixes on real hardware.

wget https://github.com/FOGProject/fos/releases/download/EXP_20260826-143004/arm_Image
wget https://github.com/FOGProject/fos/releases/download/EXP_20260826-143004/arm_init.cpio.gz
wget https://github.com/FOGProject/fos/releases/download/EXP_20260826-143004/arm_dtbs.tar.gz

All three are from the same build, so there is no mixing them up with what you
have now.

@maxcarpone That output was exactly what I needed — thank you for running it, and for the screenshot of the failing deployment, which turned out to be the most useful thing in the thread.

Your database is fine and your schema is current. schemaVersion 286 is the right number for 1.5.10.2402; 287 only landed this morning. And your first query returning an empty set means you have no stuck tasks at all — nothing in Queued or In Progress. The blank entries you’ve been seeing are all in Complete and Cancelled, and they’re just history: 300 of those rows point at hosts and 459 at images that were deleted at some point over the nine years that table has been filling up. Nothing is wrong with them, they simply have nothing left to show.

The real bug is the one in your deployment screenshot, and it is not your FTP password. Here is what was happening:

* Task Complete
* Updating Database.....................Failed
* Error returned: Failed to update imaging log
* Reattempting to update database.......Failed
* Error returned: No Active Task found for Host: VM-W11-TEST

Only that first error is real. FOG looks up the open imaging-log row to close it by asking for the row whose finish time is empty, and a change earlier in the 1.5.10 line moved “empty” from a zero date to a real NULL. The query FOG was building for that could never match a NULL — so on every single deployment, on every install, it failed to find the row it had just created minutes earlier. It then reported “Failed to update imaging log” after it had already marked the task Complete, which is why every retry after that came back “No Active Task found for Host” and the machine sat there rebooting into an error.

That also explains your very first post: “the host is well imaged but it is not updated in FOG, information about the last image isn’t written in the database.” It wasn’t. The imaging log never closed, the task was already marked Complete, and nothing recorded that the image had landed.

I’ve reproduced it end to end and fixed it, along with three other ways a task could end up pointing at nothing: https://github.com/FOGProject/fogproject/pull/1391

Two things still outstanding on your side:

1. The two MariaDB instances are worth sorting out on their own. I don’t think they caused the above, but two servers on one box is a real problem waiting to happen and it makes everything harder to diagnose. systemctl list-units 'maria*' 'mysql*' and ss -lntp | grep -E '3306|mysql' will show what’s actually listening, and sudo mariadb -u root fog -e "SELECT COUNT(*) FROM tasks" compared against the count in the web UI will tell you whether FOG and your shell are looking at the same database.

2. “Invalid Login” on register-with-immediate-deploy I have not explained yet, and I’d like to. It’s suspicious that a brand new user worked and fog didn’t, because that rules out the typing. Two questions: does the fog user’s password contain any accented or punctuation characters, and can you log into the web UI as fog right now with that same password? If the answer to the second is yes, the problem is in how the password survives the trip from the boot menu, and that’s a different fix from the one above.

@maxcarpone I don’t know if this is directed specifically at you @maxcarpone but if you want the gist:

sudo mariadb -u root fog

Then enter the select statements provided earlier.

I’ve found and fixed several ways these empty tasks get created — a group deploy of two or more hosts was failing outright, and deleting an image was leaving its queued tasks pointing at nothing — but before I ship a cleanup for the rows you already have, I need to know whether the bad tasks hold a 0 or the id of something that got deleted, because that changes what the cleanup has to match on. Could you run this against your FOG database and paste the output?

SELECT  t.taskID,
        t.taskStateID,
        t.taskTypeID,   IF(tt.ttID   IS NULL, 'MISSING', tt.ttName)   AS type_row,
        t.taskHostID,   IF(h.hostID  IS NULL, 'MISSING', h.hostName)  AS host_row,
        t.taskImageID,  IF(i.imageID IS NULL, 'MISSING', i.imageName) AS image_row,
        t.taskName,
        t.taskCreateBy,
        t.taskCreateTime
FROM       tasks      t
LEFT JOIN  hosts      h  ON h.hostID   = t.taskHostID
LEFT JOIN  images     i  ON i.imageID  = t.taskImageID
LEFT JOIN  taskTypes  tt ON tt.ttID    = t.taskTypeID
WHERE      t.taskStateID IN (0,1,2,3)
ORDER BY   t.taskID;

SELECT  t.taskStateID,
        COUNT(*)                AS rows_total,
        SUM(h.hostID  IS NULL)  AS host_missing,
        SUM(i.imageID IS NULL)  AS image_missing,
        SUM(tt.ttID   IS NULL)  AS type_missing,
        SUM(t.taskHostID  = 0)  AS host_zero,
        SUM(t.taskImageID = 0)  AS image_zero,
        SUM(t.taskTypeID  = 0)  AS type_zero,
        MIN(t.taskCreateTime)   AS oldest,
        MAX(t.taskCreateTime)   AS newest
FROM       tasks      t
LEFT JOIN  hosts      h  ON h.hostID   = t.taskHostID
LEFT JOIN  images     i  ON i.imageID  = t.taskImageID
LEFT JOIN  taskTypes  tt ON tt.ttID    = t.taskTypeID
GROUP BY   t.taskStateID;

SELECT * FROM schemaVersion;

@maxcarpone

I’m suspecting you’re not entering the correct password?

This is your FOG Web login user/password.

@maxcarpone I don’t know for sure if 2 instances running would cause a problem specifically that you’re seeing, but I could see there being a mass confusion in “what instance am I connecting to” definitely causing headaches.

@Jeremy The build is up, and it turned out there were two separate bugs, not one.

Bug 1: our arm64 kernel couldn’t unpack our own arm64 init. The kernel had gzip
initramfs support switched off while the init we publish is arm_init.cpio.gz. I
checked a released arm_Image with extract-ikconfig to be sure and it’s real. That
pair has been unable to boot since January 2021, when a cleanup commit pruned “unneeded
initrd compression algos” from all three kernel configs. Correct for x86, wrong for arm64,
and nobody caught it because almost nobody boots the arm64 build.

Bug 2: our arm64 kernel didn’t describe an ARM platform at all. No CONFIG_ARCH_BCM,
so no Broadcom SoC and no Raspberry Pi anything. That’s the missing NIC you found. It also
had no PL011 UART and no generic PCI host bridge, so it had no serial console and no PCI
bus on basically any arm64 machine. The config was added in 2018 by someone who said in
the commit message that they couldn’t test it, and eight years of make oldconfig carried
it forward untouched.

Both are fixed and merged. The kernel now has BCM2835/2711/2712 support, which covers Pi 3
through Pi 5: the VideoCore firmware and mailbox chain, the SD card controllers, bcmgenet,
lan78xx and smsc95xx for the older boards, macb for the Pi 5’s RP1, PCIE_BRCMSTB, and the
SoC watchdog (FOS reboots through that at the end of a task, so without it a client
finishes and just sits there).

I’ve tested it under QEMU as far as QEMU can go: the new kernel unpacks the released init
and boots all the way into FOS userspace, and with a virtio NIC it gets an IP. The old
kernel produces no console output at all on the same machine. What QEMU can’t test is
any of the Broadcom code, because its Pi 4 model disables the PCIe, genet, RNG and thermal
blocks. That’s the part I need you for. None of us has a Pi.

---

Testing it

Good news: don’t change your setup. Keep the U-Boot chain you already have working. We’re
not asking you to switch to iPXE yet, I just want to know whether the kernel runs on real
Pi hardware.

1. Get the files

# the new kernel
wget https://github.com/FOGProject/fos/releases/download/EXP_20260825-141730/arm_Image

# the init - unchanged, but grab this exact one, it's the pair I tested
wget https://github.com/FOGProject/fos/releases/download/EXP_20260819-141018/arm_init.cpio.gz

# device trees, if you'd rather use ours than the one you have
wget https://github.com/FOGProject/fos/releases/download/EXP_20260825-141730/arm_dtbs.tar.gz
tar xzf arm_dtbs.tar.gz          # gives you broadcom/bcm2711-rpi-4-b.dtb

Drop arm_Image and arm_init.cpio.gz into your 7efcf632/ TFTP directory. Your existing
DTB is fine, ours is just there if you want it.

2. Skip the uInitrd wrapper

You can hand the gzip file straight to booti and skip mkimage entirely:

tftp ${ramdisk_addr_r} 7efcf632/arm_init.cpio.gz
booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

I’d rather you did it this way for this test. If you wrap it with mkimage -C gzip,
U-Boot may decompress it before the kernel sees it, and then we won’t have tested the
decompression fix at all. If you’d rather keep uInitrd, build it with -C none so
the gzip bytes get passed through untouched.

3. Move your load addresses

This one matters. Your current layout puts the DTB at 0x02600000, which is 38 MB in,
and the kernel at 0x00080000. The new arm_Image is 30 MB and its BSS runs past the end
of the file, so it can land on top of the DTB and you’d get a hang that looks exactly like
the one you’re already seeing. Give it room:

setenv kernel_addr_r  0x00080000
setenv fdt_addr_r     0x08000000
setenv ramdisk_addr_r 0x09000000

You can drop kernel_comp_addr_r and kernel_comp_size. Those are for a compressed
kernel and arm_Image isn’t one.

4. Fix the bootargs

There are four real mistakes in what you have, and one addition that will save you a lot of
time:

• storagedev=/dev/sda isn’t a thing. FOS ignores it. The variable that picks a disk
  is fdrive=. That’s the “Host Primary Disk” field in the web UI.
• storage= is pointing at the wrong share. A capture writes to
  192.168.203.113:/images/dev/. /images is exported read-only, /images/dev is the
  writable one, so as written the upload will fail on permissions after a long wait.
• web= needs the scheme: web=http://192.168.203.113/fog/. curl usually guesses,
  don’t rely on it.
• mode=debug does nothing here. FOS only reads mode= when type= is empty, so with
  type=up it’s ignored. The one you want is isdebug=yes, which drops you to a shell
  and pauses after every step. Use it for this first test, it’ll show you exactly where
  things stop.

So:

setenv bootargs console=tty1 console=ttyS0,115200 loglevel=7 consoleblank=0 \
  isdebug=yes \
  web=http://192.168.203.113/fog/ \
  mac=dc:a6:32:c8:b4:33 osid=50 type=up \
  img=ImagePi4 imgType=mps imgPartitionType=all \
  storage=192.168.203.113:/images/dev/ storageip=192.168.203.113 \
  fdrive=/dev/sda

(console=ttyS0 is the Pi’s mini-UART. That driver is new in this build too, so if you have
a serial adapter you’ll now get output on it. Harmless if you don’t.)

5. What success looks like

Early on you should see, before anything FOG-specific:

Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 52576K
Run /init as init process

Those three lines alone tell me bug 1 is fixed on real hardware. Then the FOG banner with
Version / Init Version / Kernel Version, then Checking Operating System ... Linux, then
Attempting to check in.

If it sits on “Attempting to check in” repeating, that is a pass, not a failure. It means
everything booted and FOS is waiting for the server to hand it a job.

---

Then the actual capture

FOS won’t image anything until the server has a task queued for it. Hand-writing kernel
arguments doesn’t create one, which is the other reason you weren’t getting anywhere.

1. In the web UI, register the Pi as a host with MAC dc:a6:32:c8:b4:33.
2. Set that host’s Host Primary Disk to /dev/sda (that’s what fdrive= above is
   doing by hand).
3. Create an image called ImagePi4, Linux, Multiple Partition Image - Single Disk.
4. On the host, Basic Tasks -> Capture.
5. Boot the Pi again with the same bootargs. Check-in should return and it should start
   uploading.

Fair warning on one thing I can’t predict: your Pi boots off that USB SSD, and FOS is going
to be capturing the same disk it isn’t running from, which is fine. But a Pi’s boot
partition and its partition layout aren’t like a PC’s, and I don’t know yet how our
partition code handles it. That’s the second thing I want to learn from you.

---

What to send back

Even a failure is useful, honestly more useful than a success.

• The console output from boot, as much as you can capture. Serial is easier than
  photographing a screen if you have an adapter.
• Specifically whether you see those three initramfs lines.
• If it stops somewhere, whatever the last line on screen is. With isdebug=yes it’ll be
  paused at a named step rather than just hanging, which tells me exactly where to look.

Thanks for sticking with this. Two people have asked for Pi support on here over the last
couple of years and both threads died because none of the developers has the hardware, so
you finding this and being willing to test it is genuinely how it gets fixed.

@Jeremy FOS apparently hasn’t been great with Raspberry Pi.

I’m working on building in proper support and fixing a bug we found along the way (Yes I’m using AI to help with the coding and finding/implementing piece.)

I’ll need you, once this refactoring is done and an experimental build is built to test that kernel/init pair to be able to know if what we added/supposedly fixed is working.

Thank you for letting us know.

@jmeyer I’m confused what you’re asking?

secureboot/snponly-shimx64.efi simple is the shim that agrees with the signed snponly.efi. This agreement is only required during “Secure Boot Enabled”, but would/should still work if used for booting “secure boot disabled”.

We already have an ability to boot to the mok manager from the iPXE menu, as well as loading into FOS as its own specific task.

@Jason89436 Thanks for the detailed report — the debug output is what made this findable, and sShutdown_insert coming through empty is exactly the bug.

What was happening. The snapin create path set that field from a comparison rather than from a literal, so PHP handed the database a boolean. FOG binds every parameter as a string, and (string)false is the empty string — so what actually reached the server was ‘’, which is not a member of enum(‘0’,‘1’). Hence “Data truncated for column ‘sShutdown’”.

That empty string has been going in for years. You are seeing it now because FOG used to run SET SESSION sql_mode=‘’ on every connection, which switched off the server’s own validation and let it quietly substitute a value instead of complaining. Removing that clear was the right thing to do, but it turned a long list of silent coercions into visible errors, and this is one of them.

Fixed in 1.6.0-beta.4027. You are on beta.4020, so an update will pick it up. The fix normalizes booleans to ‘0’/‘1’ at the point where parameters are bound, which covers every write path rather than just this one — the same defect was reaching the task-type editor and group/host tasking, and those are fixed along with it. The 1.5 line has it too, from 1.5.10.2399.

Since then I have gone a step further on 1.6 and stopped storing booleans as enum(‘0’,‘1’) at all — they are tinyint(1) now. The reason is that an integer written to an ENUM is a member index rather than a value, so 1 selected the member ‘0’ and meant false. Nothing in FOG hit that, because everything was bound as a string, but it was one careless cast away from silently inverting flags. That change is in the current beta and upgrades your database in place, so there is nothing to do beyond updating.

On the LDAP side — I would like the exact error for that one. The LDAP config path writes its checkboxes as integers rather than booleans, so it is not the same defect, which means either something else is failing there or it is a different symptom of the same strict-mode change. Either way it needs its own look. If you still see it after updating, post the message and the debug block the way you did here and I will chase it down.

@maxcarpone From the sounds of things, the problem you’re running into is the FOG FTP username/password have potentially drifted?

https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

Is still valid I think though how this happened I don’t know, but without much more information this is likely still the best starting point.

@Paul-Freeman There is no repository for post download scripts. At least not one that’s centrally managed that I’m aware of.

Post download scripts are intended to be custom to your environment, and as such it wouldn’t be something FOG would want to maintain.

The forums are the right spot really.

@Paul-Freeman Please try this for your script:

#!/bin/bash
## FOG post-download script -- copy model-matched drivers into the imaged OS.
##
## Sourced, not executed: funcs.sh completeTasking() does
##   . ${postdownpath}fog.postdownload
## so use `return` here, never `exit` -- an exit aborts the whole imaging init
## and the task never completes.
##
## Install to /images/postdownloadscripts/drivers.sh, then add this line to
## /images/postdownloadscripts/fog.postdownload:
##   . ${postdownpath}drivers.sh
##
## Server layout expected (extracted .inf trees, not CABs):
##   /images/drivers/<model>/...     e.g. /images/drivers/Latitude E5410/
## Lands in the image as:
##   C:\Windows\DRV\...

driverbase="/images/drivers"
clientdriverdir="Windows/DRV"     # relative to the mounted Windows volume

#############################################
# Work out the model name
#############################################
# Lenovo is the only real special case: it puts the marketing model
# ("ThinkPad T14 Gen 3") in system-version and a bare machine type ("21AH") in
# system-product-name. Dell and everyone else use system-product-name, so Dell
# needs no branch of its own -- it is the default.
manufacturer=$(dmidecode -s system-manufacturer 2>/dev/null)
case $manufacturer in
    [Ll][Ee][Nn][Oo][Vv][Oo])
        machine=$(dmidecode -s system-version 2>/dev/null)
        ;;
    *)
        machine=$(dmidecode -s system-product-name 2>/dev/null)
        ;;
esac

# Strip leading and trailing whitespace. Dell in particular pads its DMI
# strings, and " Latitude 5420 " will not match the folder on the server.
machine="${machine#"${machine%%[![:space:]]*}"}"
machine="${machine%"${machine##*[![:space:]]}"}"

dots "Preparing drivers"

# Placeholder junk dmidecode returns on whiteboxes, VMs and unflashed boards.
# Treat these the same as "no model" rather than looking for a folder named
# "To Be Filled By O.E.M.".
case $machine in
    ""|[Tt]o[[:space:]][Bb]e[[:space:]][Ff]illed*|[Ss]ystem[[:space:]][Pp]roduct[[:space:]][Nn]ame*|[Dd]efault[[:space:]]string*)
        echo "Skipped (no usable model name)"
        debugPause
        return
        ;;
esac

#############################################
# Bail out before mounting anything if there are no drivers to copy
#############################################
# -d, not -f: these are directories. The original used -f, which is false for a
# directory, so the copy could never run.
remotedriverpath="$driverbase/$machine"
if [[ ! -d $remotedriverpath ]]; then
    echo "Skipped (no drivers for $machine)"
    debugPause
    return
fi

#############################################
# Find and mount the Windows volume
#############################################
# /ntfs is NOT mounted when post-download scripts run -- every funcs.sh helper
# that touches it mounts and unmounts for itself (see mountOSPartition and
# clearMountedDevices). Without this, mkdir -p /ntfs/Windows/DRV just creates a
# directory in the ramdisk that disappears at reboot, which is the usual reason
# this script "succeeds" and no drivers appear.
[[ -z $disks ]] && disks="$hd"
[[ -d /ntfs ]] || mkdir -p /ntfs >/dev/null 2>&1
umount /ntfs >/dev/null 2>&1

winpart=""
for disk in $disks; do
    getPartitions "$disk"
    for part in $parts; do
        fsTypeSetting "$part"
        [[ $fstype == ntfs ]] || continue
        ntfs-3g -o remove_hiberfile,rw "$part" /ntfs >/dev/null 2>&1 || continue
        # WinRE/recovery partitions are NTFS too. \Windows\System32 is what
        # distinguishes the actual OS volume from them.
        if [[ -d /ntfs/Windows/System32 ]]; then
            winpart="$part"
            break 2
        fi
        umount /ntfs >/dev/null 2>&1
    done
done

if [[ -z $winpart ]]; then
    echo "Skipped (no Windows partition found)"
    debugPause
    return
fi

#############################################
# Copy the drivers
#############################################
# -rt, not -a: ntfs-3g mounted without a permissions map cannot honour chown or
# chmod, so rsync -a fails on every file and returns 23 -- a spurious "Failed"
# even though the data copied fine. -r -t gives recursion and mtimes, which is
# all a driver tree needs. -z is dropped too: it is a local copy, so
# compression costs CPU and buys nothing.
#
# Trailing slash on the source copies the CONTENTS of the model folder into
# DRV. Without it you get C:\Windows\DRV\<model>\... and the DevicePath below
# no longer points at the .inf files.
mkdir -p "/ntfs/$clientdriverdir" >/dev/null 2>&1
rsync -rt "$remotedriverpath/" "/ntfs/$clientdriverdir/" >/dev/null 2>&1
errStat=$?

#############################################
# Point sysprep at the drivers
#############################################
# NOTE: this block is still commented out, as in the original. Without it the
# files are copied but nothing ever reads them -- DevicePath is what makes
# sysprep/PnP search C:\Windows\DRV. Uncomment to actually inject. It must stay
# ABOVE the umount below, because it edits a file on the mounted volume.
# Keep %SystemRoot%\inf in the list; separate extra locations with ;
#
#regfile="/ntfs/Windows/System32/config/SOFTWARE"
#key="\Microsoft\Windows\CurrentVersion\DevicePath"
#devpath="%SystemRoot%\DRV;%SystemRoot%\inf;";
#reged -e "$regfile" &>/dev/null <<EOFREG
#ed $key
#$devpath
#q
#y
#EOFREG

umount /ntfs >/dev/null 2>&1

#############################################
# Report
#############################################
# A driver copy that fails must not fail the imaging task, so this never calls
# handleError. handleWarning is used only for a genuine copy failure -- note it
# sleeps 60 seconds, which is why the "no drivers for this model" cases above
# just echo and return instead.
if [[ $errStat -ne 0 ]]; then
    echo "Failed"
    debugPause
    handleWarning "Failed to copy drivers for [$machine] (rsync exit $errStat)"
    return
fi

echo "Done"
debugPause

@Fog_Newb Can you please pull/install and try again?

I’m trying to make things proper, and in doing so I well Claude and I made a mistake lol:

Hopefully this helps?

Here’s claude’s synopsis:

What bit: tasks.taskCheckIn became nullable (GH-1245 / schema 284) and save() started writing a real SQL NULL, so a task that hadn't checked in yet read back as null instead of '0000-00-00 00:00:00'. dev-branch's get() returns null for an unset key (1.6's returns ''), and Task::taskCheckIn() passed that straight into isAlmostExpired(string $checkInTime) — PHP rejects null for a typed scalar param, so: uncaught TypeError → bodyless 500 → FOS never gets ##@GO → "failed to check in", forever, on the first check-in of every task, capture and deploy.

Fix: one ?? '' at the call site in Task::taskCheckIn() — PR #1283, merged, dev-branch now 1.5.10.2344. Not in get(): it's returned null since 2018 and save() now relies on null meaning "truly unset".

The empty() - tasks were unrelated — leftovers from the topic-18081 bug fixed back in January.

@Paul-Freeman Do you mind posting yoru script?

I suspect your script is throwing a handleError (which will exit and restart the machine) and since postinit runs before the task gets to complete that explains what you’re seeing.