Unfortunately, the kernel has grown in size over the years, and with the latest update, it is now recommended to have a boot partition size of 500 MB. However, the current partitioning of IPFire does not allow for easy resizing without affecting the other partitions. Moving and changing the size of the boot partition is a non-trivial operation, although there are tools available for this purpose.
In this situation, my suggestion would be to follow these steps:
Begin by backing up all the configuration files on your IPFire system.
Download the latest IPFire ISO from the official website.
Install IPFire from scratch using the downloaded ISO.
Once the installation is complete, restore your backup of the configuration files.
As you implied in your message, performing this process requires a NULL modem connection with the serial interface of your PCengines machine. To establish this connection, you will need a DB9F-DB9F null modem cable with a USB to DB9 connector. Alternatively, you can use a USB to DB9 adapter, such as this one, which provides an even better solution.
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
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.
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)
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.
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.
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.
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.
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.
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