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?
Generally this looks like it is going to work.
You can make it more simple by removing the call of find and sed, but the steps that the code is doing are looking good.
That would be great
but i’m not a developer coder.
That is why I am here to help you out 
May something like this ?
for rrd in /var/log/rrd/*.rrd; do
echo "$rrd"
done
as an idea. If you made a backup of the original file, you can use “diff -u {original_file} {new_file}” so your changes can better be applied but also overviewed.
Best,
Erik
Yes, that is the cheapest way to list all files ending in “.rrd”.
Well i have just enlarged the partition with gparted to 1G or something like it. I did a backup beforehand of course, but it worked out really well for me.
@ alternativende
I’ve also used gparted in earlier years, but it is currenly a stop-gap measure for older installations. The next partition that could be short of space is / See Core 139 - Filesystem full
New installations overcome that by not having a separate /var partition and allocating most disk space to /, as well as having larger /boot partition.
oh sorry only now the answer, thanks.
Could solve it, however, think I used the gparted via live CD.