Announcement

Collapse
No announcement yet.

Once-normal apt/deb packages are now all lumped together as a "System Upgrade" that requires reboot

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Once-normal apt/deb packages are now all lumped together as a "System Upgrade" that requires reboot

    Hello everyone! This is a problem I've been having for about a month now, and the forums I've tried thus far have been fruitless, so I thought I'd say what's been happening here.

    Before December, any packages I had installed on my Kubuntu LTS 22.04.3 laptop as normal system packages (be they through the Ubuntu repos, PPAs, or downloaded deb files) were all listed individually in Discover. Trying to update any and all of them required me to input my password after hitting "update selected" in Discover.

    Starting in December, however, all packages installed this way, regardless of origin, have been getting lumped together into one big update option, labeled "System Upgrade." This would include core libraries and programming languages, to things like Spotify and Google Chrome. That is, somewhere, Discover started viewing all of these as the same.
    Click image for larger version  Name:	image.png Views:	0 Size:	120.5 KB ID:	676087​
    Say I had google-chrome-stable, libc-bin, and​ firefox​ all needing updates. Under System upgrade, it would say "3 packages to upgrade." Alone, this is innocuous, but the problem is that updating these packages through Discover does not prompt me for my password. That is, somehow Discover is bypassing sudo (or has been opened with sudo already active), whereas before it would always prompt me, and nala/apt still requires me to do so. Finally, after updating this "System upgrade" (which sometimes is literally just Firefox), I am prompted to restart my system, and I am unable to download any more updates until then. That is, if I have flatpaks that I now need to update, but I installed that "System upgrade" update, I am not shown those updates until I've restarted.

    This is incredibly strange behavior that I've never seen happen before. What might I be able to do to figure out the cause? And perhaps return my Discover to its original working order?

    And yes, the command line does work, but I'd prefer not to receive any replies saying "just use apt?". That would be ignoring the problem, rather than fixing it. I still have a faulty software manager on my system at the end of the day, and I do not want that to be the case!

    Thank you in advance for any responses!!! 😄

    Edit: Because I forgot to mention this: nala shows that the python3-update-manager and update-manager-core packages are being held back; this has been the case for at least 3 weeks, potentially since this whole thing started.

    #2
    I've filed a bug report as well, though apparently Plasma 5.24 is no longer supported despite being the LTS release with Kubuntu, so if it is, in fact, a Plasma bug, I'll likely be stuck with it until April.
    https://bugs.kde.org/show_bug.cgi?id=479609

    Comment


      #3
      I am going to guess that you recently upgraded your Plasma 5.24 via the Backports and/or Backport-Extras PPA?

      You have the offline-updates option enabled. You can click on that one update entry and see what it consists of:

      Click image for larger version  Name:	Screenshot_20240110_102301.png Views:	0 Size:	294.5 KB ID:	676090
      Look in System Settings at the bottom and un-check the Offline Updates option, and restart Discover.

      Click image for larger version  Name:	Screenshot_20240110_102232.png Views:	0 Size:	167.4 KB ID:	676091
      You don't need a sudo password prompt for something that is being run as 'root' user during bootup., so that is not a bug.

      More descriptions on offline updates
      https://www.freedesktop.org/software...e-updates.html
      https://blog.neon.kde.org/2021/03/01...es-are-coming/

      Originally posted by Domojestic View Post
      python3-update-manager and update-manager-core packages are being held back; this has been the case for at least 3 weeks, potentially since this whole thing started.
      These are being phased by Ubuntu https://ubuntu-archive-team.ubuntu.c...d-updates.html
      if you are impatient, you can manually install the packages being held.
      Phasing is sort of random in who sees these each time, but is nothing new in *buntu, it having been in regular use since 22.04 came out. Using Discover, you just never see that is has happened.
      Last edited by Snowhog; Jan 10, 2024, 10:06 AM. Reason: Spelling error

      Comment


        #4
        Originally posted by Domojestic View Post
        Plasma 5.24 is no longer supported despite being the LTS release with Kubuntu,
        This is because they made 5.27 the current LTS version of Plasma, which happened earlier than usual, and I don't think was planned to be at the time, when 5.24 became LTS.

        Comment


          #5
          Originally posted by claydoh View Post
          I am going to guess that you recently upgraded your Plasma 5.24 via the Backorts and/or Backport-Extras PPA?

          You have the offline-updates option enabled. You can click on that one update entry and see what it consists of:
          I don't recall every upgrading 5.4 via the backports, but I'm pretty forgetful...

          Case in point, THANK YOUU!!!!!!!! 🤩🤩🤩 That's exactly what it was! I almost remember enabling this, but I'm sure I had to. I'm so glad this was just me being silly and not something more insidious...

          In any case, how I guess the activation of sudo occurs when I'm logging into my system again?

          Comment


            #6
            Originally posted by Domojestic View Post
            I don't recall every upgrading 5.4 via the backports, but I'm pretty forgetful...
            I was thinking of places that might be a reason for a settings change to happen.

            Originally posted by Domojestic View Post
            In any case, how I guess the activation of sudo occurs when I'm logging into my system again?
            It is happening in a very low level session early in the boot process, where there are no user accounts available or needed - the recovery options in grub, for example, act the same way, no user passwords.

            Comment

            Working...
            X