Improve upgrade process (especially kernels)

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

Yes, right here:

:: Running pre-transaction hooks...
(1/2) Removing linux initcpios...

/usr/share/libalpm/hooks/60-mkinitcpio-remove.hook is ran, which in turn executes /usr/share/libalpm/scripts/mkinitcpio-remove.

So feel free to improve this process by modifying the script. Another option is having some kernel that doesn’t get touched by update. Or have an iso image in your grub. :man_shrugging:

Sure. But are you saying that that can only happen on arch/-based distros?

Anyway, there is/was a lot of topics about that and we are still where we are. Example from 8 years ago: Autoremoval of old kernel-stuff on kernel update / Pacman & Package Upgrade Issues / Arch Linux Forums

No this is not a problem of the distro itself. It is a problem of the update-process.
When you handle kernel-updates using the same methods as for every other package, you end in a process where even the use of several kernels lead to an easily breakable update.

When you think of the kernel and modules as of a very valuable resource, you need to take special care of them during the update.

For example you could make the update for kernels in an serial fashion.

  • Delete ONE kernel
  • and modules,
  • update them,
  • recreate initrd and grub
    Then after this is completed (and synced) do the next kernel. This is by far not unbreakable, but it is better than now.

Der Krug geht zum Brunnen bis er bricht.


I think we can all agree that update process could be better. But can someone come up with an actual practical implementation that won’t require rewriting 10 other packages and changing who-knows-what? Just being realistic here. :slight_smile:

What about

Including the existing mhwd-kernel into the startup of the update-process ?

  • When there is only ONE kernel, do the normal update
  • When there is more than one kernel:
    • prefer to first update a non-running kernel !
    • prefer to first update a LTS kernel
    • prefer to first update the newest of them
    • Do a kernel update of this selected kernel with mhwd-kernel
      Yes this is a partial update, but it is inside the complete Update-process
  • While there is another updateable (non-running) kernel
    • Do a kernel update of this selected kernel with mhwd-kernel

Then do the rest of the update (including the running kernel)

  • The update-process then will not touch the already updated kernels, so they are save from harm while doing the rest of the update

It even may be possible to do this as a form of pre-update-script

Yes i did not realy look into the update-programms. If desired, I can take a look at the programs and then suggest a more realistic design. :bowing_man:

Yes rewriting would not be a good idea. Because there would be new errors in this critical process.

mhwd-kernel is just a bash script that calls pacman.

You can write another script that does multiple pacman updates and uses --ignore <find whatever kernel and any other package that "depends" on it like headers, modules and whatnot> - you can probably just repurpose some of mhwd-kernel script.

Anyway, this is a lame solution and you need at least two kernels installed. So it’s easier to just install linux-mainline or any other linux kernel from AUR (beside kernels from repo) and then just update repo first and after AUR. This alone will ensure a working kernel. Simple. :stuck_out_tongue: