Upgrade over a rolling distro?



I am new on Manjaro and today I have been proposed a ~170 packages update. I agreed and then my keyboard has been disabled on LightDM connexion. Fortunately I could restore my Manjaro with Ubuntu and Timeshift.

How to redo the update and fix the keyboard detection ?


I don’t think you can restore Manjaro with Ubuntu and it’s version of Timeshift. I would look up and write down the pacman commands to redo the update and typing in the commands by booting to the command line from Grub or the Livemedia.


Welcome to Manjaro! Something I always suggest to new users is to take a look at the update announcement and read through the known issues before applying updates.

Timeshift is also available in Manjaro, but you may also want to install the Downgrade package so you can roll back to a previous version should something go wrong (I’m looking at you, NetworkManager!).


The Update announcement is here:

Do you have an HP computer? This may help:


“Fortunately I could restore my Manjaro with Ubuntu and Timeshift”
If I say could do it, please believe me. I am just answering to you from a nice working restored Manjaro from Ubuntu’s Timeshift


If we look at known issues before applying updates, probably we won’t apply updates ever.
I already installed Timeshift in Manjaro. I make Ubuntu backups from Ubuntu and Manjaro backups from Manjaro. It is why I could make a Manjaro restore from Ubuntu (as well as I will be able to make a Ubuntu restore from Manjaro)

I installed “downgrade” and here is the result I get:
$ downgrade
Downgrading from A.L.A. is disabled on the stable branch. See https://wiki.archlinux.org/index.php/downgrading_packages for more details.
Utilisation : downgrade , … [-- ]
Voir downgrade(8) pour plus de détails.


Thanks for your suggestion, but my PC is not a HP laptop.
Any other idea to troubleshoot the keyboard disabling ?
Please can you explain me the the meaning of a “stable update” ?
It looks like an upgrade, what is the meaning of it over a rolling distro ?


Manjaro uses a Rolling Release Development Model, whereby rather than being replaced, the same core system will instead be continually updated and upgraded. As such, it is not – nor will it ever be – necessary to re-install a later release of Manjaro in order to enjoy the very latest and most up-to-date system possible. By virtue of keeping an existing installation updated, it is already the latest release.


Stable branch: the packages that come to stable have gone through roughly a couple of weeks testing by the users of the Unstable/Testing repos, before they get the packages. These packages are usually free of any problems.

Testing branch: These users are the next line of defense. Being a larger number of users than those using Unstable, they refine the work done prior to them installing the packages with their feedback.

Unstable branch: which usually runs inside of 3 days behind Arch package releases & are modified as necessary to suit Manjaro. Those that use Unstable need to have the skills to get themselves out of trouble when they upgrade into it. They are the Manjaro users who are most likely to need to use such skills. Due to the feedback from the users of the Unstable repo, most bugs are found & fixed for the rest of Manjaro’s users. Although the very latest software will be located here, using the unstable branch may consequently break your system!


Thanks for your explanations.
When a stable branch is updated with 164 new packages, it looks like the probability that a problem occurs is very high, isn’t it ?
What difference do you make between an update and an upgrade ?
I appreciate the Rolling Release Development Model, but is a 164 packages update so different than an upgrade process like there is in Ubuntu ? (from 17.10 to 18.04 for example)
If I use the testing branch, will the update process smoother in terms of number of packages to be updated at the same time (obviously not for the first update) ?


update or upgrade are only for fixed not for rolling ! for us we have only one.

attention, testing is precisely not tested so a beginner (as you ?) will often be blocked.
Normally you should not have a problem with a stable upgrade(update) but it depends a lot on your hardware; if not standard then there is a risk (not having been tested in testing).


why call it stable then?

(and testing, unstable?)

as stable basically means not so new pacakges, maybe issues occured for other users ( in testing/unstable) and they gave feedback and the issue was fixed until the package ot in stable.
maybe there was an upstream issue which is already fixed upstream (testing user didn’t run into that issue) but stable is 1-2 weeks older, didnt get upstream fix yet and bug occurs in stable

Imo pretty unreliable way to call something stable


I agree.
Maybe the update rhythm for the stable branch should be more or less the same than the testing branch, but with a delay used for testing and debugging. It would not make the stable version more stable and I should have had the same problem with my keyboard, but at least, it would allow daily connected users to reach bugs during small updates.


if we have a new version upstream, the new package go to testing for somes days et never directly in stable !

I was just saying that the testing community is small and so it is possible that some cases have not been seen.

the debates on the testing and stable branch have existed for more than 5 years :wink:
In fixed, they freeze for 6 months, here we freeze for 8 days is already huge ! shortening this time would cause too many problems and we must not forget that it is the community that tests, with too short a time we would have very few returns.


yeah, but as example:
package x version 5 is in testing
upstream updates to version 6
5 days later version 6 goes to testing
version 6 has a bug
upstrean developer gets aware of the issue
upstream releases version 7
5 days later version 7 is in testing
testing user updates system, isnt affected by bug

“stable” branch:
version 5 is in repo
10 days later version 6 is in repo (nobody in testing noticed/ was affected by issue of version 6)

I dont say manjaro is a bad distro because of this

My point is, just get rid of the “user-friendly-as-its-best” statement and dont call a branch stable, just because of having delayed upstream updates (and some testing/unstalbe user maybe run in an issue and give feedback)

sorry for offtopic

regarding topic:

you could try another lightdm-greeter, not sure which one you’re using but maybe thats just the problem.
or just use another display manager (or none and just use startx to start x session)

(see old topic here where the problem was webkit-greeter and webkit update https://forum.antergos.com/topic/5180/login-issue-with-lightdm-webkit-greeter-not-accepting-user-input?page=1 )


package x version 5 is in testing
upstream updates to version 6
5 days later version 6 goes to testing
version 6 has a bug
upstrean developer gets aware of the issue
upstream releases version 7
5 days later version 7 is in testing
testing user updates system, isnt affected by bug

Sorry but in your case, Testing has included bugged version 6 for 5 days.

topic: I redone the update with excluding “libinput” and for some reason:
1/ “libinput” has not been really excluded from update
2/ problem has disappeared

Thanks to everybody for this discussion

closed #17

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