That’s a fallback preset, but it won’t prevent the initramfs being deleted and recreated during an update. 
Perhaps I am just ignorant, and yes I skipped reading all comments, why would anyone want to keep an obsolete initramfs when the kernel is updated?
You can create a copy, giving it a good name, then you can create an entry by copying the content of an auto generated entry and paste it into /etc/grub.d/40_custom - modify the entry to match your use case.
Then run update-grub or grub-mkconfig -o /boot/grub/grub.cfg.
I knew it … 
Thanks for explaining it correctly.
The OP is looking for a way to make sure their system can still boot after an interrupted update. 
…which is generally an impossible task. That is why snapshots (or update “slots” if we look at android for example) were invented.
I guess we could also say… 
… and to not interrupt the process or use a buggy GUI package manager, but I guess people want to do it the pointy-clicky way.
I got hit at least 2 times already.
After that i created my own update-script which ends with calling “maxi”
At least then i know what to do instead of booting.
I could look into /boot with
sudo ls -lA /boot
and look for kernels and initramdisks or use maxi at any time.
You can also use maxi -eg
to collect information about the boot process. This works,
- when you are in your running system (with CTRL+ALT+F2).
- And also in a live environment
That’s because you didn’t update with pacman, The Infallible One™. You updated with pamac, The Flawed One™. 
Why do you use sudo for that? Did you deny read access on /boot to all other users?
No
As far as I can remember, I use trizen -Syu (and therefore pacman -Syu).
because:
/bin/ls -lA /boot
insgesamt 1492828
-rw-r--r-- 1 root root 307200 13. Jan 01:27 amd-ucode.img
drwx------ 3 root root 4096 1. Jan 1970 efi
drwxr-xr-x 1 root root 6 9. Dez 15:21 efibak
drwxr-xr-x 1 root root 112 2. Feb 17:05 grub
-rw------- 1 root root 422727680 2. Feb 17:04 initramfs-6.12-x86_64-fallback.img
-rw------- 1 root root 218726400 2. Feb 17:03 initramfs-6.12-x86_64.img
-rw------- 1 root root 522598400 2. Feb 17:04 initramfs-6.18-x86_64-fallback.img
-rw------- 1 root root 318822400 2. Feb 17:04 initramfs-6.18-x86_64.img
-rw-r--r-- 1 root root 14934016 11. Nov 19:07 intel-ucode.img
-rw-r--r-- 1 root root 22 31. Jan 00:06 linux612-x86_64.kver
-rw-r--r-- 1 root root 21 31. Jan 00:06 linux618-x86_64.kver
drwxr-xr-x 1 root root 44 2. Sep 14:10 memtest86+
-rw-r--r-- 1 root root 362 9. Dez 15:51 refind_linux.conf
-rw-r--r-- 1 root root 13914624 2. Feb 17:03 vmlinuz-6.12-x86_64
-rw-r--r-- 1 root root 16597184 2. Feb 17:03 vmlinuz-6.18-x86_64
Otherwise I wouldn’t be able to see the initramdisks 
initramfs... is only readable by root
(And there are definitely good reasons for that)
I just realized that /boot is still visible, but not /boot/efi. So if you need to search deeper (which “maxi” does automatically), you still need sudo.
That’s irrelevant. Viewing the contents of a directory depends on the permissions of the directory itself, not on the permissions of the files therein. 
[nx-74205:/dev/pts/5][/home/aragorn]
[aragorn] > ls -l /
total 32
lrwxrwxrwx 1 root root 7 Oct 13 08:39 bin -> usr/bin
drwxr-xr-x 1 root root 172 Feb 1 12:07 boot
drwxr-xr-x 19 root root 4080 Feb 3 14:24 dev
drwxr-xr-x 1 root root 4466 Feb 3 14:24 etc
drwxr-xr-x 1 root root 14 Jun 4 2025 home
lrwxrwxrwx 1 root root 7 Oct 13 08:39 lib -> usr/lib
lrwxrwxrwx 1 root root 7 Oct 13 08:39 lib64 -> usr/lib
drwxr-xr-x 1 root root 40 Oct 23 14:29 mnt
drwxr-xr-x 1 root root 22 Jun 4 2025 opt
dr-xr-xr-x 348 root root 0 Feb 3 14:24 proc
drwx------ 1 root root 324 Feb 1 13:09 root
drwxr-xr-x 35 root root 780 Feb 3 14:32 run
lrwxrwxrwx 1 root root 7 Oct 13 08:39 sbin -> usr/bin
drwxr-xr-x 1 root root 26 Jun 4 2025 srv
dr-xr-xr-x 13 root root 0 Feb 3 14:24 sys
drwxrwxrwt 18 root root 640 Feb 3 16:51 tmp
drwxr-xr-x 1 root root 80 Feb 3 14:11 usr
drwxr-xr-x 1 root root 126 Feb 3 14:24 var
[nx-74205:/dev/pts/5][/home/aragorn]
[aragorn] > ls -l /boot
total 61344
drwxr-xr-x 3 root root 4096 Jan 1 1970 efi
drwxr-xr-x 1 root root 84 Feb 1 12:08 grub
-rw------- 1 root root 31272960 Feb 1 12:07 initramfs-6.18-x86_64.img
-rw-r--r-- 1 root root 14934016 Nov 11 19:07 intel-ucode.img
-rw-r--r-- 1 root root 21 Jan 31 00:06 linux618-x86_64.kver
-rw-r--r-- 1 root root 16597184 Feb 1 12:07 vmlinuz-6.18-x86_64
[nx-74205:/dev/pts/5][/home/aragorn]
[aragorn] >
Oh, that sounds like a good idea and it would make for a better backup kernel since it would stay the same for as long as I don’t update it.
While it is beyond my knowledge right now, acquiring said knowledge is fairly easy and compiling stuff is something I do fairly regularly so I’m not worried, it’s just another subject I have to get myself more acquainted to.
I’ve been using linux for decades, but only as my main desktop for a few months so there are a lot of specific things I simply don’t know about, like that pamac is apparently very unreliable.
I am also realizing I can just make a copy of any of the existing kernel and the required files to boot it and move that outside of the scope of the package manager. Unless the paths are hardcoded inside them or something.
Thinking is hard when you’re tired, lol.
The good old sudo cp /boot/kernel /boot/kernel.bak
But you will still need a live usb to boot somehow to restore it, so the whole thing does not really make sense for me.
The plan is to add a grub entry to the copy, then I can boot it whenever. Not sure if the grub config is wiped too on updates though, but I assume not.
I’d just setup an ISO to boot from when I needed to fix things.
To keep it up-to-date, you just download a newer iso and put it in the right place (should be able to automate that)
If you prefer, you can use another install, you can update it from a chroot if you want.
os-prober may deal with that assuming you have it enabled, but I can’t be certain as I haven’t tested this scenario.
You can add your own menu/boot entries in /etc/grub.d.
See:
cat /etc/grub.d/40_custom
You give it the number in the filename for the order it processes them in.
Back almost 3 decades ago, I remember it was pretty crucial to have your previous kernel on hand.
It would have been the most popular distro at the time, Slackware. You had to compile kernels yourself. And they were very finicky, whether a new bug or accidental misconfiguration of hundreds of kernel options.
I can’t remember what I did exactly, it was so long ago. But I could always boot a new-kernel or previous-kernel. I had a script that would mv/rename the kernel, and then I would compile the new one.
Then LILO (hah) would pick up the files and I could always boot either.
So many times the newly complied kernel did not work, so you had to have a backup of your previously working one. Everyone did it this way.. (I think.)
Is this basically what you are trying to do?
Times have changed! Resilient kernels that adapt to most things. I found having a new and an LTS kernel (installed via mhwd-kernel) is more than fine now.
And especially with snapshots, always a way to rollback, or so much more. I didn’t even fully understand the fallback image, I’ve had it disabled so long.
The actual goal is to always be able to access my system when I’m in a hurry or don’t want to deal with fixing issues right this second.
The fact essential files are deleted in this way just doesn’t make sense for a production product, they should only be deleted at the very end, after the whole update process is done and you rename the new ones into the old ones. If something fails, your old files remain and your system isn’t broken.
Since that’s unlikely to change any time soon, I just want a backup way to boot in case things go wrong.
I usually have a pxe server with a manjaro iso(and many more stuff) I can boot into and I have usb drives I can put one into as well, when I overwrote the last one, but that doesn’t give me access to my actual system right now and who knows when that cheap usb drive is gonna have issues and I need to make a new one or I misplace it or I changed the OS on my router and haven’t set up the pxe stuff back(because of course I hadn’t, sigh).
Having a more reliable alternative way to boot just makes sense to me.
The option with a grub entry for a backup kernel sounds very sensible but there is a hole in that plan: other files get deleted too. Actually the gub config too but at the very end so it shouldn’t matter much. So you will have a good kernel but the boot process will still be stuck on some other missing component.
The option with an iso or pxe sounds more reliable.
That update procedure is one of the weaknesses of the arch concept for me. I guess it is not always roses 
But i use a laptop so power outage on update cannot happen to me.
At the end of the day, only snapshots and backups are the real solution for restoration from a disaster.
I wasn’t planning on only copying the kernel, my kernel was still intact with the issue I had.
Nothing is foolproof, but it should be about as good as I can make it.
The issue with booting an iso is that it’s not my system I’m booting so I don’t have access to everything I may need to immediately.
For example, if there’s a time sensitive event in a game I play(or whatever else would require some setup to make work), that would be an issue.