asm64-hooligan's cmpunlocker + 610.57.04 support

close two rollback paths: firmware-owned dmem.bin, and remove.sh hanging master

Booter payload override moved out of the firmware package's namespace. cmpunlock.c read it from /lib/firmware/nvidia/ga100/gsp/dmem.bin, which belongs to nvidia-gpu-firmware (linux-firmware on Fedora). That directory already accumulates per-driver blobs on every firmware release, so an update landing a dmem.bin there would have been preferred over the built-in payload and quietly broken the unlock. Pinning that package is not an option - it is a linux-firmware subpackage and holding it back wedges system upgrades on a dependency conflict. Reading from /var/lib/cmpunlocker/dmem.bin instead makes the question moot. The GSP firmware the driver actually loads lives in the versioned directory from the driver package, which is pinned. remove.sh no longer swaps the running driver by default. Loading the stock nvidia-drm against a CMP wedges the machine: traced it to that exact modprobe, after which the kernel still answers pings while userspace stops making progress. Nothing needed the swap - the modules are already off disk, so the next boot picks up the stock driver on its own, and an uninstall ends in a reboot anyway. Behind --reload for anyone who wants it, now guarded with timeouts. Dropped the rmmod -f fallback: forcing out a module that is still referenced can take the kernel with it, which is a bad trade when a reboot finishes the job. remove.sh also syncs after depmod, matching build.sh. Without it a power cut between depmod and the next flush leaves a zero-length modules.dep, and then nothing resolves on the next boot - not the NIC driver, not storage. Hit this three times in testing via hard power-off.


+79 -22
3 changed files