You will not be able to delete stuff to make more room on the root partition as that contains all the packages required to run IPFIre. Delete stuff from there and IPFire will stop working.
All logs, backups and stuff like that is stored on the /var partition, where you have enough space.
Basically the linux kernel and the various packages required have got larger over time so that a 2GB root partition is not large enough.
Your simplest option is to make a backup, store it off from the IPFire system. Then do a fresh install and then restore from the backup. You will then have the new partition layout.
Some users that have had the same problem in the past have ended up adjusting the partition layout to take space from the /var partition and move it to the / partition. I am sure that will have taken them more time than doing a re-install and restore.
The partition adjustment has to be carried out with those partitions unmounted so usually done by running a rescue cd (on usb). Then you have to reduce the size of the /var partition, and then reduce the filesystem size on that partition, usually moving any data on that partition away from the boundary between the / and /var partitions. Then you increase the size of the / partition and then also increase the filesystem size to fill the increased partition space.
The above takes a long time and has a high risk of error, corrupting the data in which case you would have to do a fresh install anyway.
In my view the partition adjustments take longer than doing a fresh install and restore, so that would be my recommendation.
I took a new hard drive and reinstalled IPfire on it. I then re-read the IPfire settings from the backup. Unfortunately, the new IPfire runs a bit shaky. The Samba shares are sometimes accessible by the clients and sometimes not accessible. I don’t see any reason. What could that be about? The old IPfire worked fine for years.
No that is something different. The lock file has filled up completely. That says something is going wrong on the system.
A working system would normally show 1M in the media page but that is a rounding up effect… The % on my system is shown as 1% and I think that is also a rounding effect.
Lock files are not very large and my directory has around 58 bytes in it, so for your directory to be full with 8MBytes it must have got swamped.
Can you show a listing of that directory?
I also just noted that the Index-Nodes for that directory does not show it being full but at 1%, which is what would be expected.
I also note that the graph above says that it was created with another architecture.
When you restored the backup into your new disk was that backup from a different architecture?
Are you using x86_64 or aarch64 currently and have you used in the past 32 bit versions? How old was the backup that you did the restore from?
I am currently using the x86_64 IPfire. I’m not sure what architecture the backups come from. They are a few days old. Another is 6 months old. Can you tell from the backup files what architecture the old system had? I’ll attach the backups.
The hardware is a simple 10 year old PC with an i5 processor and a second network card (Realtek Semicinductor). It has been running for ten years without any problems. Now I have installed a new 4TB hard drive (Seagate IronWolf). I then reinstalled IPfire. The hard drive was unused. I didn’t delete any partition structure.
No you can’t tell the architecture from the backups. What was the version of the Core Update you were running when the filesystem full error occurred?
Just show a selection of say 20 entries. If it is going to be helpful that amount should be fine.
I suspect the simplest fix will be to do a fresh install again.
The installation redoes the partitioning from scratch. That worked okay because the BIOS based /, /var & /boot partitions were replaced by /, /boot & /boot/efi