EFI boot partition full, BIOS upgrade fails, owing to oversize amdgpu.ko.xz on Intel (amdgpu unused)

Ask Fedora
, , , , , , , ,
1

After upgrade to recent kernels, the amdgpu module ends up being enormous :

[root@host:/lib/modules/6.9.12-600.fc40.x86_64/kernel]# find . -name ‘amdgpu’ -ls
368973 4 drwxr-xr-x 2 root root 4096 Jul 29 02:24 ./drivers/gpu/drm/amd/amdgpu
296071 4572 -rwxr–r-- 1 root root 4674112 Jul 28 01:00 ./drivers/gpu/drm/amd/amdgpu/amdgpu.ko.xz

That’s an XZ compressed size 4.6MB for just the amdgpu module ! The nouveau module is @ 2MB -
they both uncompress to something enourmous (> 2GB for amdgpu).

And I don’t even use it, since my system is an Intel (from /proc/cpuinfo) :

processor : 11
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Core™ i7-9750H CPU @ 2.60GHz
stepping : 10
microcode : 0xf4

lspci | egrep ‘VGA|NVID’

00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630]
01:00.0 3D controller: NVIDIA Corporation TU117M [GeForce GTX 1650 Mobile / Max-Q] (rev a1)

My /boot/efi/EFI/ partition became too full:

ls -la ${PWD}/*$(uname -r).efi

-rwx------. 1 root root 58601472 Jul 29 02:22 /boot/efi/EFI/Linux/af19f43bc05746859621afad3f48dd99-6.9.12-600.fc40.x86_64.efi

My Boot disk :

fdisk -l /dev/nvme0n1

Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: PC601 NVMe SK hynix 512GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CD1261DD-F34B-46D4-85FE-7515E82955F7

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 370687 368640 180M EFI System

df .

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/nvme0n1p1 180224 129418 50806 72% /boot/efi

My initramfs ends up becoming huge :

-rw-------. 1 root root 175740374 Jul 30 23:34 initramfs-0-rescue-af19f43bc05746859621afad3f48dd99.img

In order to write that EFI/Linux/ file, I had to remove :
# ls -l ${PWD}/Dell/bios/recovery/
total 0
-rwx------. 1 root root 0 Jul 29 05:09 tmp.rcv

# ls -l ~/BIOS*

-rwx------. 1 root root 18922047 Mar 16 21:38 /root/BIOS_CUR.RCV
-rwx------. 1 root root 18925478 Nov 9 2023 /root/BIOS_PRE.rcv

So now after BIOS Update initiated by ‘GNOME Software’, the BIOS reset itself to defaults,
I had to redo all my BIOS settings, including the ones disabling Windows RAID and enabling
SATA AHCI Mode, to make the boot disk visible again .

Please, can you try to keep the boot kernel small - there is no reason it should need to load the GPU
just for booting - why not exclude all GPU modules from EFI boot kernel, have them loaded
by dracut from initrd if needed ?

My EFI partition is now too full to support BIOS backups, it is the first partition, all other partitions
are quite full, I can’t easily expand it / move all other partitions down, can’t the BIOS be told to
use a USB stick or something for BIOS Backups during Flash ? I don’t see how …
Every time I need to do a BIOS update now , the update will succeed, but it resets
to BIOS default settings because no settings were stored in any backup …

Thanks, Best Regards,
Jason

3

You don’t need to mount /boot/efi as it’s only used by the mobo to boot, the o/s doesn’t need it or use it, fedora only mounts it for grub package updates convenience.

$ cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Mon Aug 14 14:44:00 2023
#
# 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=fea3e966-0bc4-4f20-82ce-29c1edc7578e /                       ext4    defaults        1 1
UUID=5a5317e7-ef7e-4272-b289-df57b37aa1f6 /boot                   ext4    defaults        1 2
#UUID=F538-80A4                            /boot/efi               vfat   x-systemd.automount,noauto 0 1
UUID=c74fb059-7e23-4055-a52a-9d23eb22be2a /var/kvm1               ext4    defaults        0 2
#UUID=50ee067a-928e-4844-a1d3-530ad2307188 /var/kvm2               ext4    defaults        0 2
/dev/nvme1n1p1                            /var/kvm2               ext4    defaults        0 2
#/dev/nvme0n1p9                            /var/kvm2               ext4    defaults        0 2
UUID=76bbd3b6-dfc6-4489-bee2-4dc371708e1f /var/lib/mock           f2fs    defaults        0 2
UUID=566f7281-3501-4822-80b8-018222a116a2 /home                   ext4    defaults        0 2
#UUID=3a00d179-9c86-43a0-87a2-fed4dad7cdb5 none                    swap    defaults        0 0
UUID=2440c679-aa48-4e02-a400-715d85c1d0f2 /home/leigh/data1       ext4    defaults        0 2
UUID=02f8f890-6870-44b5-9cdc-ddfaf099f135 /home/leigh/data2       ext4    defaults        0 2
UUID=6843a9f2-0adb-423f-92ac-241853595344 /home/leigh/development ext4    defaults        0 2
UUID=68ac19ba-1df8-488e-bf4a-c54ec6675734 /home/leigh/qBT_dir     ext4    rw,noatime      0 2
4

That’s not a “solution” !

Any Kernel I install with ‘kernel-install add’ will attempt to write the /boot/EFI/efi/Linux/${UEFI_PE_NAME} PE Executable EFI boot kernel , regardless of whether /boot/EFI is mounted or
not .

In order to make my ‘rpm -ivh kernel-6.9.12-600.fc40.x86_64.rpm’ command succeed, which
uses ‘kernel-install’, I had to remove my BIOS Backup Files.

That file ends up being too large, is all I am saying . I think excluding the huge GPU modules
from it might fix. The amdgpu.ko module started becoming huge in linux v6.6+, I think .

Please make the EFI Kernel Smaller !

5

You might find this blog post interesting:

6

Thanks, most interesting and informative.

I will try excluding amdgpu from my next kernel build .

Incidentally, anyone know how to disable the Kernel Character → Video mode switch completely during
boot ? Boot argument : ‘rhgb=no’ doesn’t seem to do it anymore.

All the best,
Jason

7

Maybe sudo plymouth-set-default-theme --rebuild-initrd details is what you are looking for? I’m not sure.

Alternatively, the plymouth.enable=0 kernel parameter might be what you want.

8

After adding :
# cat /etc/dracut.conf.d/omit-gpu-drivers.conf
omit_drivers+=" amdgpu radeon nouveau i915 "
# grep CMDLINE /etc/default/grub
GRUB_CMDLINE_LINUX="resume=UUID=939af7c3-8bc1-408d-939b-89614b264bf5 rd.lvm.lv=LNX_ROOT/FEDORA rhgb=no plymouth.use-simpledrm enforcing=0 gnome.initial-setup=no mitigations=off "

And doing :

 # dracut -f
 # grub2-mkconfig >/boot/grub2/grub.cfg

Then initramfs files are now much smaller - thanks ! :

-rw-------. 1 root root 35320268 Jul 31 02:09 initramfs-6.9.12-600.fc40.x86_64.img
-rwxr-xr-x. 1 root root 15888896 Jul 31 02:09 vmlinuz-0-rescue-af19f43bc05746859621afad3f48dd99
-rw-------. 1 root root 105220271 Jul 31 02:09 initramfs-0-rescue-af19f43bc05746859621afad3f48dd99.img

1 Like
9

That would only happen if you install kernel-uki-virt or if you configured install.conf to build and install uki kernels.

10

Aha, thanks for the info, I do build ALL sub-rpms that might be useful of kernel, including
kernel-uki-virt, and of course, having built all RPMs, I do install them.
What precisely do I need the uki-virt kernel installed for ? Please clarify .
Anyway, boot is MUCH slicker now, with exclusion of GPU modules from dracut,
/boot/EFI/efi is still too full, though .
I guess maybe moving the whole of EFI/Windows out of the file system,
which I do not need since I do not boot Windows, and moving the BIOS recovery files back,
might be preferable to not having those BIOS recovery files on the filesystem - this is what I will
try next. Thanks !

11

On a typical, vanilla f40 install this is what is required for fedora.

 # ls -R /boot/efi/EFI
/boot/efi/EFI:
BOOT  fedora

/boot/efi/EFI/BOOT:
BOOTIA32.EFI  BOOTX64.EFI  fbia32.efi  fbx64.efi

/boot/efi/EFI/fedora:
BOOTIA32.CSV  gcdia32.efi  grub.cfg      grubx64.efi  mmx64.efi  shimia32.efi
BOOTX64.CSV   gcdx64.efi   grubia32.efi  mmia32.efi   shim.efi   shimx64.efi

On my system that is about 19 MB

12

For normal users the uki kernel is useless. It is an experimental package used in a virtual machine with known virtual hardware. After uninstalling the uki images you can remove /boot/EFI/efi/Linux and its contents. There used to be a bug in the uninstall procedure which leaves files there.

If you never intend to boot windows you can remove that directory with its contents.

13

Thank you to all who responded !

As a footnote to this:

Next time I had to reboot, I discovered that :

  1. Because I had removed the last ‘rescue’ kernel & initramfs images, and then ran ‘kernel-install’ , last, the rescue kernel was created last and became the default boot kernel .
  2. This rescue kernel was unable to load the ‘vmap.ko’ module to see the EFI boot partition
  3. I had to enter emergency single-user mode, do a ‘depmod -a 6.9.12-600.fc40.x86_64’ , then
    manually load ‘modprobe vmap’ , and then press ^D to continue boot, and then do :
    ‘rpm -ivh --reinstall kernel{,-core,-modules,-modules-core,-modules-extra,-devel}-6.9.12-600.fc40.x86_64.rpm’ ,
    thus NOT re-creating the rescue kernel & initrd last, before Grub2 would auto-boot the non-rescue
    vmlinuz-6.9.12-600.fc40.x86_64 kernel again, which DOES correctly include vmap.ko
    in its initramfs .

Please can ‘kernel-install --add’ , when creating the Rescue Kernel, ‘touch -r …’ the files correctly so
that the normal non-rescue (currently running) kernel is the default ?
Should I raise a bug on this ?

1 Like
14

It sounds like a legit bug to me. I normally disable the rescue kernel. But I agree that it should not be made the default when other kernels are available.

15

When there is not existing rescue image a new upgrade will create a copy of itself as the new rescue image. The newly installed kernel is also normally the default kernel to boot.

Are you saying that the new kernel version booted? Or that the actual rescue image is what booted?

16

Yes, before I had raised any of this post, I had built, installed and booted linux-6.9.12,
by slightly modifying the kernel.spec file from kernel-6.9.11-200.fc40 .
Then I tried doing a 'fwupdmgr ‘{get-updates,install,update}’ and had problems because
of size of /boot/efi/EFI partition.
Then I noticed my rescue kernel was from fc32, and, following instructions elsewhere on this site,
removed /boot/*rescue* and ran manually :
[root@host]# kernel-install --add
, which resulted ONLY in the rescue kernel being created.
On reboot, which unfortunately happens frequently owing to my laptop’s over-sensitive builtin
vibration / motion sensor, so if it drops a few inches it will reboot, then
on reboot the rescue kernel was chosen as default,
since that had the latest timestamp / was the last created by ‘kernel-install’ ?
I did not notice this until boot of rescue kernel had failed because the rescue kernel had failed
to include ‘vmap.ko’ in its initramfs, and /boot/efi could not be mounted. Surely the dependency on
vmap.ko should have been picked up by dracut when creating rescue kernel ?

17

Don’t install kernel-uki-virt if you have a small UEFI partition.