Garuda is deleting custom kernels

I compiled 3 custom kernels

*3.3
*6.2
*6.1

At some point all files in /lib/modules/6.x get deleted, and I cannot boot into the kernel that was compiled and working perfectly fine.

Does anybody knows what can I do to prevent this?
I have 6 distros at home.
Garuda is the only distro doing this, and I guess it might be related to the special kernel garuda has, maybe it wants to keep only two.

Thanks so much.

Please post the output of garuda-inxi when you have a chance.

This does not sound like something Garuda “does”.

Garuda supports having multiple kernels installed, including custom kernels. Garuda does not have a “special kernel” per se, as not every spin ships with the same kernel. Most ship with the Zen kernel, which is not Arch’s default kernel but is not a particularly exotic kernel either (it’s in the [extra] repo).

Each kernel in /usr/lib/modules should have a separate directory based on the name of the kernel. Here is an example on the system I am booted into right now, which has six different kernels installed:

/usr/lib/modules
├── 6.1.28-1-lts
├── 6.1.28-hardened1-1-hardened
├── 6.3.2-1-cachyos-bore
├── 6.3.2-arch1-1
├── 6.3.2-zen1-1-zen
└── 6.4.0-rc2-1-mainline

They will change version numbers as the kernels are updated, but they don’t go away unless I choose to uninstall a kernel.

Maybe if you can describe your process with a little more detail someone from the community can help identify what is happening. Take it a step further: the real litmus test would be attempting to reproduce the issue. If you can, be sure to document the process so we can take a look.

6 Likes

No Garuda does this.
I think it's the garuda-hooks

Simply NO. I have 5 arch distros installed each having 3 kernels including Garuda and this behavior doesn't happen on any of them.

4 Likes

Take a look for yourself at the scripts garuda-hooks package maintains in /usr/share/libalpm/hooks or /usr/share/libalpm/scripts and you will see this is a somewhat baseless theory.

%FILES%
etc/pacman.d/hooks/90-mkinitcpio-install.hook
usr/share/libalpm/hooks/01-snapshot-reject.hook
usr/share/libalpm/hooks/20-grub-config.hook
usr/share/libalpm/hooks/20-lsb-release.hook
usr/share/libalpm/hooks/20-os-release.hook
usr/share/libalpm/hooks/99-foreign.hook
usr/share/libalpm/hooks/99-grub-install.hook
usr/share/libalpm/hooks/99-orphans.hook
usr/share/libalpm/hooks/99-pacnew-check.hook
usr/share/libalpm/hooks/99-update-grub.hook
usr/share/libalpm/hooks/garuda-hooks-runner.hook
usr/share/libalpm/hooks/zzz_post.hook
usr/share/libalpm/scripts/garuda-hooks-runner

It seems more likely to be a PEBCAK-related issue. :wink:

Your reply did not include any information, so I have moved the thread to 412 Precondition Failed for now. If you would like to revisit the discussion you may edit your post to include the details that were asked of you and we will move it back to an accessible topic category.

Please bear in mind blaming Garuda for randomly deleting your files or similar spurious mudslinging is not useful when troubleshooting an issue on a technical support forum. Please keep your suggestions evidence-based and rational if you can.

6 Likes

The only thing which comes to mind is:

I guess it can easily be found out by disabling said service.

4 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.