When I tried to update I’ve got this error
Error running transaction: installing package kernel-core-6.18.3-200.fc43.x86_64 needs 40MB more space on the /boot filesystem
I know that sometime in fedora 43 they made /boot limit 2GB, but I’m still stuck at the old limit that is making me unable to update easily.
Is there an option to increase it via terminal? I’m on not immutable version of Fedora 43
1 Like
There isn’t an easy way. /boot is its own partition, usually between the EFI System Partition (ESP) at the beginning of your disk and your root partition (and potentially more after it). Increasing the size of your /boot would require to make some free space after it by shrinking whatever follows it (the rootfs, most likely) and then extending it into that free space.
This can be done with something like GParted from a live system, but it has the risk of data loss, so be sure to back up whatever data you would rather not want to lose.
The safer alternative is to backup your /home and reinstall Fedora and adjusting the partition sizes while doing it. But this is also more work.
As a short-term solution, you can manually uninstall the oldest kernel on your system before upgrading, this should free up enough space on your /boot to allow installing another kernel. Usually, Fedora would automatically uninstall the oldest one anyway (if it exceeds the installonly_limit, which defaults to 3), but only after installing the new one, so at some point in time you need enough space in /boot to accomodate installonly_limit + 1 kernels.
2 Likes
I don’t have them as a separate partition, but I’ll keep that as a last resort anwser
Huh? If your /boot isn’t a separate partition, that means in turn that it is part of your root fs. And as a result, the error you posted would mean that your root fs is full. That’s a completely different question then.
Are you sure about that?
1 Like
That’s weird. I don’t see why you’d get this message (referring to the /boot filesystem) if /boot wasn’t its own partition.
Just to check, can you show lsblk -f ?
No you’re right It is a separate partition. I don’t know what I had in mind typing that…
So my only way of fixing the thing is reinstaling the entire os?
And if yes, then what is the recomended amount of space for /boot?
Something has gone wrong when setting up partitions.
/boot should be a separate partition with at least 1GB space, if you have an NVIDIA gpu, follow the 2GB recommendation.
Backup anything important and reinstall.
How do I make fedora use 2GB? Every time I installed fedora with noveau by default (don’t know if there is much diffrence) it always was 1GB. Do I need to manually partition the drive?
It will be 2GB by default if you install using the Fedora 43 ISO.
If you prefer not to reinstall, see @l-c-g 's earlier post for workarounds.
It’s the safest way, but not the only way. Especially since you are not using LUKS to encrypt /dev/nvme0n1p3, you can try and push the start of that partition back by 1GB and then extend /dev/nvme0n1p2 into that free space. In my experience, this works reasonably well, but there is a non-zero chance for data loss, so I would recommend to backup your /home.
I would suggest to have 2x the space that one kernel needs as free space. This way you should be able to install a new kernel into that free space unless they suddenly double in size.
On my system, the 6.18.3 kernel files are 98 MB and change in total (11MB System.map, 68MB initramfs, 18MB vmlinuz), so I would accept something like 200MB free on /boot (I currently have ~500MB of 1GB, but this is an AMD system):
~ ❯ ls -lh /boot 🕙 17:17:23
total 459M
-rw-r--r--. 1 root root 11M 8. Dez 01:00 System.map-6.17.11-300.fc43.x86_64
-rw-r--r--. 1 root root 11M 13. Dez 01:00 System.map-6.17.12-300.fc43.x86_64
-rw-r--r--. 1 root root 11M 2. Jan 01:00 System.map-6.18.3-200.fc43.x86_64
-rw-r--r--. 1 root root 287K 8. Dez 01:00 config-6.17.11-300.fc43.x86_64
-rw-r--r--. 1 root root 287K 13. Dez 01:00 config-6.17.12-300.fc43.x86_64
-rw-r--r--. 1 root root 288K 2. Jan 01:00 config-6.18.3-200.fc43.x86_64
drwx------. 3 root root 4,0K 1. Jan 1970 efi/
drwx------. 3 root root 4,0K 8. Jan 18:58 grub2/
-rw-------. 1 root root 156M 15. Nov 11:38 initramfs-0-rescue-feb0ffbf74474587b7165e7df4bab53b.img
-rw-------. 1 root root 67M 14. Dez 10:04 initramfs-6.17.11-300.fc43.x86_64.img
-rw-------. 1 root root 67M 18. Dez 08:24 initramfs-6.17.12-300.fc43.x86_64.img
-rw-------. 1 root root 68M 8. Jan 18:51 initramfs-6.18.3-200.fc43.x86_64.img
drwxr-xr-x. 3 root root 4,0K 3. Jun 2025 loader/
drwx------. 2 root root 16K 3. Jun 2025 lost+found/
lrwxrwxrwx. 1 root root 47 14. Dez 10:04 symvers-6.17.11-300.fc43.x86_64.xz -> /lib/modules/6.17.11-300.fc43.x86_64/symvers.xz
lrwxrwxrwx. 1 root root 47 18. Dez 08:23 symvers-6.17.12-300.fc43.x86_64.xz -> /lib/modules/6.17.12-300.fc43.x86_64/symvers.xz
lrwxrwxrwx. 1 root root 46 8. Jan 18:50 symvers-6.18.3-200.fc43.x86_64.xz -> /lib/modules/6.18.3-200.fc43.x86_64/symvers.xz
-rwxr-xr-x. 1 root root 18M 15. Nov 11:37 vmlinuz-0-rescue-feb0ffbf74474587b7165e7df4bab53b*
-rwxr-xr-x. 1 root root 18M 8. Dez 01:00 vmlinuz-6.17.11-300.fc43.x86_64*
-rwxr-xr-x. 1 root root 18M 13. Dez 01:00 vmlinuz-6.17.12-300.fc43.x86_64*
-rwxr-xr-x. 1 root root 18M 2. Jan 01:00 vmlinuz-6.18.3-200.fc43.x86_64*
Well I was using this work around. I think there should be an easier option to increase the size of the partition without obliterating. Now I need to find a drive that will wit my home folder.
Still thank you all for help
How? That’s like asking for a way to make your garage wider but without moving or rebuilding your house or the neighbor’s house that the garage sits between. It can’t be done. (Well, for partitions, moving them is easier than moving a house, but there is some risk, that’s what I wanted to point out.)
I would also consider shrinking the EFI partition down to 200MB (should be fine on a non-dual-boot system) and expanding the boot partition leftwards. The extra 350MB-ish might be enough to stop space issues with kernel upgrades.
Yeah, I’ll stick to reinstalling my os. I don’t exactly know how to transfer my home folder, but I think I’ll find a tutorial. If not I’ll make a new discussion
True, that is simpler. Still carries the risk of rendering the system unbootable if anything goes wrong, but it would leave the btrfs partition alone and allow recovering data from /home from there.
I’m dualbooting so I will just stick to a reinstall.
I’m just going to ask now how can I paste my home folder to a new os, because I just have a feeling that it won’t be just that easy
1 Like
The obvious way is to create a new partition for /boot at the end of the disk.
Shrink the btrfs partition by 2gb to make room for a new 2gb partition at the end of the disk.
Umount /boot/efi and /boot
Save old /boot to disk with dd.
Change the UUID of the old /boot FS
restore content of /boot from disk with dd to the new 2GB partition
resizefs new boot FS to 100% partition size.
mount /boot /boot/efi
test reboot. Then you can delete the old 1gb boot partition.
1 Like
In a running Linux the fastest way to copy your /home/user to a other destination, would be with rsync.
rsync
# To copy files from remote to local, maintaining file properties and sym-links (-a), zipping for faster transfer (-z), verbose (-v).
rsync -avz host:file1 :file1 /dest/
rsync -avz /source host:/dest
# Copy files using checksum (-c) rather than time to detect if the file has changed. (Useful for validating backups).
rsync -avc /source/ /dest/
# Copy contents of /src/foo to destination:
# This command will create /dest/foo if it does not already exist
rsync -auv /src/foo /dest
# Explicitly copy /src/foo to /dest/foo
rsync -auv /src/foo/ /dest/foo
ok’ ill try to do that
While none of this is wrong, my impression of @sgetg1 from statements like “[…] but I think I’ll find a tutorial.” and “[…] I just have a feeling that it won’t be just that easy” is that adjusting this to their system and paths might exceed their level of experience and comfort. For example, the fact that an external drive is mounted to /run/media/$USER/$Label, so that would be the destination in these commands.
1 Like