This is a discussion topic for the following Common Issue:
You can discuss the problem and its solutions here, but please note that debugging and technical feedback should primarily go to the issue trackers (e.g. Bugzilla) linked in the Common Issue, because that’s the place that developers watch, not here.
If there are any updates/changes/amendments for the Common Issue description, which you believe should be performed, please post it here.
Please see the Common Issue for solution/workarounds:
I don’t see into the deep technical details here. Perhaps someone else can answer.
As far as I can see, dracut is already doing that. If you don’t include nvidia in the intrd, the corresponding firmware isn’t included either.
I don’t understand why a separate /boot is needed alongside /boot/efi when / can be any size and not have a small /boot limit (I’d rather have initrd take up 200MB within a 900G / without additional space, vs 200MB on a 1-2G partition with the rest of the partition unused, on-top of the larger-than-needed /boot/efi that would likely only have a tiny .efi)
I get the sense it’s related to recovery or protection against failed updates, but don’t people with the smaller /boot need to reinstall or potentially mess something up with resizing it?
Yeah this works F43; 260M /boot/efi (likely oversized with only 20M use), /boot part of / that’s any large size:
/dev/nvme0n1p2 xfs 954G 61G 893G 7% /
/dev/nvme0n1p1 vfat 248M 20M 229M 8% /boot/efi
I did a Workstation install and 700+ package updates, but didn’t see that efi size change so I’m thinking that could be smaller (Windows has 100M minimal I think?)
Edit: 64M at install-time works fine for /boot/efi! (that might be the minimal to pass the partition check; 32M didn’t work)
I think it would make sense at this point to split the nvidia-gpu-firmware package in two packages. One package has the required files for Turing GPUs (RTX 20*0) and older. The second package include files for the new GPUs (RTX >= 30*0 ).
The FW files for the current bunch of cards are significantly larger compared to the Turing GPUs.
Turing:
ls -lh tu102/gsp/gsp*
-rw-r--r--. 1 root root 13M Oct 21 02:00 tu102/gsp/gsp-535.113.01.bin.xz
-rw-r--r--. 1 root root 13M Oct 21 02:00 tu102/gsp/gsp-570.144.bin.xz
Ampere
ls -lh ga102/gsp/gsp-5*
-rw-r--r--. 1 root root 25M Oct 21 02:00 ga102/gsp/gsp-535.113.01.bin.xz
-rw-r--r--. 1 root root 49M Oct 21 02:00 ga102/gsp/gsp-570.144.bin.xz
Hi,
you could use “gparted”. I had the same problem: /boot (0.5 GB) was full. Yes, the workaround: delete useless files - for example kernel rescue (I had never need it) work, but there is relatively simple solution: parted or gparted: move another partition of system HDD (SSD etc..).
Fedora 19 introduced dracut host-only mode precisely to address initramfs bloat:
Current initramfs images contain most of the kernel drivers to boot from any hardware. This results in a very big initramfs, which takes a long time to load on system start and a long time to create on kernel updates. Switching to host-only will improve the situation.
That doesn’t work for LVM encrypted / systems.
I think the default partition layout needs to be changed. Resizing and/or recreating /boot is much easier if the installer had created the btrfs partition first and then the /boot partition.
something like this could work even online ( not tested)
1. btrfs fs resize -5G / # create some margins for mistakes
2. update partition table for /btrfs ( move end of partition by 1GIB )
3. partprobe -s
4. umount /boot/efi /boot
5. dd if=/dev/nvmexxxxx of=backup_boot_on_filesystem # dump boot
6. delete and recreate partition for /boot
7. partprobe -s
8. dd if=backup_boot_on_filesystem of=/dev/nvmexxxxx
9. resize2fs /dev/nvmexxxxx
10. mount /boot && mount /boot/efi
11. btrfs fs resize max /
That’s also the lesson MS have learnt with their windows recovery partition. WIn7 created the recovery partition before the main system partition. Later versions created the main partition first. Many times the recovery partition needed to be enlarged. Otherwise updates for the WinRE env failed to install.
for VM installations it’s better to have /boot first then the btrfs partition. It’s easier to resize the virtual disk and extend the btrfs partition if needed.
as long as legacy BIOS/MBR is supported by Fedora, this isn’t really possible. Some older BIOS firmwares aren’t able to read sectors towards the end of large disks.
backup your system, recreate the partitions from scratch would be my way to go. Also, what about LVM-encrypted volumes or other fs like ext4 and xfs?
true, this may not be an option for legacy systems.
Not really, this should easily be possible with a live image.
I have successfully done similar things several times online with RHEL7 and newer.
RHEL6 would not update the kernel partition table when toying with the root vg partition. Reboot was required.
Have also migrated several TB with dd on old HP-UX clusters from SCSI connected raids to ‘newer’ fc raid systems. Often the LVM VGs had outdated default parameters and would not allow to extend the VG and other stuff. It was often easier and faster to migrate the data with dd during a weekend downtime.
does it really matter? This is about the default btrfs based partition layout.
Hello Everyone,
I have posted an enquiry regarding ‘initramfs’ on thread Fedora 43 KDE: Black screen with underscore after LUKS passphrase
Can I safely remove the three oldest kernels and then regenerate ‘initramfs’ for the fc43 kernel ?
The boot directory seems to refer only to the fc38 kernel, which may be the cause of my problem.
Thanks for any ideas, suggestions.
This document describes your manual and effective method for clearing space in the
/boot partition on Fedora using the Midnight Commander utility (mc).Manual Method to Free Up Space in the /boot Partition on Fedora
This procedure leverages the Midnight Commander (mc) file manager to safely identify and remove old kernel versions, ensuring system updates can proceed without “out of space” errors.
Use the code with care.
Prerequisites
terminator).sudo).Detailed Steps
First, install mc to facilitate navigating and deleting files within the terminal:
bash
sudo dnf install mc -y
Use the code with care.
It is crucial to know which kernel version the system is currently using right now to ensure you do not accidentally delete it:
bash
uname -a
Use the code with care.
Example Output:
Linux hostname 6.17.12-300.fc43.x86_64 ...
Note down the exact version number. In this example, the version to be kept is 6.17.12-300.fc43.x86_64.
/boot Partition with mcOpen mc directly in the /boot directory using root privileges:
bash
sudo mc /boot
Use the code with care.
Inside mc, navigate through the files and use the F8 key to mark files for deletion.
What must be kept (do not delete):
Keep all files that contain the kernel version number noted in Step 2 (e.g., 6.17.12-300). This includes:
vmlinuz-* (and corresponding System.map, config, symvers, initramfs files)Furthermore, always retain the rescue files:
rescue in the name.
IMPORTANT SAFETY NOTE:
The ideal practice is to always keep at least two functional kernels (the current one in use and the immediate previous one), in addition to the rescue image. This serves as a contingency plan: if the primary kernel fails after an update or for any other reason, you can reboot using the previous kernel or the rescue image to diagnose and fix the problem.
What should be deleted:
Delete all files belonging to older kernel versions that exceed the minimum number of safe kernels you wish to retain.
Use F8 to delete the old files. mc will ask for confirmation before deletion.
After freeing up space, you can proceed with your system updates. When it is time to reboot, you will know exactly which entry to select in the GRUB menu to ensure a safe boot:
6.17.12-300);