I don’t have a Nvidia card and my initramsfs-6.7 fallback image is 246,6 MiB, the others have around 70 MiB.
Funny that I have to deal with it with my main display driver being Intel integrated graphics and Nvidia being just a separate dGPU chip not involved in anything.
I’m getting tired of this neverending “Linux vs Nvidia” thing…
2 Likes
So my assumption was wrong, and so is that post, it’s not just NVIDIA.
What I was trying to say is that you shouldn’t worry that NVIDIA firmware is going to get loaded - as you don’t have it and no drivers installed? (if you do you should see why, and remove it).
If your initramfs image is big that probably means that 6.7 is now bundling into initramfs your GPU firmware - if you have kms hook, and Early KMS Start enabled (kms hook seems enough).
So far I haven’t noticed any slowdowns during the boot load (which I was afraid of given size).
But I could be wrong, I’m really no expert in this, not even remotely, just trying to figure out why my initramfs is 20x bigger.
You could try uninstalling NVIDIA drivers if you have them and if you can (as you say you’re not using it), see if that helps. Maybe Intel firmware is being bundled into initramfs. Just guessing.
If I removed kms hook from the mkinitcpio, yes, I have a small size in all initramfs mages, 48,4 MiB for the linux-6.7, 46,6 MiB for linux-6.6 and 43,4 MiB for the linux-6.1. I am guessing if I will get in to any problem by doing this? It’s only the size after all. I don’t think I have any driver Nvidia installed.
Related to Nvidia I only have mhwd-nvidia, mhwd-nvidia-390xx and mhwd-nvidia-470xx, required by mhwd-db, which is required by mhwd.
You won’t get into problems per se but it’s not optimal. As Seth from Arch forums explained to me, simpledrm should not be loaded as it’s slow etc., or basically you’re not using your GPU up to its potential. You can check it out in logs, I used this…
journalctl -r -p debug | grep "simpledrm"
(you should have mostly these ‘The simpledrm driver will not be probed’)
So, IMO, you should keep the kms, the size doesn’t seem to affect the loading time, so no reason not to have it.
Firmware is something that gets installed with your GPU driver (or in that bundle), I have no idea, you can’t do much on that side. I’d say that if you don’t have NVIDIA drivers then it’s your GPU firmware that gets bundled into initramfs, but it’s really hard to check that out I’m afraid.
As related to mhwd-nvidia I can’t check that on my end because all I have is NVIDIA, it’s a little strange that you would be required to have those on your system, ask a question about that specifically or try removing all those that have nvidia in it, it’d probably complain if you can’t (but backup/timeshift it before that or know how to log into TTY and reinstall those in case it breaks your system). It’s probably a Manjaro thing.
No, what I get is:
jan 14 09:48:59 archlinux kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
jan 14 09:48:59 archlinux kernel: [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
w/o kms? Only NVIDIA needs simple-framebuffer as far as I know.
Anyhow, you should keep the kms.
1 Like
I doubt, but sure size matters when dealing with UKIs and small EFI partitions:
$ eza -l /efi/EFI/Linux
.rwxr-xr-x 53M root 14 янв 22:54 manjaro-6.1-x86_64-systemd.efi
.rwxr-xr-x 54M root 14 янв 22:53 manjaro-6.1-x86_64.efi
.rwxr-xr-x 58M root 14 янв 22:54 manjaro-6.6-x86_64.efi
.rwxr-xr-x 241M root 14 янв 22:54 manjaro-6.7-x86_64.efi
Most people do not make/enlarge their $esp to >= 1 Gb
Also, the bigger UKI gets, the longer it takes to boot system. The difference between 6.6 and 6.7 on my laptop is about 10-15 seconds:
Startup finished in 11.794s (firmware) + 14.398s (loader) + 7.304s (kernel) + 5.895s (userspace) = 39.392s
It used to be:
Startup finished in 11.885s (firmware) + 3.713s (loader) + 7.067s (kernel) + 5.862s (userspace) = 28.529s
I will keep kms.
The stranger think for me is the size of the initramfs linux-6.7 is 246,6 MiB, linux-6.6 is 71,0 MiB and linux-6.1 is 66,2 MiB.
I was afraid of that but it honestly doesn’t show on my end, maybe ~1sec difference in the loader part, that’s it. Maybe it makes sense for NVIDIA and not the others, or maybe it’s UKI specific?
And if some of you are wondering what gets bundled into your initramfs there is an easy way to check…
# mkinitcpio --verbose --preset linux67 |& tee /tmp/log1
Then e.g. search for nvidia, when I turn off kms I only get one line and nothing else. With kms most of the log is filled with nvidia entries pointing at
/usr/lib/firmware/nvidia/*
…or adjust to your specific case.
EDIT: The only problem is that I can’t see much difference in between 6.6 and 6.7 (both logs are full of nvidia entries) so this doesn’t prove that something extra is going on in 6.7.
I usually use lsinitcpio /boot/initramfs-6.7-x86_64.img -like command with grep, or dump their output to text files and then compare them.
Btw, removed Nvidia drivers and utils, ran mkinitcpio… No avail, size is the same.
Even on stable it is BIG (using xfce, nouveau) = 294M / 560M
maxi
Currently running: 6.1.71-1-MANJARO (linux61)
linux515 vmlinuz-5.15-x86_64 initramfs-5.15-x86_64.img=37M fallback=245M
linux61 vmlinuz-6.1-x86_64 initramfs-6.1-x86_64.img =39M fallback=272M
linux67 vmlinuz-6.7-x86_64 initramfs-6.7-x86_64.img =294M fallback=560M
Modules in: /lib/modules
modules515 5.15.146-1-MANJARO=273M extramodules-5.15-MANJARO=264K
modules61 6.1.71-1-MANJARO =322M extramodules-6.1-MANJARO =300K
modules67 6.7.0-0-MANJARO =290M extramodules-6.7-MANJARO =320K
For me there seems to be something broken 
So there is a folder with 258M for nvidia, which was not this big with 6.1 
That is even better (I’ve never used it myself, thanks).
Anyhow, either way, diffing 6.6 and 6.7 shows /usr/lib/firmware/nvidia/*/gsp to be the only difference, which is in agreement with that post, whatever gsp is in this context.
So, for NVIDIA is clear, I’d like to see you with intel/amd etc. do something similar.
same here…dbus-broker errors and linux67-img so big
dbus-broker error … i think the 2x // are a problem … can´t find this problem in the source code - /usr/share//dbus-1/
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.Thunar.FileManager1.service' is not named after the D-Bus name 'org.freedesktop.FileManager1'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.Tumbler.Cache1.service' is not named after the D-Bus name 'org.freedesktop.thumbnails.Cache1'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.Tumbler.Manager1.service' is not named after the D-Bus name 'org.freedesktop.thumbnails.Manager1'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.Tumbler.Thumbnailer1.service' is not named after the D-Bus name 'org.freedesktop.thumbnails.Thumbnailer1'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service' is not named after the D-Bus name 'org.freedesktop.Notifications'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.xfce4-notifyd.Notifyd.service' is not named after the D-Bus name 'org.xfce.Notifyd'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.Thunar.FileManager1.service' is not named after the D-Bus name 'org.freedesktop.FileManager1'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.Tumbler.Cache1.service' is not named after the D-Bus name 'org.freedesktop.thumbnails.Cache1'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.Tumbler.Manager1.service' is not named after the D-Bus name 'org.freedesktop.thumbnails.Manager1'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.Tumbler.Thumbnailer1.service' is not named after the D-Bus name 'org.freedesktop.thumbnails.Thumbnailer1'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service' is not named after the D-Bus name 'org.freedesktop.Notifications'.
dbus-broker-launch[1433]: Service file '/usr/share//dbus-1/services/org.xfce.xfce4-notifyd.Notifyd.service' is not named after the D-Bus name 'org.xfce.Notifyd'.
Big linux67 img files…
-rw------- 1 root root 260M 14. Jan 21:53 initramfs-6.7-x86_64-fallback.img
-rw------- 1 root root 190M 14. Jan 21:52 initramfs-6.7-x86_64.img
1 Like
Those who still wonder about the initramfs file size: https://www.phoronix.com/news/NVIDIA-Big-GSP-Firmware-Dump. So mkinitcpio and dracut are affected by this. If you live in Ubuntu world, you wouldn’t have a problem as Canonical is bundling firmware already way longer than upstream does now. Do you need that firmware in your initramfs? Most likely not. It is only designed for Nouveau drivers and nothing more. So even if you use the proprietary drivers, you don’t need that firmware. What is it for? Eye-Candy and other nonsense to make the boot experience smooth with Plymouth and Co.
Temp solution: get rid of kms, maybe plymouth and let the quiet flag do all for you. Most likely you will see a vendor logo on your UEFI system without the fancy progressbar plymouth would add. You can also just get rid of kms in the fallback image or disable fallback completely.
kms Adds GPU modules to provide early KMS start. Additionally adds modules that are required by privacy screens built into the LCD panel of some laptops.
Manjaro added kms just recently with Calamares on 23.3.1 install medias. Before that we didn’t use it on standard installations. Arch had it added since a year: Update mkinitcpio.conf (!126) · Merge requests · Arch Linux / Mkinitcpio / mkinitcpio · GitLab
More info on it here: kms hook increases the initramfs size heavily starting with 6.7 kernel (#238) · Issues · Arch Linux / Mkinitcpio / mkinitcpio · GitLab
On side note: mkinitcpio 37-1 adds rclone to the initramfs (#227) · Issues · Arch Linux / Mkinitcpio / mkinitcpio · GitLab
4 Likes
This is what I did, as I always keep a fairly recent release of the live-media always available should something go wrong, so a fallback image while convenient, it isn’t exactly catastrophic if I don’t have one.
Fallback image is normally the same image without autodetect hook enabled.
1 Like
Okay.
Anyway, in all the years I’ve been using Linux, I know I’ve only ever selected the fallback image (maybe twice) out of mere curiosity when playing around. So this recent large image size issue has pushed me to disable a function that clearly can be considered optional for me.
Thanks, this made me reconsider my preferences and get rid of kms and plymouth for good. My UKIs are much smaller now (that positively effects boot time), and that’s nice.
┬─[openm@reiwa:~]─[17:19:21]
╰─>$ eza -l /efi/EFI/Linux/ 0 (0.025s)
.rwxr-xr-x 41M root 15 янв 17:09 manjaro-6.1-x86_64-systemd.efi
.rwxr-xr-x 42M root 15 янв 17:09 manjaro-6.1-x86_64.efi
.rwxr-xr-x 43M root 15 янв 17:09 manjaro-6.6-x86_64-systemd.efi
.rwxr-xr-x 43M root 15 янв 17:09 manjaro-6.6-x86_64.efi
.rwxr-xr-x 43M root 15 янв 17:10 manjaro-6.7-x86_64-systemd.efi
.rwxr-xr-x 44M root 15 янв 17:10 manjaro-6.7-x86_64.efi
No fancy boot pic and animation though… Good riddance! Another gain: with no kms and plymouth hooks, initrd building / packing takes less time on a weak 6 year old U-series processor. Isn’t it neat?
1 Like
@philm to check for people with freeze or slow machine with kernel 6.7
it may concerns motherboard with acpi-cpufreq and schedutil
can you check in 6.7 if this is also needed ?