Thank you for your help, Aceindy.
It is running from an SD card. Have not been able to get it on an SSD.
In a life prior to my previous life I was admin for a large amount of UNIX systems, but my knowledge has become somewhat rusty .
IMHO a supervised system should have warned me or better fixed potential problems for me ( or other novices) . And thus I see this incident as an opportunity to improve HAss-OS.
I see 8 partitions of which 4 can be mounted
/dev/mmcblk0p2 22773 22348 0 100% /media/yann/hassos-kernel
/dev/mmcblk0p3 123520 123520 0 100% /media/yann/disk1
/dev/mmcblk0p4 22773 22348 0 100% /media/yann/hassos-kernel1
/dev/mmcblk0p5 125184 125184 0 100% /media/yann/disk
then there is
/dev/mmcblk0p7 with a label hassos-overlay
that does not mount. (read-only ?)
/dev/mmcblk0p8 with a label hassos-data
that does not mount. (read-only ?)
root@leonie:/media/yann# fsck -n /dev/mmcblk0p8
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Warning: skipping journal recovery because doing a read-only filesystem check.
hassos-data: clean, 311842/1916928 files, 4222403/7636731 blocks
root@leonie:/media/yann# fsck -n /dev/mmcblk0p7
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Warning: skipping journal recovery because doing a read-only filesystem check.
hassos-overlay: clean, 53/24576 files, 8949/98304 blocks
This leaves:
root@leonie:/media/yann# fsck -n /dev/mmcblk0p1
fsck from util-linux 2.34
fsck.fat 4.1 (2017-01-24)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Automatically removing dirty bit.
Leaving filesystem unchanged.
/dev/mmcblk0p1: 245 files, 3860/16343 clusters
and
root@leonie:/media/yann # fdisk -l /dev/mmcblk0p6
Disk /dev/mmcblk0p6: 8 MiB, 8388608 bytes, 16384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
root@leonie:/media/yann# fsck -n /dev/mmcblk0p6
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/mmcblk0p6
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
root@leonie:/media/yann# e2fsck -b 8193 /dev/mmcblk0p6
e2fsck 1.45.5 (07-Jan-2020)
e2fsck: Read-only file system while trying to open /dev/mmcblk0p6
Disk write-protected; use the -n option to do a read-only
check of the device.
root@leonie:/media/yann # e2fsck -b 32768 /dev/mmcblk0p6
e2fsck 1.45.5 (07-Jan-2020)
e2fsck: Read-only file system while trying to open /dev/mmcblk0p6
Disk write-protected; use the -n option to do a read-only
check of the device.
Anyway, to answer your suggestion, I’ve not been able to detect a database.db
and therefor could not free up space yet.