Hi George, I have removed the rescue kernel. I would like to increase the boot partition, as easily and safely as possible. My SSD’s are fairly new so they should not be a problem with failing.
As maybe you have read, I have both Gparted and Gnome-Disks.
When I tried to unmount the boot partition it says “unable to unmount”. So I am confused and not sure of the proper procedure to increasing the size of boot. I have lots of space on “home” which I suspect I have to reduce before I can increase “boot”
Is there a clear advice someplace for beginners?
Boot from Live USB image, which means your partitions will not be mounted.
Then use Gparted or your partitioning tool of choice to shrink one partition and expand your /boot partition by whatever amount you deem appropriate. I’ve left mine at 1GB but I remove the nouveau drivers from all of my /boot files which makes them significantly smaller and I have also dumped the rescue partition as it’s of no use to me.
┌─🎩 lurcher /boot🔒
├─
└─➜ df -h /boot 13:14 Tue 04-Nov
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 974M 370M 537M 41% /boot
370MB used with 527MB free with 5 kernels kept. Plenty of space I feel, even with a stock “pre-F43 fresh install” 1 GB /boot partition. If you want to make yours larger, go ahead but it has to be done with the partitions unmounted, as you have found out.
1 Like
Hi Steve, would it work if I used the second SSD with Windows and opened Gparted in the Windows OS?
Good idea, yes you can normally alter partitions from Windows, but Windows does not recognise btrfs usually … so test it out.
In this day of TB drives, the Fedora installer really should double or triple the default size of /boot. That is the correct answer. A larger /boot becomes mandatory if a large initramfs is needed. As for expanding /boot, if that requires shrinking root, that’s not going to work.
In your particular case, since you have a second drive, you might consider shrinking Windows, creating a Linux partition in the free space and backing up what can’t be reinstalled there. Then do a fresh reinstall of Fedora, and manually allocate a large (2 or 3 GB) /boot. 200 MB should be enough for /boot/efi.
I struggle to understand why we’re still using separate /boot partitions at all. Both Grub and systemd-boot can read from multiple kinds of filesystems, so outside of LUKS encryption on the rootfs, what’s the benefit? Yes I understand why /boot/efi needs to still exist as the ESP, but /boot?
Here is an example script that quickly and efficiently removes a set of (usually) unnecessary kernel versions, leaving the latest one:
#!/usr/bin/env bash
old_kernels=($(dnf repoquery --installonly --latest-limit=-1 -q))
if [ "${#old_kernels[@]}" -eq 0 ]; then
echo "No old kernels found"
exit 0
fi
if ! dnf remove "${old_kernels[@]}"; then
echo "Failed to remove old kernels"
exit 1
fi
echo "Removed old kernels"
exit 0
Save it as, for example, remove_ok, make it executable, and put it in /bin. For better compatibility with your system, you can and should change the file owner to root. Then, after each update, simply call it with sudo, and it will immediately begin cleaning up the old kernel. If you want to keep more than just the latest, most recent version, you can manipulate the --latest-limit=-1 variable.
Note: To avoid potential problems, run this script on a system booted from the latest kernel.
I hope this helps…
1 Like
Why would you want to do that? It’s dangerous and unnecessary as dnf takes care of old kernels. And again, for most users 1GB is still large enough to keep 2-3 kernels.
Just as an example, here is usage of my /boot partition. I am keep five latest kernels, however, I have removed the rescue kernel. If I would ever need a rescue kernel, I just boot from a recent live image. And yes, this machine has no nvidia GPU.
df -h /boot
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 794M 353M 384M 48% /boot
rpm -qa kernel
kernel-6.16.12-200.fc42.x86_64
kernel-6.17.4-200.fc42.x86_64
kernel-6.17.5-200.fc42.x86_64
kernel-6.17.6-200.fc42.x86_64
kernel-6.17.7-200.fc42.x86_64
`ll -h /boot`
LANG=c ll -h /boot
total 351M
-rw-r--r--. 1 root root 12M Oct 12 02:00 System.map-6.16.12-200.fc42.x86_64
-rw-r--r--. 1 root root 12M Oct 19 02:00 System.map-6.17.4-200.fc42.x86_64
-rw-r--r--. 1 root root 12M Oct 23 02:00 System.map-6.17.5-200.fc42.x86_64
-rw-r--r--. 1 root root 12M Oct 29 01:00 System.map-6.17.6-200.fc42.x86_64
-rw-r--r--. 1 root root 12M Nov 2 01:00 System.map-6.17.7-200.fc42.x86_64
-rw-r--r--. 1 root root 284K Oct 12 02:00 config-6.16.12-200.fc42.x86_64
-rw-r--r--. 1 root root 287K Oct 19 02:00 config-6.17.4-200.fc42.x86_64
-rw-r--r--. 1 root root 287K Oct 23 02:00 config-6.17.5-200.fc42.x86_64
-rw-r--r--. 1 root root 287K Oct 29 01:00 config-6.17.6-200.fc42.x86_64
-rw-r--r--. 1 root root 287K Nov 2 01:00 config-6.17.7-200.fc42.x86_64
drwx------. 4 root root 4.0K Jan 1 1970 efi/
drwx------. 3 root root 4.0K Nov 11 08:41 grub2/
-rw-------. 1 root root 41M Oct 20 11:18 initramfs-6.16.12-200.fc42.x86_64.img
-rw-------. 1 root root 41M Oct 22 10:14 initramfs-6.17.4-200.fc42.x86_64.img
-rw-------. 1 root root 42M Oct 31 07:50 initramfs-6.17.5-200.fc42.x86_64.img
-rw-------. 1 root root 42M Oct 31 08:36 initramfs-6.17.6-200.fc42.x86_64.img
-rw-------. 1 root root 42M Nov 4 08:49 initramfs-6.17.7-200.fc42.x86_64.img
drwxr-xr-x. 3 root root 4.0K Apr 7 2024 loader/
drwx------. 2 root root 16K Apr 7 2024 lost+found/
lrwxrwxrwx. 1 root root 47 Oct 20 11:17 symvers-6.16.12-200.fc42.x86_64.xz -> /lib/modules/6.16.12-200.fc42.x86_64/symvers.xz
lrwxrwxrwx. 1 root root 46 Oct 22 10:13 symvers-6.17.4-200.fc42.x86_64.xz -> /lib/modules/6.17.4-200.fc42.x86_64/symvers.xz
lrwxrwxrwx. 1 root root 46 Oct 31 07:49 symvers-6.17.5-200.fc42.x86_64.xz -> /lib/modules/6.17.5-200.fc42.x86_64/symvers.xz
lrwxrwxrwx. 1 root root 46 Oct 31 08:35 symvers-6.17.6-200.fc42.x86_64.xz -> /lib/modules/6.17.6-200.fc42.x86_64/symvers.xz
lrwxrwxrwx. 1 root root 46 Nov 4 08:48 symvers-6.17.7-200.fc42.x86_64.xz -> /lib/modules/6.17.7-200.fc42.x86_64/symvers.xz
-rwxr-xr-x. 1 root root 17M Oct 12 02:00 vmlinuz-6.16.12-200.fc42.x86_64*
-rwxr-xr-x. 1 root root 18M Oct 19 02:00 vmlinuz-6.17.4-200.fc42.x86_64*
-rwxr-xr-x. 1 root root 18M Oct 23 02:00 vmlinuz-6.17.5-200.fc42.x86_64*
-rwxr-xr-x. 1 root root 18M Oct 29 01:00 vmlinuz-6.17.6-200.fc42.x86_64*
-rwxr-xr-x. 1 root root 18M Nov 2 01:00 vmlinuz-6.17.7-200.fc42.x86_64*
1GB can be tight for nvidia users, but nothing to panic. Steps to take: slowly reduce number of kernels, remove rescue kernel, which is the size of one to two Fedora kernels.
I think that accumulating so many kernel versions, especially after installing many dependencies belonging to a specific kernel version, such as libperf, can have an impact in certain situations when the system is used for something other than storing kernels in the /boot directory… for example, for complex program compilations, not to mention building specific kernel drivers.
As a last resort, it is worth keeping at most one, older kernel version that did not cause major or practically no problems with starting the system as such – additionally, we have the mentioned --latest-limit=-1 variable in the script I proposed.
Linux itself is such a complex project that the developers of a given distribution don’t even remotely want to create every possible kernel update scenario. And this is where Linux’s greatest strength emerges – you can always do something a little differently – the distribution and its proposed set of programs, scripts, etc. are just one of the possible images of a given distribution that we can or want to use…
am I correct in noticing the nvidia initramfs bloat only occurs with newer RTX GPUs? Because my GTX 1080 system has no such issue, my initramfs is only 38 megabytes.
RTX2080 here:
.rw-------@ 44M root 22 Oct 09:07 initramfs-6.17.4-200.fc42.x86_64.img
.rw-------@ 49M root 28 Oct 17:28 initramfs-6.17.4-300.fc43.x86_64.img
.rw-------@ 48M root 29 Oct 17:09 initramfs-6.17.5-300.fc43.x86_64.img
.rw-------@ 48M root 3 Nov 09:55 initramfs-6.17.6-300.fc43.x86_64.img
.rw-------@ 48M root 7 Nov 16:11 initramfs-6.17.7-300.fc43.x86_64.img
Mine is about 48 MB, but I do strip out the Nouveau drivers from dracut, as I have no need for them/
sudo lsinitrd | grep nvidia | awk '{ sum += $5 } END { printf "Total: %.2f MiB\n", sum/2^20 }'
> Total: 100.82 MiBMaybe my initramfs are small because I’m using the kmod from rpmfusion, so it’s not actually stored in boot but in the rootfs. The folder /lib/modules/6.17.7-200.fc42.x86_64/extra/nvidia is a good 140MB, so that’s a lot of driver not being stored on /boot for me.
Before you start moving 751G of data by an 1GB offset, consider two options
- shrink sdb3 by 2gb and create a new /boot partition and move content from sdb2 to sdb4 (the new partition ), then remove the sdb2 partition, leaving a gap of 1GB unused
- if you want to move sdb3 to the right by 1gb, better shrink the btrfs device first!
it’s only 20% used shrink it, leaving 20-30GB available space, then shrink partition.
example : Partittion 800GB / btrfs used ~20% / 160GB
btrfs fi resize 190 GB /to shrink the filesystem to 190GB. btrfs may need some time to move some data around. change the end of partition to 200GB ( keeping some margins for mistakes ). The size of partition would be 200GB instead of 800GB. and changing the start/offset of sdb3 would require gparted to move 200GB instead of 800GB.
Then you can enlarge the btrfs partition to max and also resize btrfs dev to max
this should have created room to enlarge /boot partition and fs
you have either omited the nouveau driver from the initramfs or removed nvidia-gpu-firmware.noarch
It looks to me like that script was pulled verbatim out of the “Clean-up old kernels” section from the post-upgrade suggestions given in the System-Upgrade documentation. In the context of having just upgraded your system to a new Fedora release, it makes perfect sense. Not in this one, though. It seems that changing that -1 to a -2 would do the trick of giving enough space.
Speaking of that, did anyone else besides me notice that the OP had a kernel from f42 that was a duplicate of one in f43? If they’d have just deleted this one kernel, then they’d have had room to install their default install-only limit of three in /boot.
In this case, this script will also remove this old and identical kernel from F42, so I don’t understand what the problem is…
This script, no matter where it comes from, simply fulfills its role (every possible and expected scenario) and that’s what it’s all about.
I think the issue is that it only leaves the OP with one kernel. Nothing more.
In the present case, changing that -1 to -2 would leave the OP with both kernels from f43. Then they could do their kernel update to achieve their install-only limit of 3, which their /boot partition has room for.
Afterwards, dnf would scroll off the earliest kernel in their stack to maintain that limit.
I don’t know if you noticed, but I wrote about it in both first posts… I don’t understand what the problem is…
I don’t even know how to remove packages or firmware from the initramfs, so it’s not that. nvidia-gpu-firmware is definitely installed too.