QuickDocs > Kernel and Booting
Uhm, okay . . .
Exit, Logout, Restart, CTRL-S to view Grub menu.
GRUB version 2.12
Fedora Linux (6.19.14-106.fc42.x86_64) 42 (Workstation Edition)
Fedora (0-rescue- 30 WorkStation Edition
Memory test (memtest86+64.efi)
System setup
Mark, SUCCESS. F38 no longer appears in the Grub Menu.
Upgrading Fedora Linux Using DNF System Plugin
( Pardon my dnf command[ s ]. I think I broke my Sudo ).
# dnf offline reboot
( I’ll be back )
" System is not ready for offline transaction "
# dnf clean packages
# dnf check-update
# dnf upgrade --refresh
" Complete ! ", BUT with an SELinux notification . . .
Okay, that SELinux notification may [ or may not ] be useful to Fedora.
There is one more thing I could do [ tomorrow ]. That is, fall back to my initial Fedora 42 Backup Image.
A note about my Work Flow : My GNOME software store setting for Updates is always DISABLED because I always want to do BACKUPS-BEFORE-UPDATES. That’s my best practice and has served me well.
So, I can start over, just remove the F38 Kernel using Mark’s method, run the Update commands, run the Upgrade commands.
I’ll try to plan the steps, on paper, for my next lab session. Maybe the SE Linux notification will go away / disappear.
If so, this could be a SOLUTION [ and then a reproducible solution ].
Also, I would like to review that article by Dre Dyson . . .
I had the same issue when I was trying to update one of my laptops to 43 when 43 was released. One thing nobody has mentioned here is that the upgrade from 42 to 43 includes a bigger boot partition (from 1GB to 2GB) which I don’t believe you can do unless you upgrade (I think I tried using the partition manager in a Live session to resize from memory unsuccessfully).
But I also had on a mini PC a black screen when I tried updating from 42 to 43. So while it might be nice to try and fix this install, think about the time it’s going to take compared to just doing a backup of your files and doing a fresh install? I spent days trying to fix one of my installs compared to about an hour for a new install with everything up and running again.
Easier and more effective with sudo dnf remove kernel*6.8.9* since that will remove all the related packages cleanly.
Using that command to remove kernel-core does not remove the kernel meta package, nor does it remove any other user installed kernel packages such as kernel-devel that may not depend upon the kernel-core package.
Upgrade does not require the larger boot partition nor does it fail unless the /boot file system is really tiny. A new installation automatically creates the larger size /boot.
The reason for the larger boot partition was that at one point dracut was building excessively large initramfs images and the quick solution was making the boot partition larger. That issue with the image size has been overcome and now is no longer a strict requirement. As you can see I have only a 1GB /boot and it is only about half full with 3 kernels plus the rescue kernel.
$ lsblk -f /dev/nvme0n1
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat FAT32 52B5-5EC4 470M 4% /boot/efi
├─nvme0n1p2 ext4 1.0 c4eb1f4d-eaab-4b8a-a952-302402d8844d 551.4M 46% /boot
└─nvme0n1p3 LVM2_member LVM2 001 l81PQ1-jP4v-u4jv-mXAN-B7dy-X0Tf-SOaUr5
├─fedora_root-root ext4 1.0 f17f245b-7d9f-4315-8c12-a555c37ca0e2 243.1G 33% /
Not true.
$ dnf remove kernel-core-7.0.9-202.fc44
Package Arch Version Repository Size
Removing:
kernel-core x86_64 0:7.0.9-202.fc44 @commandline 99.1 MiB
Removing dependent packages:
kernel x86_64 0:7.0.9-202.fc44 @commandline 0.0 B
kernel-modules x86_64 0:7.0.9-202.fc44 @commandline 99.5 MiB
kernel-modules-core x86_64 0:7.0.9-202.fc44 @commandline 72.9 MiB
kernel-modules-extra x86_64 0:7.0.9-202.fc44 @commandline 4.4 MiB
kmod-nvidia-7.0.9-202.fc44.x86_64 x86_64 3:595.71.05-1.fc44 @commandline 10.5 MiB
Transaction Summary:
Removing: 6 packages
it does not remove kernel-devel, you have to expl. remove that if you don’t need it anymore.
The OP’s system not needs NVIDIA and Akmod. I guess Kerenel Devel is also not needed.
OP is challenging him selves and the Hardware to maintain it as it is. He knows the options.
I was mentioning this because the OP was about the boot partition running out of space and that 43 has the larger boot partition (2GB) compared to 42 which has 1GB. Doing an upgrade won’t change that and a new install is needed to do it. Correct that It’s not needed if your current install updates without issue. I had one particular laptop that always ran out of room on the boot partition with 42 and constantly having to manually remove older kernels before each update. Three other PCs and laptops I have work fine with the 1GB boot partition as well.
Peter :
Am I out of /boot space ?
EXTERNAL REFERENCE : by Dre Dyson
Advanced Fedora 42 Upgrade Black Screen Fix
STEP # 19 : Check Your /boot Partition Size
The error above is about boot/efi this is a 600mb partition.
df /boot/efi -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 599M 21M 579M 4% /boot/efi
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 232,9G 0 disk
├─sda1 8:1 0 600M 0 part /boot/efi
├─sda2 8:2 0 2G 0 part /boot
└─sda3 8:3 0 230,3G 0 part /home
/
zram0 251:0 0 8G 0 disk [SWAP]
You certainly do not appear to be out of space in either /boot or /boot/efi at present.
You appear to be using LVM for / and /home.
Please show us the output of df -h so we can see the space in all file systems.
Note that LVs are quite flexible and can be easily adjusted for size with just a few commands, so if either of those file systems are nearly full it is not difficult to adjust the sizes to allow more space where needed.
@amanti you can cut and past text if you choose the </> symbol in the editor.
Then you get that, pre-formatted text. This way we also can find information
when we do a search. Graphics are not searchable.
DRAFT PROCEDURE, Sunday - May 25, 2026 @ 3:00 Pm CT.
STEP # 001 : Observation Fedora 42 Upgrade Black Screen
Although Fedora is very much like a full production environment, there are no guarentees in life . . . only probabilities. You are responsible for your own system integrity.
STEP # 002 : What’s your name ?
Look at your notes.
What is your [ Clonezilla ] Image File Name for the most recent backup, i.e. before executing Dnf UpDate commands ?
Make a note of it.
STEP # 003 : Restore The Named Image File
Then power-down and Disconnect the Backup HDD.
STEP # 004 : Verify Firmware Repository setting is Colored Gray [ DISABLED ].
Gnome GUI > Software [ Shopping bag icon ] > Hamberger > Software Repositories
STEP # 005 : Verify Software Update “Manual” setting radio button is Blue.
Gnome GUI > Software [ Shopping bag icon ] > Hamberger > Preferences
STEP # 006 : Observation of Grub Menu
Exit all applications. Logout. Restart. CTRL-S.
Make a note of it.
* Fedora Linux (6.8.9-100.fc38.x86_64) (Workstation Edition
Fedora (0-rescue<LONGNUMBER> 30 (Workstation Edition)
Memory test
System setup
STEP # 007 : Observation of a Grub menu entry to a Fedora 38 Kernel
Make a note of it.
Then continue by pressing the keyboard Return key.
STEP # 008 : Am I out of /boot space ?
# df -h /boot
# df -h /boot/efi
# lsblk
# df -h
STEP # 009 : Verify MACHINEID directory does NOT exist.
Post # 5 by Jeff says “There should NOT be a /boot/efi MACHINEID directory” . Reference MACHINEID
# ls -d “/boot/efi/$(cat /etc/machine-id)”
STEP # 009.1 : Otherwise, a temporary workaround : Move Directory . . .
# mv “/boot/efi/$(cat /etc/machine-id)” “/boot/efi/$(cat /etc/machine-id)_disabled”
STEP # 10 : Apply Workarounds
STEP # 010.1 : Removing the rescue kernel
STEP # 010.2 : Reducing the number of installed kernels
STEP # 010.3 : If rpm -q kernel == 3
# rpm -q kernel
kernel-6.8.9-100.fc38.x86_64
kernel-6.17.10-100.fc41.x86_64
kernel-6.19.8-100.fc42.x86_64
root@localhost:/etc/dnf/libdnf5.conf.d#
root@localhost:/etc/dnf/libdnf5.conf.d# uname -r
6.8.9-100.fc38.x86_64
root@localhost# dnf remove kernel*-kernel-6.8.9-100.fc38.x86_64*
No packages to remove for argument: kernel*-kernel-6.8.9-100.fc38.x86_64*
Package Arch Version Repository Size
Removing:
kernel x86_64 6.17.10-100.fc41 updates 0.0 B
kernel-core x86_64 6.17.10-100.fc41 updates 96.6 MiB
kernel-modules x86_64 6.17.10-100.fc41 updates 95.2 MiB
kernel-modules-core x86_64 6.17.10-100.fc41 updates 68.1 MiB
kernel-modules-extra x86_64 6.17.10-100.fc41 updates 4.2 MiB
Transaction Summary:
Removing: 5 packages
After this operation, 264 MiB will be freed (install 0 B, remove 264 MiB).
Is this ok [y/N]: y
Running transaction
[1/6] Prepare transaction 100% | 9.0 B/s | 5.0 B | 00m01s
[2/6] Removing kernel-0:6.17.10-100.fc41.x86_64 100% | 14.0 KiB/s | 100.0 B | 00m00s
[3/6] Removing kernel-modules-extra-0:6.17.10-100.fc 100% | 6.0 B/s | 122.0 B | 00m19s
[4/6] Removing kernel-modules-0:6.17.10-100.fc41.x86 100% | 562.0 B/s | 2.4 KiB | 00m04s
[5/6] Removing kernel-modules-core-0:6.17.10-100.fc4 100% | 6.2 KiB/s | 3.2 KiB | 00m01s
[6/6] Removing kernel-core-0:6.17.10-100.fc41.x86_64 100% | 19.0 B/s | 17.0 B | 00m01s
Complete!
root@localhost:/etc/dnf/libdnf5.conf.d#
Remove A Kernel, fc38, using Mark’s Method, post # 40
STEP # 010.4 : Install an fc42 kernel
# dnf upgrade kernel* --releasever=42
Post # 35 from Jeff says to do . . .
# dnf upgrade kernel\* --releasever=42
root@localhost:~# dnf upgrade kernel\* --releasever=42
Updating and loading repositories:
Repositories loaded.
Nothing to do.
root@localhost:~#
STEP # 010.5 : Run Dnf UpDate commands on the command line.
# dnf clean packages
# dnf check-update
# dnf upgrade --refresh
Reboot
STEP # 010.5 : Verify Workarounds
According to my handwriten notes after doing Dnf UpDate commands, the fc42 kernel automatically appeared in the Grub Menu, I think.
( I’m retesting this )
Then Restart ? Yes. Exit all applications. Logout. Restart.
CTRL-S to view the Grub Menu
# uname -r
STEP # 011 : Observation of Grub Menu
Exit all applications. Logout. Restart. CTRL-S.
Make a note of it.
STEP # 012 : Verify SUCCESS.
The Grub Menu entry to Federal 38 Kernel no longer appears.
Then continue by pressing the keyboard Return key.
STEP # 013 : Verify Booted Kernel
uname -r
It should be a Fedora 42 Kernel.
Make a note of it.
STEP # 014 : System Details
Gnome GUI > * icon [ Settings ] > System > About > System Details
It should match your note from the previous step.
STEP # 015 : Am I out of /boot space Now ?
# df -h /boot
# df -h /boot/efi
# lsblk
# df -h
Clarification . . .
Post # 38, STEP # 17 . . .
What I did here [ as revealed by the screen capture ] is . . .
# dnf remove kernel-6.8.9-100.fc38.x86_64
However, STEP 18 : View the Grub Menu failed; fc38 was still there as a menu entry.
That’s when I jumped to Post # 40 from Mark and found SUCCESS; fc38 no longer appeared in the Grub Menu.
Following this Workaround .
I succeeded at this once.
Now, I a’m Re-Trying [ to create a high quality procedure ] like . . .
-
Apply the workaround.
-
Run the DNF UpDate commands.
-
Verify the Workaround was successful.
My Re-Tries are unsuccessful.
Do I need to deviate from that Workaround in any way ?
Any additions [ or omissions ] ?
When I am honest, I lost a bit the overview of the Issue you have.
If you not have the black screen anymore, you might start a new topic and tell us where exactly you get stuck. In the end you already marked a solution.
If I do understand you correctly F42 works when you not try to upgrade, right?
You probably also give us once the information as described here Inxi | the help to help your selves .This way we can exclude some hardware issues you might have.
I didn’t click a button indicating this is solved.
I restored and I’m starting over to see if the steps can be repeated, cleanly. Then it’s a solution that is repeatable.
( This is not a hardare issue ).
Anyway at least to see your information would make it easier to give you support.
The ask fedora section is meant to use like a Q&A section on which users make a question about an issue an we help to solve that issue and then mark the topic with it.
Normally we try to do per issue one topic to avoid to long request. Users like to find fast a solution, this is not possible when the Topics get to long.
The results from inxi -Fzxx posted as text can be found by other Linux community members with similar hardware. Sometimes topics here are found by users of other distros who have similar hardware and issues, and some of them can suggest solutions.
Even when hardware works as designed, there are often firmware bugs because vendors don’t put much effort into linux support and only respond when issues are reported to them. Linux has gone full cycle from widely used standards to distro’s going in different directions, but now converging due to the threat environment forcing rapid adoption of what kernel.org provides combined with an influx of new users combined with AI web scrapers straining distro file server capacity.