Hi Charly,
Thanks for your interest!
TL;DR: backup to external location no-go due to no sshfs / missing fuse module. Repair brought down the system, fixed in the end by clearing /boot and restoring it later on
Still working on it, got a setback from an unexpected corner: no sshfs due to missing modules.
My kernel is 4.19.42-v7+, but there are no modules:
# uname -a
Linux online.osba.nl 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux
# pwd
/lib/modules
# ls
4.14.66+ 4.14.66-v7+ 4.19.66+ 4.19.66-v7+
There is no kernel 4.19.66, apt can not install it due some dependency.
I tried symlinking 4.19.42 to 4.19.66, in the vain hope nothing had changed. Did not work of course.
Online I was not able to find a source with modules for 4.19.42-v7+, so copying was out.
Next I tried downgrading to 4.9.0; that was out because /boot is a mere 44MB, and apt complains about lack of space.
I first moved kernel.img (ostensibly for RPi 4) to a safe place to make space, that was not enough.
Now I just broke the system in this way:
- Move all contents of /boot to /boot_bak; there already was a (system made?) boot.bak which might come in handy;
- Run apt install linux-image-4.9.0-6-rpi2/oldstable
- Now there is enough space, but the process seems to stop early:
(I have some trouble with the editor; if I take this line away, the text is not preformatted anymore , so I’ll camouflage it as some useless text between brackets)
# apt install linux-image-4.9.0-6-rpi2/oldstable
Reading package lists... Done
Building dependency tree
Reading state information... Done
linux-image-4.9.0-6-rpi2 is already the newest version (4.9.82-1+deb9u3+rpi1).
Selected version '4.9.82-1+deb9u3+rpi1' (Raspbian:oldstable [armhf]) for 'linux-image-4.9.0-6-rpi2'
0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up linux-image-4.9.0-6-rpi2 (4.9.82-1+deb9u3+rpi1) ...
No diversion 'diversion of /boot/vmlinuz-4.9.0-6-rpi2 by rpikernelhack', none removed.
No diversion 'diversion of /boot/config-4.9.0-6-rpi2 by rpikernelhack', none removed.
No diversion 'diversion of /boot/System.map-4.9.0-6-rpi2 by rpikernelhack', none removed.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-6-rpi2
W: APT had planned for dpkg to do more than it reported back (0 vs 4).
Affected packages: linux-image-4.9.0-6-rpi2:armhf
The reason may be the the lack other files that I moved aside.
After that I copied a selection of files back from /boot_bak to /boot, but found out (after a ssh timeout) that I skipped kernel7.img…
Well, the SD card is in my computer now, taking the opportunity to make a copy of all the files in case the intended transfer via the Yunohost backups stalls in some unforseen way. It took about 30 minutes for some 20G from a 32GB Sandisk A1 card.
Ok, the RPi boots again. Presumably the system is not fool-proof against removing the kernel 
Funnily enough, I do have kernel 4.19.66-v7+ running now, WITH fuse 
Haha, that was a well spent night in the end 
Feeling a bit uncomfortable though, that I can’t explain when kernel 4.19.66 arrived; all files backed up in /boot_bak are from 20190930, a month ago, except for the 4.9.0-related files, which are from two hours ago. No mention of 4.19.66.
Up next: symlinking /home/yunohost.backup/archives to an sshfs-mountpoint; story for another night.
Have a nice day as well!