Is there any documentation of grow of default install partition size of /dev/sda1 (mounted as /boot) over the years respectively IPFire versions? And what size will it become on a fresh installed Core Update 200 system? I wonder how long my 110M sized one will last while updating…
I did a fresh install early in January and that gave me a 488M boot partition.
It currently has 73M on it. Another system that was fresh installed around middle of 2025 has the same size and usage.
So your 110M will be alright still for a while but I would plan in a fresh install so it can be done at your leisure rather than when space suddenly is insufficient. Then you will get a 488M partition.
1 Like
The limited size of the /boot partition has been an ongoing issue. Why is a separate /boot partition still being used ? I’ve been running btrfs or ext4 as the / partition filesystem for years and GRUB has no difficulty booting via a /boot directory within the / partition.
1 Like
Feel free to modify the installer code and submit a patch for it.
5 Likes
I’ll consider doing so.
Thus far, nobody has indicated that separate ./boot partition is a security requirement.
My experimentation with the installer has been limited to forcing it to use GPT label with BIOS machines. That did work, but it was too tedious doing a compilation each time I wanted to do a fresh install. Consequently, I have not had a development environment set up for many years.
I did remove the separate /boot partition on friend’s Ubuntu, that kept filling up with multiple kernels. That did not require any coding - simply re-location of the directory followed by editing /etc/fstab & running script(s). As a starting point, I could do similar on a fresh install of IPF and check that it survives several upgrades.
2 Likes
This is already looking a more complex task, probably requiring changes to Upgrade scripts as well. If there is no interest, from developers, in doing that, then it is not worth my continuing the task.
My progress so far:
- (laboriously) re-jigged a running installation to boot reliably, with no kernel in /dev/xda1. Using stable CU 198
- this was on a VM, using BIOS firmware - a UEFI VM, without Secure Boot, is defeating me in my openSUSE host.
- I’ve not attempted removing the /boot partition and re-numbering the remaining three, but don’t anticipate issues there, because partitions are identified by UUID
- upgrade to CU 199, via WUI, went smoothly, but reboot failed, being unable to find the previous kernel.
I had re-run grub-mkconfig in the modified CU 198 and grub.cfg in CU 199 looks correct. I need to study the upgrade scripts.
1 Like
Would a moderator care to either rename this thread, or move posts since 2025 to a new thread.
The original thread started when root partition was /dev/sda3: it is /dev/sda4 in contemporary CU. It was also about root partition filling with optional user files.
Discussion this year has been about /boot (/dev/sda1) filling up as a result of system Upgrades.
1 Like
A change to the partition structure to include /boot under / root will only be able to be applied to the iso for a fresh installation. That is the same as all the previous partition size changes.
To modify the partition on an existing structure the mounted partitions would have to be unmounted but an update requires IPFire to be running.
So any user wanting to change their existing partition structure to a newer version would have to either do a fresh install and restore or manually change the partitions with fdisk or equivalent. I would always suggest doing a fresh install as I believe that can be done faster and more secure than trying to use a live cd to move partitions around and/or resize them.
4 Likes
I’m not suggesting that others change the partition structure of a working system, which is why I did not detail the process.
I wanted to see whether or not a modified partition deployment would Upgrade correctly and it does not. There is something in the Upgrade procedure that does not recognise the working location of /boot.
The install procedure does not give a user the opportunity to change partition structure. It would require changes to the Install module. As I have discovered, that fails at the next CU Upgrade, unless the Upgrade routine is also amended.
As far as I can ascertain, the Upgrade process is controlled by a script on the running system and I would prefer modifying that, at the investigation stage, rather than modifying source.
2 Likes
Hello everyone,
On a freshly installed system, you should no longer have a separate /boot partition. There is a separate /boot/efi partition which has to exist because UEFI firmware is only able to read FAT32.
Also, as far as I am aware, IPFire does not make any assumptions about the partition layout. So if you like, you can change it on your system.
What changes to the updater would be required? I can’t think of any.
2 Likes
Hi @ms , I just did a fresh install of CU200 Testing on my vm and there is still a /boot partition being created, together with the /boot/efi and the / partition.
Interesting. I was surprised to find this on my machine in my office:
[root@fw01 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.8G 4.0K 7.8G 1% /dev
tmpfs 7.8G 12K 7.8G 1% /dev/shm
tmpfs 7.8G 1000K 7.8G 1% /run
/dev/sda3 59G 6.7G 51G 12% /
efivarfs 192K 47K 141K 26% /sys/firmware/efi/efivars
/dev/sda1 32M 574K 32M 2% /boot/efi
/dev/sda3 59G 6.7G 51G 12% /.snapshots
/dev/sda3 59G 6.7G 51G 12% /home
/dev/sda3 59G 6.7G 51G 12% /root
/dev/sda3 59G 6.7G 51G 12% /var/cache
/dev/sda3 59G 6.7G 51G 12% /var/ipfire/backup
/dev/sda3 59G 6.7G 51G 12% /var/lib
/dev/sda3 59G 6.7G 51G 12% /var/log
/dev/sda3 59G 6.7G 51G 12% /var/mail
/dev/sda3 59G 6.7G 51G 12% /var/tmp
/var/lock 8.0M 12K 8.0M 1% /var/lock
Maybe we only turned it off when using btrfs? Turns out, we did:
I just cannot remember why we made that change only for btrfs.
2 Likes
The above link didn’t work for me. Not sure if this is only me but my browser didn’t accept the two ; being replaced by %3B.
This link works for me.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=58a46f0bc2063dbc8f55fd46d44d7348199aefbc
2 Likes
Yeah, this seems to be a problem with Discourse whenever I copy and paste a URL from git.ipfire.org.
Interesting. I just copy and paste the url also. Maybe there is some setting in discourse, although I have not deliberately changed any settings for me to not have that effect.
Both are the same for me and don’t access the location. Comes up with a 404 error. I use Firefox but i paste the url into the url link option for the post.
Maybe that makes a difference because the ones you and Michael posted are just pasted direct in the post i believe.
Yes, pasted directly into the post.
I just did a test in a post that I did not actually post.
The same link, one directly in the post and the other using the Link symbol in the discourse post menu.
Directly posted it replaced the ; with %3B and gives the 404 result and in the Link approach it keeps the ; and the link works.
It looks like any link with semicolons gets them replaced in discourse if the link is pasted directly into the post.
Yes, I can confirm this behavior.
Links placed using the Link Symbol and Block Quote are opening correctly.
1 Like
Perhaps because mkfs.btrfs has a facility to create a sub-volume within the filesystem and mount it to a sub-directory, such as /boot.
When I install openSUSE to btrfs, I always specify a separate /home partition and the Installer then does not add a sub-volume /home to the btrfs filesystem. Otherwise such sub-volume gets added. openSUSE generally does not use a separate /boot partition; consequently the Installer creates a sub-volume for /boot.