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.
