Not upgrading: kicksecure-baremetal-gui-lxqt

Support
1

I’ve been trying to upgrade my bare metal Kicksecure and want to report the confusing experience lately.

I first clicked on the “Install Updates” button by habit and got this.

/usr/bin/upgrade-nonroot
<snip>
The following packages have been kept back:
  kicksecure-baremetal-gui-lxqt
<snip>

I tried to manually run sudo apt full-upgrade and even dist-upgrade but those didn’t do the trick either.

% sudo apt dist-upgrade
Not upgrading:                  
  kicksecure-baremetal-gui-lxqt

Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 1

On top of that, sudo apt upgrade --with-newpkgs gave the exact same result. (FWIW, --with-newpkgs is not valid with full-upgrade or dist-upgrade.)

I ended up having to explicitly type the name of the meta package.

% sudo apt install kicksecure-baremetal-gui-lxqt
Upgrading:                      
  kicksecure-baremetal-gui-lxqt

Installing dependencies:
  dist-baremetal-gui-all

REMOVING:
  virtualbox-guest-utils  virtualbox-guest-x11

Summary:
  Upgrading: 1, Installing: 1, Removing: 2, Not Upgrading: 0

If I understand correctly, the usual workarounds don’t work because the new version both adds and removes dependencies. Compare this to whonix-gateway-vm-gui-lxqt on my VM, which worked just fine. /usr/bin/upgrade-nonroot called apt full-upgrade and correctly removed virtualbox-guest-utils and virtualbox-guest-x11.

For bare metal, I imagine most people not too familiar with APT may be stuck on the old package version for quite long. Missing out dist-baremetal-gui-all seems not ideal to me. It may even affect an in-place major Kicksecure/Debian release upgrade, given that apt dist-upgrade won’t upgrade it either. Thoughts?

Idea: Can upgrade-nonroot handle this for me or at least print a hint on how to resolve it? Previously, a similar idea has been suggested for a different problem.

2

For future reference, this change seems to be introduced between

% apt list kicksecure-baremetal-gui-lxqt -a
kicksecure-baremetal-gui-lxqt/unknown 3:37.0-1 all [upgradable from: 3:36.7-1]
kicksecure-baremetal-gui-lxqt/now 3:36.7-1 all [installed,upgradable to: 3:37.0-1]

And later announced in releate notes section “VirtualBox”

kicksecure-meta-packages has also been mentioned in release notes but I haven’t looked at GitHub on what exactly has changed. (To be clear, I’m just trying to find out when and how this happened. Not trying to blame anyone.)

3

Apt sometimes just behaves weird. It’s difficult-to-impossible to predict when it will, and there seems to be no general solution to this. Some of the issues that have prevented us from enabling automatic updates are documented here:

As such, users are required to update manually, using a CLI interface that shows up problems like this. It is very unlikely the problem you’re looking at is universal, and for those who are affected, the existing update mechanisms ensure users notice oddities like this.

It might be possible to notice this situation in upgrade-nonroot and warn about it (perhaps directing users to a Wiki page to help them solve it).

1 Like
4

I have good reasons to believe it happens to everyone upgrading Kicksecure on bare metal recently. Yeah it’s not “universal” in the sense that every single APT user in this universe running all sorts of package upgrades will run into this, but it is a general problem that happens to other Kicksecure users too.

To reproduce this issue, first download a Kicksecure ISO before the 18.2.1.9 point release. For example, https://www.kicksecure.com/download/iso/18.1.6.4/Kicksecure-LXQt-18.1.6.4.Intel_AMD64.iso

Then in VirtualBox, create a new VM using the ISO. Detailed steps:

  1. On the Home tab, click on the Create a new virtual machine (VM) link
  2. Put whatever as the VM name
  3. In ISO Image, open dropdown, select Other and locate the ISO just downloaded
  4. OS settings don’t matter, just don’t do unattended installation
  5. Expand Specify virtual hardware and specify enough virtual memory (e.g. 2Gi) so that Kicksecure ISO boots into graphics session

Then start the VM and select sysmaint session. (This can also be done using USB sticks on bare metal but using VirtualBox for better reproducibility.)

Once the sysmaint panel shows up, there’s no need to install the system. The Live ISO is good enough to reproduce this issue. Simply click the “Install Updates” button. I know, tor can be unreliable from time to time. But after a few tries and/or restarting tor, it will download packages and you’ll see the below, among lots of other outputs.

Not upgrading:                  
  kicksecure-baremetal-gui-lxqt

If you see something about not enough disk space (a limitation of the Live ISO), it may be necessary to move the cache directory printed out to /dev/shm or somewhere else with more capacity. e.g.

sudo mv /var/cache/apt/archives /dev/shm
sudo ln -s /dev/shm/archives /var/cache/apt
# Then try upgrading again using the button or
sudo apt upgrade

Once you got here, you can try all the commands like I did in the original post and you’ll get the same results, except there will be a lot of noise cause by other packages.

This particular issue is predictable, in the sense that it happens when a new package version both adds and removes dependencies compared to a previous version. I agree it’s hard to predict other issues preventing apt full-upgrade from completing and there’s no general solution. There’s a whole StackOverflow question discussing various ways how “Not upgrading” can show up. I lost the link but I believe the OP captures the most common workarounds already. Explicitly typing the name of the meta package works is one of them.

5

I have good reasons to believe it isn’t, namely that multiple Whonix users got the upgrade automatically and it broke things a bit due to a staggered update. A package was held back on one upgrade but then allowed through on the next, and the staggered nature of the upgrade managed to dodge installation of newer Guest Additions, but still removed the old ones, thus causing issues. That bug has a fix for it in our Git repos already.

Thanks, that looks useful, I’ll likely try that soon.

I don’t know of any documentation that states that adding and removing dependencies causes apt to hold packages back. Furthermore, it looks like it doesn’t (at least not always) due to the Whonix bug mentioned above.

1 Like