@soundofthunder Quick question. Is it really necessary to regenerate the initramfs, if I’m planning to disable future fallback image creation? Asking because the original section doesn’t specifically ask for it.
I’m running an ‘older installed system’ according to the 2025-11-10 issue listed in the Known issues and solutions section of the [Testing Update] 2025-11-14. I still have installed the LTS kernels 6.1 & 6.6 (beside my current 6.12) and updating always takes significantly more time nowadays because of the fallback image creation for the older kernels. Since I’ve got a bootable USB stick ready running Ventoy (which I update regularly with the new GNOME .iso), I’m toying with the idea of disabling the creation of the fallback image.
On the other hand, would it be a terrible idea to disable the fallback image only for the older kernels and leave it enabled for my current kernel? What I mean is, running sort of a mixed configuration and just editing the presets for 6.1 and 6.6 and only remove those initramfs images in /boot/ but leave the ones for 6.12 untouched? Would that mess up something?
Should not really be required to regenerate (although i did it). Grub menu must be regenerated though.
I did it exactly to save time on updates and to save some space - initramfs with autodetect hook is 15MB, the fallback without was 130MB.
Here is an example of my preset:
So do not forget to comment also the 2 lines with -------
And after that you can also delete the old fallbacks from /boot
Otherwise, you can mix whatever you want. That is why there are different presets for different kernels, to allow customization. But if you do not plan to change hardware you are probably good without the autodetect.
Is not strictly necessary if the kernel or initcpio.conf options where not changed, but it only takes a few seconds for the default target.
The fallback target takes longer because it will include more (or even all - I don’t know) modules.
I do that as soon as I’m noticing that it is active again when a newer kernel has been installed. Not problematic at all.
It saves a few seconds and the space that the much larger fallback initrd will need in the /boot directory.
I have never had a situation where the fallback image was even needed.
And: in case it should be necessary, I do know how to chroot and can also do it by means of actually having a bootable USB.
@Teo
it really is enough to remove “fallback” from the PRESETS line
No, it’s not strictly needed, though normally it will do no harm.
My opinion is that disabling fallback creation for the sake of saving 30 seconds (or whatever it may be) is probably unwarranted; though I understand the perceived wait can at times seem lengthy on “clunkers” (a term I affectionately use for spinning disks HDDs).
That said, I also appreciate the need to maintain an older kernel (in case it’s ever needed) – it sounds like my system (circa 2020) is more recent than yours but I still keep kernel 6.6 (LTS) around for good measure, along with 6.12 (LTS) as the primary.
I wonder if you actually need 6.1 (LTS) and whether simply keeping 6.6 (LTS) as your “spare” would be sufficient. This approach should also shave off some of that wait.
The update to mkinitcpio 40 disabled fallback image creation on my existing install. That may be because I never edited the preset file, so it got overwritten by the new one.
Those are my hooks (the most important is autodetect at the beginning). Maybe you forgot the compression. I am on ext4 and have commented everything which defaults to zstd
[teo@teo-lenovo-v15 boot]$ ls -lh
total 70M
drwx------ 4 root root 4,0K 1. Jan 1970 efi
drwxr-xr-x 6 root root 4,0K 14. Nov 18:37 grub
-rw------- 1 root root 16M 14. Nov 18:37 initramfs-6.12-x86_64.img
-rw------- 1 root root 16M 14. Nov 18:37 initramfs-6.6-x86_64.img
-rw-r--r-- 1 root root 13M 12. Aug 19:02 intel-ucode.img
-rw-r--r-- 1 root root 22 19. Sep 18:11 linux612-x86_64.kver
-rw-r--r-- 1 root root 22 19. Sep 18:08 linux66-x86_64.kver
drwxr-xr-x 2 root root 4,0K 6. Feb 2025 memtest86+
-rw-r--r-- 1 root root 598 9. Mai 2024 refind_linux.conf
-rw-r--r-- 1 root root 14M 26. Sep 20:42 vmlinuz-6.12-x86_64
-rw-r--r-- 1 root root 13M 26. Sep 20:42 vmlinuz-6.6-x86_64
[teo@teo-lenovo-v15 boot]$ cat /etc/mkinitcpio.conf
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run. Advanced users may wish to specify all system modules
# in this array. For instance:
# MODULES=(usbhid xhci_hcd)
MODULES=()
# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image. This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=()
# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way. This is useful for config files.
FILES=()
# HOOKS
# This is the most important setting in this file. The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
## This setup specifies all modules in the MODULES setting above.
## No RAID, lvm2, or encrypted root is needed.
# HOOKS=(base)
#
## This setup will autodetect all modules for your system and should
## work as a sane default
# HOOKS=(base udev autodetect modconf block filesystems fsck)
#
## This setup will generate a 'full' image which supports most systems.
## No autodetection is done.
# HOOKS=(base udev modconf block filesystems fsck)
#
## This setup assembles a mdadm array with an encrypted root file system.
## Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices.
# HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
#
## This setup loads an lvm2 volume group.
# HOOKS=(base udev modconf block lvm2 filesystems fsck)
#
## This will create a systemd based initramfs which loads an encrypted root filesystem.
# HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole sd-encrypt block filesystems fsck)
#
## NOTE: If you have /usr on a separate partition, you MUST include the
# usr and fsck hooks.
HOOKS=(autodetect systemd microcode modconf kms block keyboard sd-vconsole filesystems fsck)
# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compression
# is used for Linux ≥ 5.9 and gzip compression is used for Linux < 5.9.
# Use 'cat' to create an uncompressed image.
#COMPRESSION="zstd"
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"
# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()
# MODULES_DECOMPRESS
# Decompress loadable kernel modules and their firmware during initramfs
# creation. Switch (yes/no).
# Enable to allow further decreasing image size when using high compression
# (e.g. xz -9e or zstd --long --ultra -22) at the expense of increased RAM usage
# at early boot.
# Note that any compressed files will be placed in the uncompressed early CPIO
# to avoid double compression.
#MODULES_DECOMPRESS="no"
[teo@teo-lenovo-v15 boot]$
As part of my learning especially on locking down the system, I have learned that signing the efi and enabling Secure Boot creates a verification chain.
For some time now I have been using unified kernel and booting from the generated efi stub.
Yes grub is still present on my system but only because ISO building requires grub
EDIT:
On any system - using a unified kernel makes it possible to skip the second loader completely - whether this is grub, systemd or refind.
I cannot imagine any usage for the fallback image other then when one changes hardware on a desktop. But then again, one can just use live usb to chroot and generate a new normal (with autodetect the new hardware ) image from there. So why having the fallback taking space and time all the other 364 days in the year, so to say.
The Known Issues and Solutions wiki post in recent [Testing Update] announcements has been updated to include changes to ArchWiki
Disabling fallback image creation has also been suggested as an alternative to installing mkinitcpio-firmware AUR to resolve WARNING: Possibly missing firmware messages during updates. But suggestion is less specific and was not recommended
Actually, the information above is incorrect. In order to disableinitramfs generation, PRESETS=('default' 'fallback') should be changed into PRESETS=('default'), not the other way around.
Sorry, for the late answer. I have been doing some tests…
I realized that the big chunk of my initramfs (115 MiB) were Nvidia firmware files. I use the Nvidia open drivers and the ones in the initramfs are the propietary ones. After reading the Nvidia page on Arch’s wiki I disabled kms in the hooks, and now my initramfs is only 9 MiB!
Everything works but I still have to clarify if my initramfs should include Nvidia-open firmware drivers (they also exist)
