I'm not entirely confident this is an issue with miniramfs. I've been able to reproduce the bug when installing initramfs-tools from Sid, but not Trixie. Nothing changes with miniramfs in that process.
Trying to debug the issue (assuming it would be miniramfs) I enabled -x and reproduced the issue. The script died inside `manual_add_modules()` from initramfs-tools' `hook-functions`. Miniramfs calls this with `ext2 ext3 ext4`, which should be fairly uncontroversial. Even limiting it to `ext4`, which is a loaded module on my test system.
```
+ manual_add_modules ext2 ext3 ext4
/usr/sbin/update-miniramfs: 97: cannot create : Directory
nonexistent
```
I also tested the (likely more robust) `dep_add_modules_mount()`, which similarly failed inside `manual_add_modules()` with the same error.
```
+ dep_add_modules_mount /boot
+ local dir dev_node FSTYPE
+ dir=/boot
+ [ ! -d /sys/devices/ ]
+ read -r dev mp fs opts rest
+ [ /sys = /boot ]
<snip other filesystems>
+ [ /boot = /boot ]
+ [ ext4 != rootfs ]
+ printf dev_node=%s\nFSTYPE=%s /dev/mmcblk2p1 ext4
+ break
+ eval dev_node=/dev/mmcblk2p1
FSTYPE=ext4
+ dev_node=/dev/mmcblk2p1
+ FSTYPE=ext4
+ [ /boot != / ]
+ [ -z /dev/mmcblk2p1 ]
+ [ ext4 = ubifs ]
+ [ ext4 = zfs ]
+ [ /boot = / ]
+ [ -z /dev/mmcblk2p1 ]
+ readlink -f /dev/mmcblk2p1
+ dev_node=/dev/mmcblk2p1
+ [ -b /dev/mmcblk2p1 ]
+ /usr/lib/klibc/bin/fstype /dev/mmcblk2p1
+ eval FSTYPE=ext4
FSSIZE=503316480
+ FSTYPE=ext4
+ FSSIZE=503316480
+ [ ext4 = unknown ]
+ manual_add_modules ext4
/usr/sbin/update-miniramfs: 97: cannot create : Directory
nonexistent
```
Unless there is some new init function I'm missing for initramfs-tools' `hook-functions`, it seems to me like an issue there. I'm happy to be corrected on this though.
As a workaround for Russell, miniramfs was only required on the PPP due to the huge initramfs generated by osk-sdl, which is no longer maintained. If you switch to unl0kr you should be able to uninstall both miniramfs and osk-sdl and be back to a working system.
Thanks.