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.
One step what could be done is doing for example kernel upgrades including dkms etc on reboot/shutdown.
And/or it could be possible to lock reboot/shutdown/suspend/hibernate services while the upgrade is working.
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.
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.
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.
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.
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.
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.
LInux (in this context Manjaro) != Windows and Manjaro != Ubuntu
This sentence is spot on
I therefore agree with @anon89812132 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 Tutorials section with numerous guides on how to achieve almost anything with Manjaro.
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.
I am the son of a carpenter and construction worker - and I can say - no experienced craftsman tampers with the safety measures 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
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.
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
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
Why not include a Voting for:
(Iâve had it ONCE, TWICE, THREE times, more often. I had to help others with this.)
unless extremely careless ⌠perhaps even outright stupid
)