Synaptic & gparted show "authorization failed" in new 26.04 system?

Folks:

Recently tried to run “do-release-upgrade” to move up to resolute . . . on my ‘12 Mac Pro edition of Lubuntu that I have been running for many years, and that “failed” as posted in the “26.04” thread.

I then did it my usual way of editing the sources.list to “resolute” and that ran through OK upgrading some 1974 packages?? However on cold boot rather than going to the multi-boot grub page it went to a single “Lubuntu 19.10” grub page . . . which then went to a black window, as it has been awhile since 19.10 was installed. Tried a few moves to get back to the regular grub window, but all of them failed.

Finally got the SuperGrub2 flashdrive out and booted to Resolute, thinking the upgrade had installed grub, but it did not. I ran a sudo dist-upgrade and upgraded a few packages. Finally figured out that the upgrade had messed with efibootmgr boot order, setting “1910” as the first boot, for which, there was no 1910 install, so it went to black. I reset the boot order and that restored the multi-boot grub window. Updated the bootloader in the system that handles osprober and then booted to Lubuntu. First time it did not log in, shut down and cold booted to get to the Lubuntu log in and second time it did log in.
uname -r shows kernel 6.2.2 as running and trying to find out what system I am running and in what partition, trying to launch gparted “fails” . . . not authorized. Tried to launch synaptic also fails . . . but HTOP launches fine. I launched ubunut mainline kernel app . . . it showed the same “authorization failed” but then it loaded the kernels up to 6.19 . . . I tried to install 6.12.0 via the GUI app, that “failed” . . . ???

Any thoughts on why upgrading via the sources.list will run fine, I can use sudo to run dist-upgrade, but then trying to move the kernel up, fails??? What would I have to do to get the entire system working . . . as one?? Certain apps like the console are “authorized” but others are not?? Seems like a “mixed bag” for the resolute packages??

I’m in the process of exploring an install issue, and have done a number of installs (of resolute) today, and given I’ve just completed evaluating one (prior to marking the testcase successfully complete) I installed gparted and synaptic on it.

Both gparted and synaptic run without problem, on that FRESH install, plus my own install here on my primary system running Lubuntu resolute.

This box [I’m replying on] used the do-release-upgrade -d step, the other box I started this reply talking about is a fresh install using the current daily (20260224), YET you mention a Debian install upgrade procedure which can result in a partial upgrade and missing some Ubuntu procedures/changes that occur during the release-upgrade process.

Your resolute install may not match either a fresh install from media; or a correctly release-upgraded install either, as you upgraded packages (which do-release-upgrade will do yes) without the additional things that can occur in the release-upgrade process (these additional steps are release specific & make changes that are Ubuntu specific and relate to changes between releases!).

Both my fresh and release-upgraded installs run synaptic & gparted without issue.

2 Likes

The old Ubuntu wiki would inform us that the do-release-upgrade command was for Ubuntu Server. The man page says this

do-release-upgrade [options]

DESCRIPTION
Upgrade the operating system to the latest release from the command-line. This is the preferred command if the machine has no graphic environment or if the machine is to be upgraded over a remote connection.

Notice: “No graphic environment.” I have long been of the opinion that when doing an online upgrade from one Ubuntu release to the next it would be best to switch from a proprietary video driver to an open source video driver.

The man page says this about the -d switch:

-d, --devel-release
If using the latest supported release, upgrade to the development release

In this case from Lubuntu 25.10 to Lubuntu 26.04 development release. So, what was the original release? That information is not given.

In the past I would use the editing the sources.list URLs method to upgrade to the development release. I would not recommend doing that now because of the Ubuntu “modernise” movement.

The second post in this Ubuntu Discourse topic by @popey explains what is happening to Ubuntu

Understanding what “modernise” is changing in Ubuntu

So, I conclude that upgrading from a non-modernised OS to a modernised OS without waiting for the official upgrade path to be opened is going to result in problems. I do not know if that is the situation in this case.

I also learnt a long time ago that it might seem clever to upgrade from release to release again and again but things get left behind and we end up with a mess. Big differences occur over time. Lubuntu/Ubuntu 26.04 LTS is going to be very different from Lubuntu/Ubuntu 24.04 LTS. This will be true, in my opinion, even if the Lubuntu desktop environment is not changing much. The underlying Ubuntu is changing.

Another thing I learnt running the development version over many years is that a re-install solves all problems. It is quicker.

I know my reply is not helping to solve this problem. It might help someone reading this topic to learn something that they did not know.

Regards

Thanks for the replies on it . . . typed that post up quickly last evening after I had spent some time trying to figure it out. Briefly, upgrading from 25.10 to 26.04 using the -d modifier is what I tried to do, but it errored out and would not even start the process.

But, since around ‘14 or so I have been running Lubuntu on that machine, and in spite of several folks, likely Mr G as well, saying, “I don’t recommend editing the sources.list,” that is how I have moved from developmental to developmental . . . without it causing a problem. I also do that on my non-Sid Debian install, and there I have yet to “modernise” the sources. In Debian I have one or two lines in that file, in Lubuntu 12 or more?? I haven’t added any lines or taken any out I just edit the version word in the line. And, in this case the do-release-upgrade didn’t work . . . after installing it.

I did use that tool to upgrade Lubuntu on my newest Ryzen based machine and it worked fine.

The other oddity is the system choosing “Lu 1910” as the first boot option, for which there was no kernel attached to that . . . and then the 6.2.2 kernel . . . .

One thought I had is if there is some “key ring” that might have expired in that I might not have booted that install of Lubuntu on that machine for a month . . . would that cause some “authorization” problems?? Synaptic and gparted have been installed for many years, but now clicking on them or trying to launch from the console say, “authorization failed. this will be reported.”

But, then I can run apt commands in the console . . . sort of a mixed bag. I hear the “fresh install” suggestions, but frankly on this aging machine I think the hardware is “v1” and might be falling behind the curve . . . and seems like the original ‘12 HDD that Lubuntu is installed on is palpably “slower” that the SSD drive . . . . I’d just like to see if I can repair what is there now, if possible . . . but no errors were shown after several dist-upgrades done after the change to the new devel system.

The core point of update-manager (and its CLI tool do-release-upgrade) is to actually do transitions on a per-package level where needed, during upgrade testing the QA and dev teams identify packages and system settings that require any quirks and apply them to the update-manager code … This is particularly important for LTS releases where there are 2y between the package versions in which they might have gone through several upstream release iterations (i.e. the configuration file format might have changed completely, databases might need transitions etc)

While you can just edit your sources.list in debian this has not been supported in Ubuntu ever due to the known issues this brings along if your user-space is actually skipping release versions of the apps and plumbing layer … so if you do an upgrade that way you are pretty much on your own to find and fix the issues that otherwise the update-manager would handle for you …

All that said, if you upgrade from one pre-release to another over several releases you will in any case have a lot of cruft left behind due to that method (update-manager also handles removal of known unused bits that packages might leave behind when they skip several versions)

In general I’d personally not use such a machine in production or even connected to the internet and rather do a fresh install with the proper release…

3 Likes

OK . . . “alone again, naturally.” I am not sure how else to post, as I have done several times in this thread, and reported it over in the “26.04 thread” that I tried to run the upgrade using the do-release-upgrade -d” command and it showed the error I posted in the other thread. I got no response or reply on that post.

So, based upon that error . . . the error that happened while I was trying to do it the supported way . . . I went back to my former behavior to edit the sources.list, which provided a perfectly working system since approx ‘14 . . . in spite of the “you can’t do that and expect support from us” . . . . I wasn’t asking for comment on that approach, because I had tried the supported way and . . . it didn’t work, etc.

The thread is asking for advice and comment on why for a few of the apps (as mentioned in the subject line) would show “authorization failed” when trying to launch them, but would not show when running a sudo apt in the console?? So far no help has been provided on the actual question in the subject line . . . .

Another hint, at some point in this process a crash report window opened showing “X compositor has crashed too many times” . . . but then no further bug report window opens.

In the olde days of the ubuntu forums some 15 years back, folks would actually dig into a problem and give accurate guidance on how to repair . . . like “run a fsck and see what happens” but over time the advice is . . . “you are on your own,” which as I get closer to 70 years on the planet I find that amusing . . . but not really helpful for a long time user of Lubuntu. But, based upon the sage advice provided I ran a “sudo apt remove all-cruft” in the terminal and it showed many lines with the words “cruft” and then it showed like an animation of little munchkins chewing up the “cruft” and it is now all gone . . . the “cruft removal” process has cleaned the system . . . all-cruft is un-crufted.

Still the question of why there is a failure to authorize the launching of the two apps remains iin the un-crufted system???

Have you considered that …

Might be the actual cause of it ?

This looks like another fallout where update-manager would normally be cleaning up old bootloader entries during an upgrade …

I’d really do a backup of my data and a fresh install if i were you, it is hard to predict what else has been messed up over the years if the above is true and you have gone from development pre-release to development pre-release over multiple releases by just editing your sources.list …

2 Likes

Posting the data from Feb 15th on the “resolute thread” showing the errors that were reported when I tried to download or run the do-release-upgrade tool . . . . So, vis the grub clean up, historically I have run multi-boot on numerous machines, systems added and removed and it does seem like “grub” stores all of those systems, because when I boot to SuperGrub2 drive it shows all of the options, in spite of some being fresh installs or in the case of Debian and Lubuntu editing the sources . . . .

Seemed to have hit an error trying to move from Questing to Resolute on my ‘12 Mac Pro using “sudo do-release-upgrade -d” . . . showing in the QTwidget window:

Traceback (most recent call last):
  File "/tmp/ubuntu-release-upgrader-e8kgw785/resolute", line 8, in <module>
    sys.exit(main())
             ~~~~^^
  File "/tmp/ubuntu-release-upgrader-e8kgw785/DistUpgrade/DistUpgradeMain.py", line 222, in main
    from .DistUpgradeController import DistUpgradeController
  File "/tmp/ubuntu-release-upgrader-e8kgw785/DistUpgrade/DistUpgradeController.py", line 43, in <module>
    from .utils import (url_downloadable,
    ...<5 lines>...
                        inhibit_sleep)
ImportError: cannot import name 'inhibit_sleep' from 'DistUpgrade.utils' (/tmp/ubuntu-release-upgrader-e8kgw785/DistUpgrade/utils.py)
=== Command terminated with exit status 1 (Sun Feb 15 16:06:41 2026) ===


Thinking it was because I haven’t booted this system for a month I ran “sudo apt autoremove” through which removed approx 124 packages . . . then back to the “do-release-upgrade -d” and got the same error in the upgrade widget and then “x”-ing out of that window to regular terminal shows:

Continue [yN] y
Get:1 Upgrade tool signature [833 B]                                                                                                                
Get:2 Upgrade tool [953 kB]                                                                                                                         
Fetched 954 kB in 0s (0 B/s)                                                                                                                        
/usr/lib/python3/dist-packages/DistUpgrade/DistUpgradeFetcherCore.py:178: Warning: W:Download is performed unsandboxed as root as file 'resolute.tar.gz.gpg' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
  result = fetcher.run()
authenticate 'resolute.tar.gz' against 'resolute.tar.gz.gpg' 
extracting 'resolute.tar.gz'
[screen is terminating]


Historically I have edited the repos on /etc/apt/sources.list to upgrade the system, but just checking to see if WOTL would say “the machine is too old for Resolute”???

I was able to launch the “unauthorized” apps, as well as mainline as root in the console. Upgraded the kernel to 6.12.6 and subsequent launchings didn’t require root. The clues were there in the subject line . . . it’s usually something “simple” to get to a resolution.

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