<SOLVED> Upgrading Mint 20.3 to 21 dconf and ibus warnings

[jrw32982]

I am attempting to upgrade from Mint 20.3 to 21 via sudo mintupgrade.
The steps proceed smoothly until I get to "Running check 'Orphan packages'". I see in the console:

Code: Select all

(mintupgrade.py:2632605): IBUS-WARNING **: 14:11:05.748: The owner of /home/<myhome>/.config/ibus/bus is not root!

This statement is correct. That directory is owned by my user.

In the GUI, a bunch of packages are listed, which I want to keep. I go to Preferences -> Orphan packages -> click "+" to add a package -> enter a package name and press Enter. In the console I see:

Code: Select all

(mintupgrade.py:2632605): dconf-WARNING **: 14:14:31.940: failed to commit changes to dconf: The connection is closed

I've tried various fiddling with ~/.config/ibus/bus such as deleting it and changing it to root-owned, but after restarting the process I'm still getting the "failed to commit to dconf" error. I'd prefer not to turn off the orphan package check altogether, since I don't know what else it might do.

For example, after removing entirely ~/.config/ibus it gets recreated, owned by root, which gets rid of the first error message (but it shouldn't get owned by root in my home directory).

Any ideas on how to proceed to fix the errors?

[jrw32982]

I bypassed the errors by using sudo -i mintupgrade. I'm not sure why the instructions do not add the -i if it's required, but I guess there's something significantly different in my configuration than most people's since I'm not seeing any complaining about the omission.
I'm in the middle of the upgrade now and I will post again when it's done.
[EDIT] It finished successfully. I'm in the process of cleaning up things which didn't get upgraded properly, such as from external PPAs.

[Cosmo.]

There is a principal problem with the instructions to use mintupgrade. Nobody cared about it, even today the official instructions have these faults. Don't ask me, how such a mistake could happen, especially regarding the lightdm-settings the fault jumps into the reader's eyes.

[jrw32982]

Thanks for that confirmation, Cosmo. I couldn't find your post yesterday with my duck-duck-go-fu. I don't understand why I'm not finding more posts/questions about this issue screwing things up for people. I wasted 2+ hours yesterday trying to figure it out, wondering where gksudo went, hunting down other guides to upgrading, etc.

I still don't know for sure if sudo -i is a valid solution for this problem, but it fixed it (or at least bypassed it) for me. I'm sure I'll be searching for the answer to some related question in a few years when this conversation has passed out of my memory and I have the need to run some similar sudo graphical.

[Cosmo.]

I still don't know for sure if sudo -i is a valid solution for this problem, but it fixed it (or at least bypassed it) for me.

Sure it allowed you to do things, sudo graphical does that also, so this does not say anything about the question, if this is a valid solution.

Actually, it is not. Even worse: If you use sudo, your password gets stored in a cache (by default for 15 minutes), after that you must enter it again, if you use another sudo command. But sudo -i opens a root shell and there is no time limit for it.

If you are interested, you may read When should I use pkexec and when sudo -i as well as What is the difference between pkexec and sudo?. In short: Using sudo is much more dangerous.

Actually not every wrong usage of sudo creates immediately problems. If this would be the case, users would much quicker learn, that they did something wrong. But the fact, that not every misuse leads at once to trouble does of course not mean, that the wrong sudo graphical is the right command. From a Linux developer I expect, that he knows and respects this. Otherwise I must also doubt about other things. In case of the mintupgrade command one could assume, that the devs saved the time to create a polkit rule (but also this is not an excuse), but for lightdm-settings, where the rule already exists I do not find the least explanation, how such a fault can happen - and why it preserves for more than half a year.

[jrw32982]

Thanks for those links. After a lot of reading about pkexec I think in my use case (only running trusted GUI commands provided by the system, only needing to do this every few years, running on a single-user desktop) that just using sudo -i will be simpler. Bonus: maybe I'll even be able to remember to do that. But you're right: I don't see any reason why pkexec and policy kit wouldn't have been configured properly for mintupgrade.