Hi Guys,
after updating two devices, both showing now that one disk is nearly full, only 9% left.
As you can see in the second screenshot it’s the boot partion where only 9% of space is left.
Finally I checked what may be cause this issue and take a look at the partition.
So my question is, what can I do or can I ignore the notification? I worry that I will may get problemes with further updates.
Best regards
Georg
This is normal on 32bit systems with the additional pae kernel.
It’s depend on an older partition scheme. Installations before approx. two years ago. Isn’t it?!
So the solution is backup, reinstall, restore?
Also @arne_f: with this additional pae kernel, will this installation “survive” to next update overwriting an older kernel before writing the new one?
@xeonium Yes, first I installed the systems in February 2016.
@pike_it That’s the big question, what will happen when the next update coming out.
" Rant Over
Thanks for still being with me. Here are the take-aways from this post:
Intel processors are fundamentally broken. Mitigations are not fixes - no matter what their marketing tells you.
If you are running IPFire on 32 bit and your processor supports 64 bits and is affected by one of these vulnerabilities, reinstall now
Now!"
https://blog.ipfire.org/post/32-bit-is-dead-long-live-32-bit
Okay, okay, I understand. 
I have to reinstall the systems.
I guess the best way would be following these steps.
Step 1: Backup configuration as *.ipf File
Step 2: Download the current 64 bit image
Step 3: Format hdd and install the new version
Step 4: restore configuration
Migrate from 32 to 64 bit (if your CPU is capable) will save a lot of unused power from that, starting from memory management. And if you have more than 4gb, lacking of PAE will boost also the allocation.
A couple of years ago one update make my installation explode, so i were able to run a quick backup and took a chance to 64 bit migration.
But
the…
worth to be asked to developers, at least for avoid any upgrade before a comprehensive backup-64 bit install-restore.
Due to statistics collected by the appliances installed (if you allow it) i’d be curious to know which ratio there is between x64 and x86 installation currently.
If the kernel continue enlarge at some point there will be not enough space for two kernels. In this case the pae kernel will not installed anymore and you loose the larger memory support but the system will still work.
But if your cpu support 64bit you should migrate …
After restoring a backup you have to remove the incompatible rrd database for the graphs. https://wiki.ipfire.org/installation/arch-change
Exporting on old 32bit system
rrdtool dump /var/log/rrd/hddshutdown-sd*.rrd /hddshutdown-sd*.xml
rrdtool dump /var/log/rrd/hddtemp-sd*.rrd /hddtemp-sd*.xml
and importing
rrdtool restore /hddshutdown-sd*.xml /var/log/rrd/hddshutdown-sd*.rrd
rrdtool restore /hddtemp-sd*.xml /var/log/rrd/hddtemp-sd*.rrd
into new 64bit system will keep the values
replace * with your personal values!
Really lovely…
It would be great if anyone of you would find the time to integrate this into the backup scripts.
I had this on my list for a long time. It is not difficult, but I am really short on time right now.
To flag my post off-topic is a joke. Thanks for nothing! Hyper-V VMs had to be installed 32bit to work years ago, these VM’s have now the same “boot is full” problem as the thread starter, solution shall be to migrate to 64 bit. And I just asked if that is now working with Hyper-V.
Dirk
The problem why all has installed the 32bit Version on HyperV is not the 64bit version itself. 64bit Linux need at least 2 virtual cores. It crashes if you give the VM only one CPU core.
That would be great 
but i’m not a developer coder. For first solution everyone needs to use search.
In german we say T E A M(Toll Ein Anderer Macht’s) free translated “great anyone else will do”
I think it would be great task to get started. It is not that you have to do it alone. We are here to help.
Hi all,
does this →
--- /var/ipfire/backup/bin/backup.pl.orig 2019-12-10 17:03:57.546665749 +0100
+++ /var/ipfire/backup/bin/backup.pl 2019-12-10 17:01:25.960820294 +0100
@@ -62,6 +62,9 @@
--exclude-from="/var/ipfire/backup/exclude.user" \
$(process_includes "/var/ipfire/backup/include" "/var/ipfire/backup/include.user") \
"$@"
+ # Dump RRD graphs
+ rrdtool dump /var/log/rrd/hddshutdown-sd*.rrd /hddshutdown-sd*.xml
+ rrdtool dump /var/log/rrd/hddtemp-sd*.rrd /hddtemp-sd*.xml
return 0
}
@@ -143,6 +146,14 @@
rm -rf "/var/ipfire/snort"
fi
+ # Restore RRD graphs
+ /etc/init.d/collectd stop
+ /etc/init.d/vnstat stop
+ rrdtool restore /hddshutdown-sd*.xml /var/log/rrd/hddshutdown-sd*.rrd
+ rrdtool restore /hddtemp-sd*.xml /var/log/rrd/hddtemp-sd*.rrd
+ /etc/init.d/collectd start
+ /etc/init.d/vnstat start
+
return 0
}
@@ -251,3 +262,4 @@
}
main "$@" || exit $?
the trick ? If yes i can push it for you but may also better to try it by yourself as Michael suggested ? If you need help can try to deliver a little (may in a separate topic) ??
Best,
Erik
I certainly endorse the backup and re-install recommendation. It solved the disk space issue on my PAE installation.
If it is not possible to convert the machine to 64 bit installation, then potential action depends on georg’s use case.
If it is a home system and not an Intel processor, then perhaps no urgency. “CPU vulnerabilities” on my 32 bit AMD Sempron reports only “spectres 1 & 2”, both mitigated. By comparison, on 64 bit A-series AMD it reports spectre 1, 2 & 4, all mitigated.
Your modified backup.pl would be very static.
I’v found another possible solution here
to dump
for rrd in
find /var/log/rrd -maxdepth 1 -type f -name "*.rrd"; do xml=echo $rrd | sed 's/.rrd//g'; rrdtool dump $rrd > $xml.xml; done
to restore
for xml in
find /var/log/rrd -maxdepth 1 -type f -name "*.xml"; do rrd=echo $xml | sed 's/.xml//g'; rrdtool restore $xml $rrd.rrd; rm $xml; done
this way, all rrd files are taken into account
not sure, in which folder backup-script collect the files. The destination of the xml-files should changed.
edit: This forum cut’s the format. The link should show the correct characters, brackets, commas, tildes etc.
i think i got it
do dumping first before tar!
/var/ipifre/backup/bin/backup.pl
for addon in $(list_addons); do
make_addon_backup "${addon}"
done
# Dump rrd data into xml
for rrd in `find /var/log/rrd -maxdepth 1 -type f -name "*.rrd"`
do
xml=`echo $rrd | sed 's/\.rrd//g'`
rrdtool dump $rrd > $xml.xml
done
tar cvzf "${filename}" \
…
rm -rf "/var/ipfire/snort"
fi
# Restore RRD graphs
/etc/init.d/collectd stop
/etc/init.d/vnstat stop
for xml in `find /var/log/rrd -maxdepth 1 -type f -name "*.xml"`
do
rrd=`echo $xml | sed 's/\.xml//g'`
rrdtool restore $xml $rrd.rrd
rm -rf $xml
done
/etc/init.d/collectd start
/etc/init.d/vnstat start
return 0
@ms @arne_f @ummeegge would someone else test and confirm it?