Improve upgrade process (especially kernels)

Hello :wave:

Upgrading packages is a critical process and for many/some users it happens that the process does not run successfully because they interrupt it in 99% of all cases. They are greeted with a black screen then and sort of.

  1. One step what could be done is doing for example kernel upgrades including dkms etc on reboot/shutdown.

  2. And/or it could be possible to lock reboot/shutdown/suspend/hibernate services while the upgrade is working.

  3. Add a warning, when a kernel is EOL and not in the repos available anymore plus a suggestion to add the latest LTS kernel.

I know, tech savvy people know that doing a reboot while the upgrade is in progress is a bad thing, but sometimes you can just forget about it.

Same for kernels which go EOL. Some new users are just not that deep informed that they need to switch the kernel from time to time and that this is a user choice.

That would make it a bit saver for the majority and reduce the issues with kernel upgrades.

Thanks for reading.


I agree with kernel update process completly.

1 Like

There already is:

And as far as I know, Manjaro Settings Managers notification applet also warns about this.

Yes, there is an option for it. But I guess it warns you if the kernel is not more in the repos. I would say it is better also to warn when the kernel is still in the repos but set to EOL.
I often seen people who ran only one kernel which got EOL and than got removed from the repos. So the people have problems updating there systems.

Another possibility could be an opt-out while manjaro-install where the latest LTS-kernel is installed beside the latest stable kernel, so that new/unexperienced users have at least one kernel installed which stays long time in the repos.

My opinion on this. :grinning:

While that can still be true, it’s not as common anymore since we stopped shipping ISOs with the latest stable kernel. We now ship with the latest LTS kernel instead to mitigate the issue.

Either way, users need to be able to manage their own computers. Manjaro provides things to make things easier, but one should not depend on someone or some thing to do the thinking for oneself. An operating system is a tool, not a nanny.


@Yochanan @Strit

Good… but I never saw this so far in the GUI. Let it be more tightly integrated into pamac than using a notification.

What about a “reboot-guard” while the pamac upgrade is running. Is that a thing, what could be considered?

Manjaro Settings Manager has been barely in maintenance mode for quite some time. We have Manjaro Control Panel in the works to replace it, but the developer is not able to work on it right now.

1 Like

This isn’t an issue with Ubuntu, Mint, Debian, etc, yet affects Arch-based distros because of this reason:

Here’s a highlight from the post:

Read the entire post and thread for context around the discussion.

Still not sure why Arch Linux does it this way. :person_shrugging:

The kernel-modules-hook is a nice effort to buffer this, yet I believe addressing the underlying issue (in regards to kernel updates) is still warranted. (Thus, such a hook wouldn’t even be needed.)

any power saving should be disabled during the update, even screen dim, because i have seen many get panicked that they can’t wake the screen from sleep, thinking the system is frozen and they trigger a forced shutdown from power button (that we can’t actually help with in any way tho) hence an undesired result and a broken system.

If kernels would update only at shutdown, people might also get confused and frustrated that the shutdown process takes more time than usual, so “something” should notify them and show what is happening. Some users have plymouth, other use boottsplash, other none … so either way, a message while shutdown/reboot should be displayed.

Personally, if there is a huge update, i rather do it from TTY … regardless the DE.

1 Like

LInux (in this context Manjaro) != Windows and Manjaro != Ubuntu

This sentence is spot on

I therefore agree with @bogdancovaciu and @Yochanan that any user should understand and be able to maintain their own system.

This includes an understanding of the mechanisms involved in updating the system.

A while back a variation found in the package kernel-alive was used on some ISOs - I don’t know if this is a the case any longer - but I do know that we have had several issues over time due to that implementation.

If the user is confident - and want to automate this - then fine - but adding another layer of possible issues - is not fine.

Manjaro forum - besides the aspect of helping each other - also serves an educational aspect - at least I have always percieved it that way.

We have the #contributions:tutorials section with numerous guides on how to achieve almost anything with Manjaro.


That’s quite correct, but it’s a long, rather protracted, affair, and Rome was never built in a day, so to speak… :smiley:

That too is quite correct IMO as well :+1:

1 Like

I’m sorry, but the argument doesn’t hold here.

If problems accumulate, then something has to be done about it.

One example:

There is a circular saw in a factory. All employees have been instructed in how to use it. Nevertheless, avoidable accidents happen. Therefore, a guard was installed, which complicates the handling a bit, but makes it safer for the employees.

The same should be true for the upgrade process. It would simply be good if a few safety measures were included, which complicates handling a little, but on the other hand creates a safer environment.

It has nothing to do with patronizing the user, but rather avoiding avoidable accidents, 99% of which are due to human error, as much as possible.

I know that experienced craftsmen simply work on the open circular saw because you think to be experienced, yet mistakes happen that can then cost a finger.

Ok with an update it is not a finger, but that the computer no longer boots is just as critical for a user.

Hope you understand that view.


This is an interesting thread I must admit, as there are always two sides to any coin.

I definitely get the impression that you’re all - each and every one of you - quite right in a number of your assertions.

1 Like

I am the son of a carpenter and construction worker - and I can say - no experienced craftsman tampers with the safety measures :grin: unless extremely careless … perhaps even outright stupid

You and I were in a previous discussion here that linked to the UbuntuStudio Wiki, where RT kernels have been dealt with by polemic FUD since 2020
(IMO this was probably intended to deter users from moving to AVLinux)
I agree that most users do not need RT kernel, even for JACK, but appealing to fear is not necessary
(Anyone interested in audio and/or RT kernels should check out: Are Real-Time Kernels Safe? - LinuxMusicians )

I am not sure why Arch/Manjaro “does it this way” either, but I like the tools Manjaro has developed to make changing kernels simple

My main consideration with a Linux kernel is whether it can run all my favourite audio packages reliably and sound awesome. Most Linux distributions can do this easily.
My personal choice for optimal audio awesomeness is based on many hours of extensive partying testing: Manjaro Xfce + standard kernel ROCKS

it would make more sense to have this feature as an on-demand thing like current tools mhwd and Manjaro Settings Manager. If the new kernel packages do not install exactly as expected, user might want to check the new packages are OK before reboot/shutdown

lock reboot/shutdown/suspend/hibernate services while the upgrade is working.

I am not sure if it is possible to block all the ways a user could reboot/shutdown/suspend/hibernate or kill/cancel/interrupt update process

Developers should not be restricting user’s freedom to do even the stupidest of things. If some users learn from mistakes and share ideas for better practice other users can learn from their mistakes

IMO one thing that may be helpful for new users would be to make the update messages more prominent in pamac-manager so users can see what is going on
How many new users might not notice the arrow in the bottom right corner?
If pamac-manager could switch to message window or display it as a secondary window, new users would at least have better information about what is going on and could copy/paste anything they are not sure of here
They might also see messages about EOL kernels too

1 Like

You sure it wasn’t another user? I don’t remember discussing RT kernels.

Changing kernels is not the issue.

The problem with Arch Linux and Arch-based distros, such as Manjaro, is that a minor kernel update “pulls the rug from underneath your feet”.

Debian, Ubuntu, Mint, etc, handle this properly by using a meta package for a major kernel version, with separate packages for each minor kernel version. No interruption in workflow before reboots, and no confusing issues, such as this one. Reboots on those distros are not “borderline required” after kernel updates. You can continue to use your system uninterrupted, and reboot at your own leisure. A reboot isn’t simply an inconvenient waste of time: It also breaks workflow and flushes everything from RAM, including cached data. This has a performance penalty.

To manage, prune, and cleanup kernels, etc, is not exclusive to this either, so “size” is dealt with regardless of distro as long as you prune your older kernels manually or automatically.

1 Like

I would vote for:

  • When there is only ONE kernel installed
  • AND this kernel is EOL
    → Warning which has to be acknowledged [Ok i have read]
  • OR this kernel is not any more in the repository
    → Interrupt update, only possible with additional parameter/switch [Ok, I know what i do]

In addition, the recommended command line for mhwd-kernel could be output.

Ideally, mhwd-kernel would then NOT issue any unnecessary warnings :wink:

I confess:
This has happened to me at least twice up to the point of “unbootable”. (Even when i had 3 kernels installed, all of them where unbootable) I was able to fix it, but it would be really nice not to have to have it in the first place :wink:

Why not include a Voting for:
(I’ve had it ONCE, TWICE, THREE times, more often. I had to help others with this.)


They weren’t unbootable, they were deleted. Don’t interrupt update and then reboot.

No, i did not interrupt the update!
And the kernels DID exist. But the modules where missing :wink:
(full story in old Post :slight_smile: )

Fact is that while performing an update (including kernel-updates)

  • At some point in time the update-process deletes ALL kernels
  • Then a lot of work is done (Which can eventually fail)
  • Then later on the kernel is reinstalled
  • Then grub and initrd’s are rebuild

This is done for ALL kernels at the same time !

If done one after another, I would have had a bootable system.

Even an update-process can break to the point you have no choice ( only to REISUB)

P.S. I do manage the update-process for over 30T devices with linux.(not manjaro)

1 Like