Hi !
i took the way unmounting mSATA and resize it external (since im using an 512GB mSATA space is not a topic) and i increased /boot to 1 GB , i hope this is enough for the next time 
Ciao Gerd
1 Like
Hi everybody,
I’ve just seen this partition size problem for /boot when switching to 175 !
Here’s the info about my partitions on one of my Ipfire firewalls:
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.9G 4.0K 3.9G 1% /dev
tmpfs 3.9G 12K 3.9G 1% /dev/shm
tmpfs 3.9G 640K 3.9G 1% /run
/dev/sda4 58G 49G 5.5G 90% /
/dev/sda1 110M 52M 50M 52% /boot
/dev/sda2 32M 270K 32M 1% /boot/efi
/var/lock 8.0M 12K 8.0M 1% /var/lock
If I understand correctly, I won’t have enough space to migrate to 175 ? 
Doesn’t /boot resize automatically when going from 174 to 175 ?
Thanks
Mickaël
1 Like
If you were using xfs filesystem then definitely as it now requires 300MiB.
If you are using ext4 (most likely) then your update might have enough space but it might also not.
No, that is not possible. To resize a partition it has to be unmounted. To make sda1 bigger sda2 would need to be moved further up and for that sda4 would need to be changed so all the partitions would need to be unmounted.
With the partitions unmounted then the update can’t occur.
Doing a backup, fresh install then a restore does not take very long, maybe 20 to 30 minutes. Just make sure you have the info on the mac addresses for each network interface/colour and the IP addresses used.
3 Likes
Hi !
I have only 2 partitions (maybe cause im using an APU2) and my /boot was ext2 and / was ext4…
I just only had to move/resize / and make /boot bigger
If its a “regular” pc you might try with geparted live iso (maybe before make an image of your harddisk)
after upgrade to 175 only 6% were left on my boot (52 MB)
Ciao Gerd
Honestly that topic is getting boring / anoying. Within 8 month: the boot partition size has been increased twice. This topic has been discussed many times and always focused at the same problem.
My installations run only a 32GB SSD and I wouldn’t care if the boot partition is 1GB or 10GB.
There must be many people who run their installation @ 8GB CF/SD/SSDs. 
1 Like
Two partitions is not standard at all. IPFire has 4 partitions, a boot partition, an EFI partition that MUST have a FAT file system, a swap partition and the root partition, this regardless of the machine, for example I have an APU2 as well. If you have only two partitions, you must have manually modified several things that have an impact on the boot process as well as the running operations (like how swap memory is configured).
I would strongly advise against enlarging the boot partition in a standard IPFire. The boot partition is the first one, and resizing it in a standard installation would necessitate adjusting the boundaries of all the other three partitions, along with corresponding adjustments to the underlying file system for EFI and root. While it’s possible to do so, one has to question if it’s worth the effort. The process is likely to be both time-consuming and prone to errors.
I understand and share your sentiment, but no single entity is to blame for this situation. The course of other projects has contributed to our current state of affairs. The situation should stabilize for a few years, but it is inevitable that we will face similar issues in the future.
As for the small disk space, we’re seeing the end of an era for minimalist hardware in firewall systems. The discontinuation of machines like pcengines APU is indicative of this trend. The requirements for a firewall, including CPU, networking, RAM, and disk memory, are set to dramatically increase in the near future.
While I don’t suggest that 8 MB disks for firewalls will be phased out immediately, their role is changing. Similar to how black and white televisions still exist in some households today, these smaller disks will persist but in a more niche capacity.
You’re “strongly” against enlarging the boot partition and don’t have an argument, why.
No. See @jon s post. Just 3 changes in 2 files. Done.
I do, it’s in the next sentence.
please, point to the post, so I can try to understand what I am missing here.
1 Like
@goerdi APU2 had a bios from 2016 when it was installed.
https://community.ipfire.org/t/why-i-have-there-such-a-number-in-apu-bios/9889
I think they did not have EFI capability at that time. That came later but once a system is installed in a specific way it will stay that way unless you do a re-install.
2 Likes
That post has nothing to do on how to fix the enlarging of the boot partition by moving the partitions boundaries and the underlying file system, which is what my argument was about. There are NOT two files to fix and be done here.
Def. not, but it’s the source of that problem every time again.
that makes sense. I was very confused by its absence. Thank you. Still, there should be a swap partition.
My installation is very old (i guess 2016) i do not have a swap partion… i have a swapfile in /var/spool/
Ciao Gerd
2 Likes
Status of the boot changes.
In August 2022 it was identified that for some installations 128MiB was insufficient for the boot partition. This was not an issue for all systems but to make sure that all new installations would work the boot partition was increased to 256MiB.
Then in April 2023 it was discovered, during CU175 Testing, that the latest version of xfs will not create a file system of less than 300MiB.
It could have been decided to leave the boot partition at 256MiB but for users choosing xfs for the file system that would then result in having a VFAT partion for the /boot/EFI, an ext4 partition for /boot and an xfs partition for the / partition and that was considered to be too much of a file system salad and would change the existing file system approach of the same file system for both / and /boot.
The decision was taken to keep all systems consistent irrespective of the file system used, so not having different boot sizes depending on the file system selected.
If you are running ext4 and have a /boot partition of 256MiB this will continue to work with updates without any problems for some time still.
The need to change to a 512MiB /boot partition is only present if you are using an XFS file system.
2 Likes
Hi everybody,
Thank you for all these answers 
I’m not use XFS but ext4.
In my case that I described above, I would then like to know if… when I go to launch the update procedure, does Ipfire test first if there is enough space on all the partitions it needs before starting the update procedure and thus avoid ending up with a blockage because not enough disk space ?
Given that my firewalls are in production, I would not like to find myself in a situation where I have launched the update procedure and I am stuck in it for lack of space !
If Ipfire first tests if there is enough space and warns us with an error without continuing the update procedure then I would be more serene
Thanks
Mickaël
1 Like
I think you should be fine, simply because I do not think the boot content will need much more than the space you already have. However, you should not rely on my opinion and get @bonnietwin or a more knowledgeable member of the community.
Can you afford a downtime? If yes, I would suggest to create a mirror copy of your disk on an external disk, boot from it and update. Then see for yourself.
Sorry for the confusion. My post is NOT for a fix. These were the changes made to the entire build system over the past few years.
The fix is to make a backup, save the backup(s) to a new drive, then rebuild the IPFire box, and restore the backups.
We’ve all gone through the same issue. Kernel’s change size, builds change size, and drives must be re-partitioned.
1 Like
The root cause of this issue is IPFire persistence with separate /boot partition. I’ve eliminated such from my friend’s Kubuntu, because Kubuntu kept filling it up with kernels & initramfs. I never use one on my own openSUSE installations.
Grub can directly read ext4 & XFS partitions, making separate /boot unnecessary.