Today when I ran the updates, both of my initramfs for kernel 6.18 and 6.12 got deleted by the process.
I fixed that by chrooting into the system and recreating them with “mkinitcpio -P” but I was wondering if there was a way to have a fallback that would be safe from this kind of problem since that was kind of time consuming.
I’ve read that there is a fallback option we can enable in the preset file for the kernel, but I was wondering if simply enabling that would make it safe from getting potentially deleted since I’m not sure how the update deleted them in the first place.
If that’s not safe, is there an option that would be?
I’m thinking, about just making a manual copy of one of the initramfs and adding a grub entry for that, but I don’t know enough about it to know if that needs regular updating(every time the kernel updates or safe to leave it as-is?) or something like that.
And as a bonus question, is there a way to automatically generate a GRUB entry for the fallback or do I have to manually create it(by copying the normal kernel entry and making the necessary modification to use the fallback instead)?
The short answer: you cannot.
This is how pacman works. It deletes everything at the beginning of the update so for a minute or two you are without kernel. If there is a power outage in that moment you will not be able to boot. I find it suboptimal but maybe there is a reason for it.
But it is relatively easy to fix - chroot and install kernel manually. And let’s face it: how frequently will that happen? It’s not worth the invested time to devise some backup script. Besides, there are snapshots…
Fallback is something else and will not help since it gets deleted too.
The creation of a fallback image for each kernel by default recently got disabled
via a change to /etc/mkinitcpio.d/linuxXYZ.preset
(via .pacnew files)
You can enable it again by editing the .preset file
Both images will still be deleted at the beginning of an update and only regenerated and put back at the very end of it.
It’s the way pacman works.
Monitor the progress and completion of the update before reboot
so you can catch when it didn’t finish for some reason before you reboot and discover that fact “the hard way”.
It is easily solved by chroot and recreating the images as you did with
mkinitcpio -P
followed by
update-grub
Never thought about that since it occurs rather seldom (never, for me) and is easy to fix through chroot.
You would probably have to do this manually, maintaining that initrd yourself.
… not worth the effort, IMO
That’s what I assumed at first, but I ran the update again when I saw the window close(seemed too quick, but like I said in the update thread, wasn’t paying too much attention) and it closed again(forgot if that’s normal behavior or not).
Ran pamac again after getting back into the OS and there was nothing to update.
I just ran sudo pacman -Syu and it’s telling me everything is up-to-date.
Could things still be half updated and it thinks all is good?
Does it delete literally everything kernel related, only what’s affected by the update or only what’s automatically generated?
I didn’t have to run update-grub since nothing had changed and it was still there, but that does answer my bonus question, it does automatically generate the fallback entry.
-* Assume I skipped an extra blank line here to indicate a separation between my reply to the previous quote and a new subject. I really hate this forum software and almost everyone use it nowadays. Can’t even seem to disable automatic formatting to use a * at the beginning of a line, sigh *-
What I’m still wondering is if the initramfs file has to be generated every time the kernel change. If not, I’m thinking of making a manual entry with one for my backup kernel but would probably not be worth the effort to make a script if it does need to be generated every time.
Yes.
It contains the current kernel.
The initrd is booted, then the file system root is switched from the minimal file system in the initrd to the actual file system of your machine.
If you want to separate one paragraph from another,
use three - (minus) signs
or two of those three in two consecutive lines
→ see the two lines below?
That was me, typing “—” and Enter and “—” again.
one line:
There is a cheat sheet somewhere, explaining how to achieve certain formatting of text here.
The forum software is “Discourse” - should help in finding the info on what to type to achieve certain optics.
Markup is supported, I think.
bbcode … I don’t know, some of it, maybe
html tags are …
I still like the “old school” forums better than this here, btw.
Yeah, the * thing is markdown stuff I think, but can’t seem to be possible to disable that formatting.
Thanks for the 3x - tip, don’t like seeing the line, but it is better than nothing.
Looking it up, I think \ should work to make an empty line, but requiring a cheat sheet for basic formatting is really not ideal, I struggled for so long with how to make a code block with the backticks before figuring it out.
I just hate not being able to format posts the way I want to, I make use of empty lines a lot when I type stuff.
At least it doesn’t force an empty line between each lines here, that one just makes things so much harder to read.
There should be 2 empty lines before this hopefully
Edit: … and there is, nice. Now to remember that next time I need it…
The “cheat sheet” is simply the explanation of how formatting works and can be done here.
It’s more complex than the older ones.
Also more versatile.
It’s a trade off.
And it is what it is, here and now.
It was decided that this was better …
Yeah, but normally the post section UI would have an option to create that formatting, not having that for something like basic formatting is just a bad design, I would only expect that to be the case for super advanced stuff.
With bbcode based forums, you usually could switch mode to see the raw formatting the UI made, which makes using and learning a lot easier than … having to look it up somewhere else since it’s seemingly impossible to know just from using it.
But it is what it is, not much we can do about it.
Yeah, I already had created a fallback for 6.12 before making this thread, which is why I had my bonus question. I was just wondering if having it would have solved my problem, which it wouldn’t.
Always good to spread the information though so thanks.
That “fallback” kernel is just as current as the other one.
It’s just created with default options and many more drivers contained within.
It’s basically just much larger.
But the same, updated, new kernel.
Assume you insert a new video card into your desktop and your kernel won’t boot because it doesn’t have a driver for it. But the fallback has all possible drivers and boots. And then you regenerate with mkinitcpio -P and the new driver is included and after reboot your standart kernel boots again. That is the use case of the fallback.
But then again…the same can be achieved with a live usb and chroot. So me personally (and it seems now arch devs too) prefer to save the diskspace and time for generation a fallback on every update. Especially since i have a laptop and i won’t change important hardware.
This means that you had an interrupted update. A successful update recreates the initramfs entries for all of the kernels you have installed by way of the package manager.
No, the -fallbackinitramfs will get deleted at the start of the update process by the /usr/share/libalpm/hooks/60-mkinitcpio-remove.hook just the same.
Yes, there is, but — I hope you don’t mind my saying it — if you have to ask the questions you did, then it’s out of your league. It would involve creating a custom kernel and initramfs, and installing it outside of the scope of the package manager.
No, it doesn’t.
The kernel is compressed and made a component of the file vmlinuz. This file contains the kernel’s bootstrapping code, which on systems booting in legacy BIOS mode is the code that initializes 64-bit long mode from the processor’s real-mode, and which on all systems decompresses the runtime kernel in RAM, loads the initramfs, and then passes control onto the runtime kernel.
The initramfs is a ramfs — a filesystem in RAM — which itself contains a cpio archive with a minimal root filesystem. It does not contain any kernel.
The -fallback entry uses the exact same kernel but with a different, much bigger initramfs, which contains everything and the kitchen sink to get the system booting.
The regular initramfs in turn only contains the drivers your system really needs for booting — the systemd hook and the autodetect hook select the required drivers for booting from your running system during initramfs creation.
Once the kernel has booted and the real root filesystem has been mounted, the kernel will load additional driver modules from the real root filesystem, or better still, from the /usr/lib directory on the real root filesystem, even if the contents of /usr were split off onto a separate partition or btrfs subvolume — this is what one needed the usr hook in /etc/mkinitcpio.conf for in the past, before the transition to the systemd hooks.
