Removing kernels via GUI (Manjaro settings manager) leaves an orphan preset in mkinitcpio.d

The default procedure should be to rename them to .pacsave as otherwise, updating rams tries to execute them (with an error/advisory and no consequences, of course). Minor impact, but still, something that wasn’t the case in the past, so I assume it’s a matter of changed configuration for the maintainers to rectify (probably no more than one missed line, even). I can’t tell you for how long this has been happening though, as I only noticed it now, and I haven’t really switched kernels recently…

Manjaro 22.0.0
branch: unstable
kernel 6.1.0-1

1 Like

agreed! removing kernels should leave the user with at least the old configuration file. looks like manjaro-settings-manager uses mhwd-kernel in the background and mhwd-kernel only has one way to remove a kernel using -r option.

-r executes pacman -R "${pkgremove[@]}" (line 82 of /usr/bin/mhwd-kernel. just -R doesn’t save configs and doesn’t even clean the leftovers. for saving configs -Rn should be used. see pacman - ArchWiki.

now this issue was noticed by an old user and they even created a pr to address it. but “manjaro devs” don’t like prs (old experience) and it was, unfortunately, never implemented.

Huh? I think you should read OP again.

Again, you got things other way around. See:

I think this is fairly recent. I switched to 6.1 once it was available in the Testing branch and removed 6.0. The linux60.preset is still present but all previously installed kernels have .pacsave appended.

ls -lh /etc/mkinitcpio.d                                                                                                     ✔ 
total 28K
-rw-r--r-- 1 root root 396 Dec 20  2021 linux515.preset
-rw-r--r-- 1 root root 396 Jan 18  2022 linux516.preset.pacsave
-rw-r--r-- 1 root root 396 Mar 29  2022 linux517.preset.pacsave
-rw-r--r-- 1 root root 396 Jun  7  2022 linux518.preset.pacsave
-rw-r--r-- 1 root root 396 Aug  4 10:42 linux519.preset.pacsave
-rw-r--r-- 1 root root 392 Oct 10 09:15 linux60.preset
-rw-r--r-- 1 root root 395 Dec 13 13:02 linux61.preset
mhwd-kernel -li                                                                                                              ✔ 
Currently running: 6.1.0-1-MANJARO (linux61)
The following kernels are installed in your system:
   * linux515
   * linux61

Feel free to go over mkinitcpio 34-1’s: /usr/share/libalpm/scripts/mkinitcpio.

Now, the only problem with this is that I could rename them manually, or include the same if mv loop in the kernel remove section, but this configuration will be rewritten the next time mkinitcpio is updated. From where I’m standing, there are two ways for Manjaro devs to prevent new/inexperienced users from seeing errors related to already removed/obsolete kernels, every time initramfs are updated.

  1. Remove the related preset upon a kernel removal.
  2. Rename them to .pacsave when removing kernels (as it was before).

Do one or the other, but don’t keep them as .preset because the same script will try to execute them every time mkinitcpio runs. To me, it’s just an untested scenario, and it takes literally two lines of code to correct.

I personally couldn’t care less whether I have them or not, but since I’m using the unstable branch, I consider it thoughtful to suggest this, so it doesn’t confuse people on the stable branch when removing/installing kernels. Because a couple of kernel upgrades later, they’ll see 5-6 lines of errors during mkinitcpio, and ask questions about it on this forum.

It’s the same with the missing firmware… People will go to lengths and install firmware their hardware doesn’t even use, just so they don’t see the advisories that kernels spit upon an update. Don’t give them food for though. :slight_smile:

Well, mkinitcpio thingie is a bug and will be fixed most probably. I just didn’t have any time to go over it and find out why it doesn’t work.

Those are just info/warn messages and intended to be there. So it’s user’s problem if he can’t go and read why they are there.

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