For the first time in quite awhile some issues seemed to show up in Manjaro trying to run “pacman -Syyu” … . seems to have something to do with “locales”?
I’ve noticed the “locales” running in a number of my other system, it took awhile but they went through . . . . In the case of my Manjaro MATE edition on ye olden MacBookPro '09 era . . . failure. Tried it a couple of times. There were three “replace kauth with extra kauth”?? Type of questions which I said, “yes” to . . . //
glibc-locales: /usr/lib/locale/zu_ZA.utf8/LC_MEASUREMENT exists in filesystem
glibc-locales: /usr/lib/locale/zu_ZA.utf8/LC_MESSAGES/SYS_LC_MESSAGES exists in filesystem
glibc-locales: /usr/lib/locale/zu_ZA.utf8/LC_MONETARY exists in filesystem
glibc-locales: /usr/lib/locale/zu_ZA.utf8/LC_NAME exists in filesystem
glibc-locales: /usr/lib/locale/zu_ZA.utf8/LC_NUMERIC exists in filesystem
glibc-locales: /usr/lib/locale/zu_ZA.utf8/LC_PAPER exists in filesystem
glibc-locales: /usr/lib/locale/zu_ZA.utf8/LC_TELEPHONE exists in filesystem
glibc-locales: /usr/lib/locale/zu_ZA.utf8/LC_TIME exists in filesystem
Errors occurred, no packages were upgraded.
User: Are the the package databases up to date on the server? I’d like to update my packages. (pacman -Syu)
Server: Yes
User: I don’t care, I’m going to abuse the server and waste bandwidth anyway. (pacman -Syyu)
Also, it will definitely cause problems if a mirror is out of date.
OK, thanks for the reply . . . seemed like until now Manjaro took care of all of its needs . . . automatically. Like with the keyring updating and so forth . . . .
I’m away from that machine now, have to check it later . . . .
Thanks for your answer. I encountered the same issue as the original poster (I am in the stable branch). Although I’m relatively new to Manjaro, my previous upgrades were pretty smooth. However, it was quite frustrating to discover that I had to manually install glibc during this specific upgrade. I can’t help but wonder if the developers could have addressed this issue to ensure a smoother and more user-friendly upgrade process.
There was a time, years ago, when yy was mostly encouraged after something like changing branches or sorting mirrors … but these days even that is not required. yy should only be used if absolutely necessary … you may be surprised how rare that is.
OK, thanks for the explanation . . . as I mentioned, for the most part my Manjaro install has been so trouble free, that I now run it on two machines . . . . I think when I first installed it a few years back, not ten, but not one year . . . the wiki or the forum just showed that “yy” as the preferred way to maintain the system . . . . And, in comparo to many other, let’s say “ubuntu” where “apt update && apt dist-upgrade” is the regular commands to run, the Manjaro command is simple.
Easy enough to just type one y . . . . I would concur with the other poster asking why, all of the sudden, the end user would have to know to install a package manually to get a clean upgrade?? Or, like today for the first time in forever, Manjaro had the three questions to answer before moving forward, one of them could have been, “would you like us to install gliblc for you? y/n?” : - ))
I’m not sure I follow.
The difference is just the forced refresh … 2 y’s forcefully does it even if not required … one y only refreshes as needed. Both examples accomplish ‘apt update && apt upgrade’ … its been long enough that I cant recall if there is a ‘force update’ equivalent in apt … if so that would be the 2 y’s.
It has always been the case that one should be up to date before installing a new package, and never sync without upgrading …
So to install a package one does notpacman -S package notpacman -Sy package
but does use
sudo pacman -Syu package
This … I dont know what you refer to … but pacman has always prompted the user for package replacements.
As to pamac … I couldnt say.
Oh … manual intervention required for stable branch in the case one has an old version of glibc-locales installed …
Yeah. Sometimes manual intervention is required. Notice the rest of the announcements?
Does this also mean you have been ignoring your pacnews?
pacdiff -o
Manjaro is not a 'I never have to do anything myself" distro.
Getting back to this, I don’t know whether I had the old “glibc-locales” package installed . . . I wouldn’t even know if I have the “extra repo” installed . . . . Just basic Manjaro as the installer installs it . . . no time for messing around with the internals of it.
“Ignoring” my pacnews??? Haven’t had to do anything very much to keep Manjaro going, so, yes . . . not up to date on the “news” associated with running a linux install. In comparison to my other “rolling” distros where stuff seems to blow up with regularity . . . the need to scan 'the news" has been more critical elsewhere.
I’m a rank newbie when it comes to the care and feeding of the arch based system . . . largely because Manjaro seems to run very well with the “hand’s off” style . . . only needing intermittent -Syu to keep it going.
When I get back to the machine that is having this “failure to upgrade” problem I’ll have to rifle around a bit and see if any of the clues provided here help to break through to . . . the other side.
You may also be interested in the thread I linked back to here from.
You can follow it by clicking the link that is now above your last post.
I mention it because the user there had a similar problem … and it was revealed that pacnews were at play … as well as an outdated mirror.
Pacnews seem scary to some at first but its really just some basic comparison … once you have this backlog of them managed … you will then notice you get one every now and again, but it wont be a big headache.
Good luck and report back. Cheers.
OK . . . yes, seems like somebody else marked this post as the “solution” before it was run . . . running the “-Syu” and answering the three questions did not run the upgrade.
After I ran the suggested “overwrite” command, the pacman processing moved forward . . . now back to our regularly scheduled programming . . . .
Note: the solution might not work in a non-POSIX-compliant shell (probably has something to do with wildcard handling). I tried to run it in nushell and it gave the same error. Running it from zsh worked.