NVIDIA drivers not working - "Module nvidia not found."

Ask Fedora
, ,
1

Hello!

Somewhat lengthy topic; this is everything that I’ve tried to get NVIDIA proprietary drivers working on my system.

I’m using an NVIDIA Optimus laptop (Intel UHD 630 + GTX 1650 Max-Q). I’m running Fedora Workstation 36. I initially tried installing the drivers using the CLI initially with dnf install akmod-nvidia, but then attempted to reinstall the drivers via nvautoinstall. The autoinstaller properly detected my graphics cards, and even though it was successfully able to install every package (to my knowledge) it still didn’t end up working on my system:

➜ ~ modinfo -F version nvidia
modinfo: ERROR: Module nvidia not found.

Here is my list of active VGA devices (the command was copied from here):

➜ ~ lspci -vnnn | perl -lne 'print if /^\d+\:.+(\[\S+\:\S+\])/' | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] [8086:3e9b] (rev 02) (prog-if 00 [VGA controller])
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU117M [GeForce GTX 1650 Mobile / Max-Q] [10de:1f91] (rev a1) (prog-if 00 [VGA controller])

I tried forcing the modules to load:

➜ ~ sudo akmods --force
Checking kmods exist for 5.17.5-300.fc36.x86_64            [  OK  ]
Files needed for building modules against kernel
5.17.5-300.fc36.x86_64 could not be found as the following
directories are missing:
/usr/src/kernels/5.17.5-300.fc36.x86_64/
/lib/modules/5.17.5-300.fc36.x86_64/build/Is the correct ke[FAILED]el package installed?
Checking kmods exist for 5.19.8-200.fc36.x86_64            [  OK  ]
➜ ~ sudo dracut --force
➜ ~ uname -r
5.17.5-300.fc36.x86_64

Here are the related packages I have installed (please scroll right to see the repositories and versions):

➜ ~ sudo dnf list installed '*nvidia*' akmods kernel-devel kernel-headers
[sudo] password for nflx: 
Installed Packages
akmod-nvidia.x86_64                                                                                      3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
akmods.noarch                                                                                            0.5.7-8.fc36                                                                      @updates                  
kernel-devel.x86_64                                                                                      5.19.7-200.fc36                                                                   @updates                  
kernel-devel.x86_64                                                                                      5.19.8-200.fc36                                                                   @updates                  
kernel-headers.x86_64                                                                                    5.19.4-200.fc36                                                                   @updates                  
kmod-nvidia-5.19.8-200.fc36.x86_64.x86_64                                                                3:515.65.01-1.fc36                                                                @@commandline             
nvidia-persistenced.x86_64                                                                               3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
nvidia-settings.x86_64                                                                                   3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia.x86_64                                                                               3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-cuda.x86_64                                                                          3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-cuda-libs.i686                                                                       3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-cuda-libs.x86_64                                                                     3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-kmodsrc.x86_64                                                                       3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-libs.i686                                                                            3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-libs.x86_64                                                                          3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-power.x86_64                                                                         3:515.65.01-1.fc36                                                                @rpmfusion-nonfree-updates
➜ ~ sudo inxi -Gxx
Graphics:
  Device-1: Intel CoffeeLake-H GT2 [UHD Graphics 630] vendor: Lenovo
    driver: i915 v: kernel arch: Gen9.5 ports: active: eDP-1 empty: none
    bus-ID: 00:02.0 chip-ID: 8086:3e9b
  Device-2: NVIDIA TU117M [GeForce GTX 1650 Mobile / Max-Q] vendor: Lenovo
    driver: nouveau v: kernel arch: Turing pcie: speed: 8 GT/s lanes: 16 ports:
    active: none empty: DP-1, DP-2, HDMI-A-1, eDP-2 bus-ID: 01:00.0
    chip-ID: 10de:1f91
  Device-3: Chicony Integrated Camera type: USB driver: uvcvideo
    bus-ID: 1-8:3 chip-ID: 04f2:b67c
  Display: x11 server: X.Org v: 1.20.14 compositor: xfwm v: 4.16.1 driver:
    X: loaded: modesetting unloaded: fbdev,vesa gpu: i915 display-ID: :0.0
    screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96
  Monitor-1: eDP-1 model: AU Optronics 0x42eb res: 1920x1080 dpi: 142
    diag: 394mm (15.5")
  OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2)
    v: 4.6 Mesa 22.1.7 direct render: Yes

Oddly enough, I have several different kernel header packages. These might have been left around from previous attempts of installing these drivers, and/or as dependents… See section below.

If it helps, I ended up forgetting to wait 5 minutes before rebooting my system as you should, but after that restart, my PC was on for a long time. If there’s a way to manually trigger whatever that does, that might be a next step.

Here’s one guess I have. Reading through these logs I’ve noticed that I have mismatched kmod versions.

Note this line in sudo akmods --force:

Checking kmods exist for 5.19.8-200.fc36.x86_64            [  OK  ]

And the package list:

kmod-nvidia-5.19.8-200.fc36.x86_64.x86_64                                                                3:515.65.01-1.fc36                                                                @@commandline

My kernel version is 5.17.5-300.fc36.x86_64, according to uname -r, so this might be a mismatched kernel version… I do recall nvinstaller targeting an older version of the drivers for some reason, and then needing to upgrade my system afterwards… I’m not sure if that was an oversight on my part or not. But upgrading that package with my system isn’t an option:

➜ ~ sudo dnf upgrade
Last metadata expiration check: 0:43:47 ago # redacted timestamp
Dependencies resolved.
Nothing to do.
Complete!

And the installer isn’t complaining about anything either:

➜ ~ sudo nvautoinstall driver
[ # ] NVIDIA AUTOINSTALLER FOR FEDORA LINUX
[ ★ ] CHECKING SUPERUSER PERMISSIONS...
[ ✓ ] Superuser privilege acquired
[ ★ ] CHECKING AVAILABILITY OF RPM FUSION NVIDIA REPOSITORY...
[ ! ] RPM Fusion repository for Proprietary NVIDIA Driver was detected
[ ★ ] ATTEMPTING CONNECTION TO RPM FUSION SERVERS...
[ ✓ ] Connection to RPM Fusion servers was established
[ ★ ] LOOKING FOR EXISTING DRIVER PACKAGES...
      xorg-x11-drv-nvidia-kmodsrc-515.65.01-1.fc36.x86_64
      xorg-x11-drv-nvidia-cuda-libs-515.65.01-1.fc36.x86_64
      xorg-x11-drv-nvidia-libs-515.65.01-1.fc36.i686
      xorg-x11-drv-nvidia-libs-515.65.01-1.fc36.x86_64
      nvidia-settings-515.65.01-1.fc36.x86_64
      xorg-x11-drv-nvidia-power-515.65.01-1.fc36.x86_64
      xorg-x11-drv-nvidia-515.65.01-1.fc36.x86_64
      akmod-nvidia-515.65.01-1.fc36.x86_64
      kmod-nvidia-5.19.8-200.fc36.x86_64-515.65.01-1.fc36.x86_64
      nvidia-persistenced-515.65.01-1.fc36.x86_64
      xorg-x11-drv-nvidia-cuda-libs-515.65.01-1.fc36.i686
      xorg-x11-drv-nvidia-cuda-515.65.01-1.fc36.x86_64
[ ! ] A total of 12 driver packages were detected
[ ★ ] REINSTALLING PROPRIETARY DRIVERS...
Last metadata expiration check: 0:52:53 ago
Package gcc-12.2.1-1.fc36.x86_64 is already installed.
Package kernel-headers-5.19.4-200.fc36.x86_64 is already installed.
Package kernel-devel-5.19.7-200.fc36.x86_64 is already installed.
Package kernel-devel-5.19.8-200.fc36.x86_64 is already installed.
Package akmod-nvidia-3:515.65.01-1.fc36.x86_64 is already installed.
Package xorg-x11-drv-nvidia-3:515.65.01-1.fc36.x86_64 is already installed.
Package xorg-x11-drv-nvidia-libs-3:515.65.01-1.fc36.i686 is already installed.
Package xorg-x11-drv-nvidia-libs-3:515.65.01-1.fc36.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[ ✓ ] Driver package installation completed
      Please try executing `nvautoinstall plcuda` with elevated privileges now to install CUDA software
[ ✗ ] Leaving installer
2

Looking through what I have just written, it may be pretty clear what the issue is…

➜ ~ sudo dnf install kernel
[sudo] password for nflx: 
Last metadata expiration check: 1:03:00 ago on Sun 11 Sep 2022 05:46:15 PM CDT.
Package kernel-5.17.5-300.fc36.x86_64 is already installed.
Package kernel-5.19.7-200.fc36.x86_64 is already installed.
Package kernel-5.19.8-200.fc36.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

I’m going to try upgrading my system kernel to match the akmods target version. (Not sure how things got so mismatched in the first place, either.)

3

Okay, so I think I just found the root of the problem.

➜ ~ sudo grubby --default-kernel/boot/vmlinuz-5.19.8-200.fc36.x86_64
➜ ~ uname -r
5.17.5-300.fc36.x86_64

I had a special case with installing the bootloader because of a prior installation of Arch Linux, as well as a dual boot of Windows 11. I needed to manually uninstall a separate bootloader, rEFInd, and reinstall GRUB 2 as a result of having a very different EFI setup. As a result, I haven’t configured my EFI to automatically mount to my OS’s separate local version of /boot/efi, so the vmlinuz isn’t actually updated on my EFI partition…

I think auto mounting my EFI should fix things, so I’ll look into fixing the issue and report back.

4

You definitely have the proper kernel module for the latest kernel built as is shown by the kmod-nvidia package.

You should be able to do the following to verify things are correct.
Using rEFInd may cause an issue since fedora expects to have the uefi partition mounted at /boot/efi, and an ext4 partition mounted at /boot.

Using ls /boot should show several kernel files such as this

$ ls /boot
config-5.19.6-200.fc36.x86_64                            memtest86+-5.31
config-5.19.7-200.fc36.x86_64                            symvers-5.19.6-200.fc36.x86_64.gz
config-5.19.8-200.fc36.x86_64                            symvers-5.19.7-200.fc36.x86_64.gz
efi                                                      symvers-5.19.8-200.fc36.x86_64.gz
elf-memtest86+-5.31                                      System.map-5.19.6-200.fc36.x86_64
extlinux                                                 System.map-5.19.7-200.fc36.x86_64
flask                                                    System.map-5.19.8-200.fc36.x86_64
grub2                                                    vmlinuz-0-rescue-730854f859414ee8ab2aff2cbe878557
initramfs-0-rescue-730854f859414ee8ab2aff2cbe878557.img  vmlinuz-5.19.6-200.fc36.x86_64
initramfs-5.19.6-200.fc36.x86_64.img                     vmlinuz-5.19.7-200.fc36.x86_64
initramfs-5.19.7-200.fc36.x86_64.img                     vmlinuz-5.19.8-200.fc36.x86_64
initramfs-5.19.8-200.fc36.x86_64.img                     xen-4.16.1.config
loader                                                   xen-4.16.1.gz

and sudo ls /boot/loader/entries should show something like this

# ls /boot/loader/entries/
730854f859414ee8ab2aff2cbe878557-0-rescue.conf                730854f859414ee8ab2aff2cbe878557-5.19.7-200.fc36.x86_64.conf
730854f859414ee8ab2aff2cbe878557-5.19.6-200.fc36.x86_64.conf  730854f859414ee8ab2aff2cbe878557-5.19.8-200.fc36.x86_64.conf

Then cat /etc/efi/EFI/fedora/grub.cfg should show something like this

$ sudo cat /boot/efi/EFI/fedora/grub.cfg
search --no-floppy --fs-uuid --set=dev bd615d70-0ff8-42b6-ab38-0a7429b9bb91
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

If those 3 details are not correct then fedora updates are not properly being done and that would explain why you are booting with the default kernel (5.17.5) from the initial install of fedora instead of the current kernel which seems to be installed as you showed with the output of the kmod-nvidia package.

What I would guess is wrong may be that rEFInd overwrote /boot/efi/EFI/fedora/grub.cfg while the fedora updates write to /boot/grub2/grub.cfg.

Recovery is relatively simple as seen here
https://fedoraproject.org/wiki/GRUB_2#Reinstalling_GRUB

and it essentially involves deleting the corrupted grub.cfg files (at both locations) then doing dnf reinstall grub2-efi* grub2-common which will recover for you as long as the file systems are mounted properly.

5

One important detail I left out (before I realized this was a bootloader issue) is that Anaconda was having issues with installing the bootloader, and same with the Ubuntu Boot Repair ISO. I actually ended up removing rEFInd altogether from my EFI so it would fall back to GRUB 2, which I was able to reinstall manually from the live USB.

Note that the Ubuntu Boot Repair process seemed to just idle, so I don’t think it even touched the EFI at all (I’m pretty certain that it wasn’t able to locate it for some reason) - I might be wrong, though, because its boot repair doesn’t give you log information (at least, by default)…

Before I explain more, let me show you what my EFI looks like (scroll for full tree):

/mnt/boot/efi ~ tree
├── $RECYCLE.BIN
│   └── desktop.ini
├── BOOT
│   └── BOOT.SDI
├── EFI
│   ├── Boot
│   │   ├── bootx64.efi
│   │   ├── LenovoBT.EFI
│   │   ├── License.txt
│   │   └── ReadMe.txt
│   ├── fedora
│   │   ├── BOOTIA32.CSV
│   │   ├── BOOTX64.CSV
│   │   ├── gcdia32.efi
│   │   ├── gcdx64.efi
│   │   ├── grubia32.efi
│   │   ├── grubx64.efi
│   │   ├── mmia32.efi
│   │   ├── mmx64.efi
│   │   ├── shim.efi
│   │   ├── shimia32.efi
│   │   └── shimx64.efi
│   ├── GRUB
│   │   └── grubx64.efi
│   ├── Microsoft (files redacted)
│   │   ├── Boot/*
|   |   └── Recovery/*
│   └── tools
├── grub
│   ├── fonts
│   │   └── unicode.pf2
│   ├── grubenv
│   ├── locale
│   │   ├── * Language files
│   ├── themes
│   │   └── starfield
│   │       ├── * All the theme assets here
│   └── x86_64-efi
│       ├── * A bunch of .mod files here
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── mach_kernel
├── System Volume Information
│   ├── EDP
│   │   └── Recovery
│   ├── IndexerVolumeGuid
│   └── WPSettings.dat
└── vmlinuz-linux
  • A lot of these files are remnants from my Arch installation.
  • Most of the installation here was manual. I ended up removing EFI/rEFInd/and adding EFI/fedora/ on my own. This only pertains to the EFI partition on my hard drive, and NOT the one that came with the ISO.
  • I changed the vmlinuz-linux and initramfs files to the updated kernel, but it didn’t affect anything, so I’m assuming Fedora doesn’t use these.
  • Note that this uses grub/ instead of grub2/.

I looked for Fedora’s GRUB config file that should be in the local /boot directory, but it doesn’t exist for some reason. I think that’s the main culprit. I tried reinstalling GRUB 2 as instructed from the wiki (removing the extra config files that I could find in /boot/grub2) but the grub-common script wasn’t called for some reason. (I ended up moving the corrupted .cfg file into a backup directory just to be safe).

So the likely result of this file being missing is that there’s nothing mounted to /boot like there should be. (The mount shown is one I mounted manually):

[root@fedora nflx]# mount | grep boot
/dev/nvme0n1p1 on /mnt/boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

There’s something blocking grub-common from running its config generation, but I don’t know why. What should I do to regenerate my config files?

(Edits: forgot to add some details.)

6

I see that this is getting into bootloader territory rather than driver related issues, so let me know if a new thread should be made for this.

7

Please post the output of lsblk. It seems you do not have the proper content in /boot nor /boot/efi for a proper fedora boot.

This is certainly a boot loader issue, and I will come back and edit this with my suggestions after looking up the solution I found elsewhere.

EDIT:
The solution is posted here and can be summarized with

  1. Boot to the live install media then do the following.
  2. su
  3. identify the installed media root file system then
    mount <your root file system> /mnt
    If this is ext4 then you only need the file system path name.
    If this is btrfs then you will need to format it as UUID=XXXXXX-XXXX-XXXX-XXXXXXXX -t btrfs -o subvol=root,compress=zstd:1 /mnt where the UUID is that of your btrfs root filesystem volume. That UUID can be found with one of the options of lsblk like lsblk -o PATH,FSTYPE,UUID and looking at the fstype and path to confirm it is the installed file system volume.
  4. for part in sys proc run dev ; do mount /$part /mnt/$part ; done
  5. chroot /mnt
  6. mount -a
    this should finish mounting the installed system as it normally is when running.

Now you can begin the recovery as if booted from the installed system.

  1. sudo rm -r /boot/efi/EFI/fedora/* /boot/grub2/grub.cfg
    This will remove all interfering files and allow the next steps to run properly.
  2. cat /sys/firmware/efi
    If this returns cat: /sys/firmware/efi: Is a directory then you have booted from uefi and the remainder should work properly. If not then you have legacy booted and the recovery is different.
  3. dnf reinstall shim* grub2-efi* grub2-common
    This will reinstall the named packages and properly build the content of /boot/grub2, /boot/loader, and /boot/efi/EFI/fedora.
  4. dnf reinstall kernel*
    This should reinstall the latest kernel and rebuild all the modules for it. If this errors then use dnf upgrade --refresh The latest kernel for fc36 is currently 5.19.8.

At this point you should be ready for a proper reboot, so do that and let us know the result.

1 Like
9

Was having issues mounting /sys, /proc and /dev - found an answer on StackOverflow for that though!

10

Although this looked hopeful, unfortunately it didn’t work:

➜ ~ uname -r
5.17.5-300.fc36.x86_64
➜ ~ modinfo -F version nvidia
modinfo: ERROR: Module nvidia not found.

The installation steps worked and everything, though.
I’m not certain, but my theory is that Fedora isn’t using the system EFI partition at all, and it installed GRUB 2 over its own locally provided version on my ext4 partition. So my machine isn’t even working with it, because /boot isn’t mounted from /dev/nvme0n1p1. Hopefully this makes sense.

I’m just learning. This could be wrong for all I know! But I’m pretty sure this is the case, because I seem to recall /boot being auto mounted when I was using Arch Linux.

Here’s my lsblk:

➜ ~ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    1   118G  0 disk               # Live USB
└─sda1        8:1    1   118G  0 part 
zram0       252:0    0     8G  0 disk [SWAP]
nvme0n1     259:0    0 953.9G  0 disk 
├─nvme0n1p1 259:1    0   260M  0 part               # EFI
├─nvme0n1p2 259:2    0    16M  0 part               # Microsoft Reserved
├─nvme0n1p3 259:3    0   441G  0 part               # Windows 11
└─nvme0n1p4 259:4    0 512.6G  0 part /             # Fedora Linux
11

Also, my bootloader file structures look radically different…

➜ ~ ls /mnt/boot/efi  # /dev/nvme0n1p1 - manually mounted EFI partition
'$RECYCLE.BIN'   BOOT   EFI   grub   initramfs-linux-fallback.img   initramfs-linux.img   mach_kernel  'System Volume Information'   vmlinuz-linux
➜ ~ ls /boot/         # Local unmounted version of /boot
config-5.17.5-300.fc36.x86_64  grub2                                                    loader                             System.map-5.19.7-200.fc36.x86_64                  vmlinuz-5.19.8-200.fc36.x86_64
config-5.19.7-200.fc36.x86_64  initramfs-0-rescue-83c455977aa84dc19afd5e653811b190.img  symvers-5.17.5-300.fc36.x86_64.gz  System.map-5.19.8-200.fc36.x86_64
config-5.19.8-200.fc36.x86_64  initramfs-5.17.5-300.fc36.x86_64.img                     symvers-5.19.7-200.fc36.x86_64.gz  vmlinuz-0-rescue-83c455977aa84dc19afd5e653811b190
efi                            initramfs-5.19.7-200.fc36.x86_64.img                     symvers-5.19.8-200.fc36.x86_64.gz  vmlinuz-5.17.5-300.fc36.x86_64
extlinux                       initramfs-5.19.8-200.fc36.x86_64.img                     System.map-5.17.5-300.fc36.x86_64  vmlinuz-5.19.7-200.fc36.x86_64
➜ ~ sudo ls /boot/efi
EFI  mach_kernel  System

I think that’s why a lot of the maintenance I’ve been doing off my EFI partition /dev/nvme0n1p1 has been manual; for some reason, it’s just never been able to mount over /boot on my system.

I’m able to boot into my main system and everything, it’s just weird that it’s not able to auto mount. That’s why I suggested some way to fix it with efibootmgr.

This has been a wild ride so far though, haha. :)
Arch Linux does things much differently, I suppose!

12

Ok, it seems you may have the system installed with / as an ext4 filesystem, in which case it would not automatically create a separate /boot partition, but we need to confirm that.

When booted to the normal file system please give us the output of lsblk -o PATH,FSTYPE,UUID,MOUNTPOINT , ls /boot, ls /boot/grub2, ls /boot/loader/entries and ls /boot/efi/EFI/fedora. Also the output of cat /sys/firmware/efi

If doing that from the live boot media with the / partition mounted at /mnt then add /mnt to the front of each of those commands.

It seems that your output of ls /boot showed that as unmounted and does not contain either the vmlinuz images nor the System-map files.
The properly filled and used for booting version of /boot should contain files similar to this.

$ ls /boot
config-5.19.6-200.fc36.x86_64                            memtest86+-5.31
config-5.19.7-200.fc36.x86_64                            symvers-5.19.6-200.fc36.x86_64.gz
config-5.19.8-200.fc36.x86_64                            symvers-5.19.7-200.fc36.x86_64.gz
efi                                                      symvers-5.19.8-200.fc36.x86_64.gz
elf-memtest86+-5.31                                      System.map-5.19.6-200.fc36.x86_64
extlinux                                                 System.map-5.19.7-200.fc36.x86_64
flask                                                    System.map-5.19.8-200.fc36.x86_64
grub2                                                    vmlinuz-0-rescue-730854f859414ee8ab2aff2cbe878557
initramfs-0-rescue-730854f859414ee8ab2aff2cbe878557.img  vmlinuz-5.19.6-200.fc36.x86_64
initramfs-5.19.6-200.fc36.x86_64.img                     vmlinuz-5.19.7-200.fc36.x86_64
initramfs-5.19.7-200.fc36.x86_64.img                     vmlinuz-5.19.8-200.fc36.x86_64
initramfs-5.19.8-200.fc36.x86_64.img                     xen-4.16.1.config
loader                                                   xen-4.16.1.gz

For some reason the listing you showed us is significantly different.

13

I just noted what you said.
Your efi partition should NOT be mounted over /boot, but rather mounted at /boot/efi.
Please give us the output of cat /etc/fstab as well.

14

Yep, this is correct - I do remember setting / as my root.
I posted everything below - you can scroll through the text below in both directions!

➜ ~ lsblk -o PATH,FSTYPE,UUID,MOUNTPOINT
PATH           FSTYPE UUID                                 MOUNTPOINT
/dev/zram0                                                 [SWAP]
/dev/nvme0n1                                               
/dev/nvme0n1p1 vfat   XXXX-A5DF                            /mnt/boot/efi
/dev/nvme0n1p2                                             
/dev/nvme0n1p3 ntfs   XXXXXXXXXXBDCC9A                     
/dev/nvme0n1p4 ext4   xxxxxxxx-xxxx-xxxx-99bd-a745922edadf /

# /boot is the locally installed boot directory, not the mounted one.

# Scroll this text area to the right to see more files,
# including the /boot/vmlinuz-* files.

[root@fedora nflx]# ls /boot
config-5.17.5-300.fc36.x86_64  grub2                                                    loader                             System.map-5.19.7-200.fc36.x86_64                  vmlinuz-5.19.8-200.fc36.x86_64
config-5.19.7-200.fc36.x86_64  initramfs-0-rescue-83c455977aa84dc19afd5e653811b190.img  symvers-5.17.5-300.fc36.x86_64.gz  System.map-5.19.8-200.fc36.x86_64
config-5.19.8-200.fc36.x86_64  initramfs-5.17.5-300.fc36.x86_64.img                     symvers-5.19.7-200.fc36.x86_64.gz  vmlinuz-0-rescue-83c455977aa84dc19afd5e653811b190
efi                            initramfs-5.19.7-200.fc36.x86_64.img                     symvers-5.19.8-200.fc36.x86_64.gz  vmlinuz-5.17.5-300.fc36.x86_64
extlinux                       initramfs-5.19.8-200.fc36.x86_64.img                     System.map-5.17.5-300.fc36.x86_64  vmlinuz-5.19.7-200.fc36.x86_64

[root@fedora nflx]# ls /boot/grub2/
fonts  grubenv

[root@fedora nflx]# ls /boot/loader/entries
83c455977aa84dc19afd5e653811b190-0-rescue.conf                83c455977aa84dc19afd5e653811b190-5.19.7-200.fc36.x86_64.conf
83c455977aa84dc19afd5e653811b190-5.17.5-300.fc36.x86_64.conf  83c455977aa84dc19afd5e653811b190-5.19.8-200.fc36.x86_64.conf

[root@fedora nflx]# ls /boot/efi/EFI/fedora
BOOTIA32.CSV  BOOTX64.CSV  gcdia32.efi  gcdx64.efi  grubia32.efi  grubx64.efi  mmia32.efi  mmx64.efi  shim.efi  shimia32.efi  shimx64.efi

[root@fedora nflx]# cat /sys/firmware/efi
cat: /sys/firmware/efi: Is a directory

[root@fedora nflx]# cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu Sep  8 09:40:40 2022
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=xxxxxxxx-xxxx-xxxx-99bd-a745922edadf /                       ext4    defaults        1 1

Whoops, my bad. Thanks, that makes sense.

I happen to have a backup of my old /etc/fstab from Arch Linux:

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# (This is my old Arch Linux partition, which is now overwritten by Fedora.)
# /dev/nvme0n1p4
UUID=xxxxxxxx-xxxx-xxxx-2cc909cd1e80	/         	ext4      	rw,relatime	0 1

# This is my EFI partition.
# /dev/nvme0n1p1 LABEL=SYSTEM
UUID=xxxx-A5DF      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

It’s now my presumption that I could just add the /boot partition to fstab to fix the issue, and then reinstall GRUB 2 again to see if that fixes the issue… I’ll need to look into it!

15

Your /etc/fstab should have 2 lines for the OS similar to

UUID=xxxxxxxx-xxxx-xxxx-2cc909cd1e80	/         	ext4      	defaults  0 1
UUID=xxxx-A5DF          /boot/efi               vfat    umask=0077,shortname=winnt 1 1

If you have a separate unmounted /boot partition it could be added similar to the line for / . That is not needed since the / filesystem is ext4 and the output of lsblk does not show an extra partition for /boot. In fact ls /boot does show all the needed files in /boot.

Once that is done and the system booted that way then the steps I showed above for reinstalling grub should be done, as well as sudo dnf reinstall kernel* and it should work properly. Only one other thing might be needed to tell the bios to boot grub properly and that is to run efibootmgr -c which will tell the bios that grub is the boot loader.

If it cannot be booted that way then the mount from the live media and the chroot to the mounted file system then follow those steps to reinstall grub and to reinstall the kernel.

Since the root file system is ext4 and all the needed files show in /boot it is not necessary to add the extra /boot partition but simply to mount the efi partition to /boot/efi and it should be good to go. (Again after doing the reinstalls noted above.) The reinstalls will cause fedora to rebuild all the needed grub boot loader files.

16

So far so good! After adding an entry in fstab, it auto-mounts now, which is great:

➜ ~ mount | grep /boot/efi
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)

However, I don’t think the GRUB directory is being modified in the EFI upon reinstallation… It seems completely untouched when reinstalling the GRUB packages. If I remove that folder or the config there altogether, it’s not being regenerated.

[root@fedora nflx]# ls /boot/efi/
'$RECYCLE.BIN'   BOOT   EFI   grub   initramfs-linux-fallback.img   initramfs-linux.img   mach_kernel  'System Volume Information'   vmlinuz-linux
[root@fedora nflx]# ls /boot/efi/grub/
fonts  grub.cfg  grubenv  locale  themes  x86_64-efi

Also, I’m getting this error with efibootmgr, possibly suggesting that it can’t access and/or detect the NVRAM of my PC:

➜ ~ sudo efibootmgr -c --verbose
Could not prepare Boot variable: No such file or directory
17

Looks like I’ll need more flags for efibootmgr to make an entry - will look into it!

18

Yep, my suspicions are correct:

[root@fedora efi]# cd grub/
[root@fedora grub]# date -r x86_64-efi/
Wed Aug 31 08:43:18 AM CDT 2022
[root@fedora grub]# date -r grubenv 
Wed Aug 24 03:29:58 AM CDT 2022

The grub/ folder is the GRUB from my old install which the PC is booting from, meaning I need to somehow get GRUB2 to install side by side (ie. to even generate in the first place).

I’m going to have to give the EFI installation docs a solid read.

(Sorry for all the post edits; it’s a bad habit. :sweat_smile:)

19

Yeah, looks like I’m a bit stuck here:

[root@fedora nflx]# efibootmgr --create --disk=/dev/sda --part=1 --label="fedora" --loader="EFI\fedora\grubx64.efi"
Could not prepare Boot variable: No such file or directory

I think GRUB 2 is misconfigured, but I don’t know exactly why.

20

I see a couple of options:

  • Move forward with trying to debug GRUB 2 (go through the live disk, reinstall the GRUB configs and see where my boot partition is detected on its side), because for some reason I’m not able to detect Fedora off of my main partition. Not sure why… And then from there maybe I can get an idea of what’s going wrong.
  • Add Fedora’s EFI/fedora/grubx64.efi to my current GRUB 1 bootloader that exists. Maybe I could point it with grub-mkconfig, but I know this is not a good idea to try on Fedora…
  • Reinstall rEFInd and try to maintain that.
21

I beg you to please back up and take things one step at a time.

You can easily recover what is needed by grub with posting the output of efibootmgr and let us see what it tells you. There may easily be something hanging on in efi that is confusing the boot, but efibootmgr can tell us that.

A full 100% recovery of grub is quite possible if needed with 3 simple steps now that you have the efi partition properly mounted at /boot/efi.

  1. sudo rm /boot/grub2/grub.cfg /boot/efi/EFI/fedora/*
  2. sudo dnf reinstall shim* grub2-efi* grub2-common
  3. Wait at least 5 minutes after the reinstall completes then reboot.

Fedora grub should be able to properly boot as long as the efi boot picks the proper loader and that can be seen from the grub boot menu. Getting the efi to pick the proper boot device is the reason for running efibootmgr so you can see and select which device to boot from.

1 Like