[Stable Update] 2020-11-27 - Kernels, Browsers, Maui-Apps, Pamac 10.0-Beta, Gnome, Mesa, Qt

Latest commit at this point has 5.4.80-1 but branch compare lists 5.4.80-2.
Now that I thought about it some more: could just be an upstream (kernel.org) update though and nothing in PKGBUILD needed adjusting…

To the cups fix I have a comment.
I hoped I find any solutions here after I did the update and realized the error in KDE Printers.
I love this distro, but this is not really a user friendly in Manjaro. I switched from KDE Neon and I am not used to so many manual hackings after each update.
What if an average user does not check these posts regularly at every update ?
Why not automated with a package or asking for manual interventions when running the update ?
I have a HP LaserJet 1020 and it does not print with hplip .(Filter failed)
It works in each Debian and Ubuntu based distros. I need the foo2zjs01-nightly free driver which is in AUR only in Arch/ Manjaro.
Compared foo2zjs is default to hplip and available in repos in Debian and Ubuntu.
Thanks so much

update went smooth on 2 machines

  • Desktop ( Kernel 5.9 & Gnome )
  • Macbook ( Kernel 5.4 & Gnome )

Shouldn’t this contains tail -n 25 or --lines=25 instead?

1 Like

It was a rhetorical question and more like a bug report. Something within this update has created this user into my /etc/passwd and linked it to some unexisting executable. Or removed the /run/ceph file and forgot to remove the user.

$ cat /etc/passwd | grep ceph
ceph:x:340:340::/run/ceph:/usr/bin/nologin

Never had official repos “ceph” installed, but have official repos “ceph-libs” (not your linked AUR version). But neither of them include file /run/ceph either. “ceph” package (which I have never had installed in the first place) has /usr/bin/ceph though.

I wonder why it has not been automated with some scripting in post upgrade though. It could have been put in post upgrade of cups.

Manual interventions are not that common, but I also think that this one was avoidable indeed. As for KDE Neon (or any fixed release distro), the tinkering (if it is needed) happens more between distro upgrades.

Thanks a lot!!
Now I have your information for future problems.

I can also confirm. 5.9.11-3 did the trick.
The problem is fixed.
Everything is back to normal.
There are no messages when I shut down or reboot the system.
Thanks!

The cups renames were mentioned while updating (at least on the terminal but methinks it would be visible in pamac-GUI as well) and one should always pay attention to output while updating.

1 Like

I find it very funny how the maintainer from Arch Linux (it is a package imported from Arch with no modifications) had made a lot of effort to write this whole technical speech in post upgrade on how to do it, without actually doing the job itself in post upgrade by putting the relevant bunch of systemctl commands. The “Arch philosophy” blows my mind on so many levels sometime on how counterproductive it can be.

1 Like

Cinnamon, 5.4, all good. Thanks much.

Not everyone use printers and not every one have this service started, so why package to force you do something that you don’t want to do. It is just philosophy of the package maintenance.

1 Like

Sorry, didn’t catch that one :slight_smile:

The link is correct, it is ceph-libs 15.2.6-1. Its community repo that is in question, AUR is totally different, never mind…

I checked mine /etc/passwd and I don’t have ceph user, nor /run/ceph, nor /usr/bin/ceph.
The package ceph-libs comes with the system I guess. I have it to.

Now why would something create a user, I don’t know, but the system is using this package I think.
Check

sudo find /usr -name 'ceph*'

/usr/lib/modules/5.4.80-2-MANJARO/kernel/fs/ceph
/usr/lib/modules/5.4.80-2-MANJARO/kernel/fs/ceph/ceph.ko.xz
/usr/lib/modules/5.4.80-2-MANJARO/kernel/net/ceph
/usr/lib/samba/vfs/ceph.so
/usr/lib/samba/vfs/ceph_snapshots.so
/usr/lib/ceph
/usr/lib/ceph/ceph-osd-prestart.sh
/usr/lib/ceph/ceph_common.sh
/usr/lib/ceph/ceph-monstore-update-crush.sh

Hope someone from the team can really help you, 'cause its weird.

In that scenario, systemctl is-enabled UNIT can be used. The exit status will give if the unit is enabled or not on the system and then, according to the exit status, you do the transition or not. You would have something like:

if systemctl is-enabled OLD_UNIT then
    systemctl stop OLD_UNIT
    systemctl disable OLD_UNIT
    systemctl enable NEW_UNIT
    systemctl start NEW_UNIT
endif

Repeat for each unit that needs a transition. Maybe put a for loop if wanted.

7 Likes

or just write message while install package :smiley:

1 Like

Now the Files listing has been refreshed, too.
Everything is fine.

Lessons learned:
Do not trust what you see at first view
Gitlab is a great source of information
but in this case not very helpful.

Because I know my environment very well
in some cases I just want knowing reliably
the hows and whys things change
so I can decide to apply a patch immediately or wait (for example).

Thanks for your hints

Seems manjaro wiki is down with a case of the Vid, or something

5 posts were split to a new topic: Org.cups.cupsd.service not found

Hi philm,

after stable-update-2020-11-18 I had a black screen after boot (Black screen after [Stable Update] 2020-11-18) although I had the latest sddm version. I kept upgrading and this update also did not solve the issue, but downgrading to sddm 0.18.1-3 solved it.

So I think perhaps there might be something that manjaro team can do, so I don’t have to stay on that version “forever”, or do I need to file another sddm bug report?
Perhaps you could add it to the Known issues and solutions section.

This seems to be different from the PAM and PAMBASE issue, since I don’t have a system-auth.pacnew

  • I’m an idiot! :grin:
  • Copy-paste error
  • Edited now
  • Thanks for the feed-back!

:+1:

2 Likes