Apt upgrade safe?

In Volumio 2, apt upgrade would brick the system. I gather the build system has changed in Volumio 3. Is it now safe to do an apt upgrade in Volumio 3?

No, Volumio still has it’s own dedicated setup, do NOT use apt-get upgrade!
Why would you want to do that anyway?

Technically you could - currently the binaries provided by Volumio have newer versions than what are available in upstream repos.

But you are on your own and will porbably run into issues.

As GĂ© asks, what is your motivation for this?
Buster is an actively maintained distro, so you will automatically get updated (and stable) packages via Volumio’s OTA updater.

My motivation?

Things like this.

In every other damned Linux distro that can be (and, in the case of every other Linux box in my possession already has been) fixed with a simple apt update; apt upgrade (or equivalent).

But Volumio? Nah! The fix is right there, available from apt:

$ apt list --upgradable
Listing... Done
libavcodec58/oldstable 7:4.1.8-0+deb10u1+rpt1 armhf [upgradable from: 7:4.1.8-0+deb10u1]
libavformat58/oldstable 7:4.1.8-0+deb10u1+rpt1 armhf [upgradable from: 7:4.1.8-0+deb10u1]
libavresample4/oldstable 7:4.1.8-0+deb10u1+rpt1 armhf [upgradable from: 7:4.1.8-0+deb10u1]
libavutil56/oldstable 7:4.1.8-0+deb10u1+rpt1 armhf [upgradable from: 7:4.1.8-0+deb10u1]
libcec4/oldstable 4.0.7+dfsg1-1+rpt2 armhf [upgradable from: 4.0.4+dfsg1-2+rpi1]
libpolkit-agent-1-0/oldstable 0.105-25+rpt1+deb10u1 armhf [upgradable from: 0.105-25+rpt1]
libpolkit-backend-1-0/oldstable 0.105-25+rpt1+deb10u1 armhf [upgradable from: 0.105-25+rpt1]
libpolkit-gobject-1-0/oldstable 0.105-25+rpt1+deb10u1 armhf [upgradable from: 0.105-25+rpt1]
libswresample3/oldstable 7:4.1.8-0+deb10u1+rpt1 armhf [upgradable from: 7:4.1.8-0+deb10u1]
linux-libc-dev/oldstable 1:1.20211201~buster-1 armhf [upgradable from: 1:1.20211118~buster-1]
policykit-1/oldstable 0.105-25+rpt1+deb10u1 armhf [upgradable from: 0.105-25+rpt1]

But we’re not supposed to apply it because ???

This is not the way to manage a distro.

Have a look at my other post for more thoughts on this particular vulnerability PwnKit - CVE-2021-4034

As mentioned previously, this isn’t recommended, but you are always welcome to try - I haven’t run into any issues on my system (but it’s a custom build)

                      /\_ \                        __
         __  __    ___\//\ \    __  __    ___ ___ /\_\    ___
        /\ \/\ \  / __`\\ \ \  /\ \/\ \ /' __` __`\/\ \  / __`\
        \ \ \_/ |/\ \L\ \\_\ \_\ \ \_\ \/\ \/\ \/\ \ \ \/\ \L\ \
         \ \___/ \ \____//\____\\ \____/\ \_\ \_\ \_\ \_\ \____/
          \/__/   \/___/ \/____/ \/___/  \/_/\/_/\/_/\/_/\/___/

             Free Audiophile Linux Music Player - Version 2.0

          © 2015-2020 Michelangelo Guarise - Volumio Team - Volumio.org

Volumio Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Welcome to Volumio for Raspberry Pi (5.10.50-v7l+ armv7l)
Last login: Sat Jan 22 07:30:27 2022 from
volumio@pi:~$ sudo apt update
[sudo] password for volumio:
Get:1 http://raspbian.raspberrypi.org/raspbian bullseye InRelease [15.0 kB]
Get:2 http://archive.raspberrypi.org/debian bullseye InRelease [23.5 kB]
Hit:3 https://deb.nodesource.com/node_14.x bullseye InRelease
Hit:4 https://www.lesbonscomptes.com/upmpdcli/downloads/raspbian bullseye InRelease
Get:5 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages [13.2 MB]
Get:6 http://archive.raspberrypi.org/debian bullseye/main armhf Packages [247 kB]
Fetched 13.5 MB in 5s (2549 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
12 packages can be upgraded. Run 'apt list --upgradable' to see them.
volumio@pi:~$ apt list --upgradable
Listing... Done
bsdutils/stable 1:2.36.1-8+deb11u1 armhf [upgradable from: 1:2.36.1-8]
libblkid1/stable 2.36.1-8+deb11u1 armhf [upgradable from: 2.36.1-8]
libmount1/stable 2.36.1-8+deb11u1 armhf [upgradable from: 2.36.1-8]
libpolkit-agent-1-0/stable 0.105-31+rpt1+deb11u1 armhf [upgradable from: 0.105-31+rpt1]
libpolkit-gobject-1-0/stable 0.105-31+rpt1+deb11u1 armhf [upgradable from: 0.105-31+rpt1]
libsmartcols1/stable 2.36.1-8+deb11u1 armhf [upgradable from: 2.36.1-8]
libuuid1/stable 2.36.1-8+deb11u1 armhf [upgradable from: 2.36.1-8]
mount/stable 2.36.1-8+deb11u1 armhf [upgradable from: 2.36.1-8]
policykit-1/stable 0.105-31+rpt1+deb11u1 armhf [upgradable from: 0.105-31+rpt1]
rfkill/stable 2.36.1-8+deb11u1 armhf [upgradable from: 2.36.1-8]
rpi-eeprom/stable 13.5-1 armhf [upgradable from: 13.4-1]
util-linux/stable 2.36.1-8+deb11u1 armhf [upgradable from: 2.36.1-8]
volumio@pi:~$ sudo apt upgrade
(Reading database ... 39184 files and directories currently installed.)
Preparing to unpack .../libsmartcols1_2.36.1-8+deb11u1_armhf.deb ...
Unpacking libsmartcols1:armhf (2.36.1-8+deb11u1) over (2.36.1-8) ...
Setting up libsmartcols1:armhf (2.36.1-8+deb11u1) ...
(Reading database ... 39184 files and directories currently installed.)
Preparing to unpack .../libuuid1_2.36.1-8+deb11u1_armhf.deb ...
Unpacking libuuid1:armhf (2.36.1-8+deb11u1) over (2.36.1-8) ...
Setting up libuuid1:armhf (2.36.1-8+deb11u1) ...
(Reading database ... 39184 files and directories currently installed.)
Preparing to unpack .../policykit-1_0.105-31+rpt1+deb11u1_armhf.deb ...
Unpacking policykit-1 (0.105-31+rpt1+deb11u1) over (0.105-31+rpt1) ...
Preparing to unpack .../libpolkit-agent-1-0_0.105-31+rpt1+deb11u1_armhf.deb ...
Unpacking libpolkit-agent-1-0:armhf (0.105-31+rpt1+deb11u1) over (0.105-31+rpt1) ...
Preparing to unpack .../libpolkit-gobject-1-0_0.105-31+rpt1+deb11u1_armhf.deb ...
Unpacking libpolkit-gobject-1-0:armhf (0.105-31+rpt1+deb11u1) over (0.105-31+rpt1) ...
Preparing to unpack .../rfkill_2.36.1-8+deb11u1_armhf.deb ...
Unpacking rfkill (2.36.1-8+deb11u1) over (2.36.1-8) ...
Preparing to unpack .../rpi-eeprom_13.5-1_armhf.deb ...
Unpacking rpi-eeprom (13.5-1) over (13.4-1) ...
Setting up rfkill (2.36.1-8+deb11u1) ...
Setting up mount (2.36.1-8+deb11u1) ...
Setting up rpi-eeprom (13.5-1) ...
Setting up libpolkit-gobject-1-0:armhf (0.105-31+rpt1+deb11u1) ...
Setting up libpolkit-agent-1-0:armhf (0.105-31+rpt1+deb11u1) ...
Setting up policykit-1 (0.105-31+rpt1+deb11u1) ...
Processing triggers for dbus (1.12.20-2) ...
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u2) ...
volumio@pi:~$ uptime
 08:43:12 up 100 days, 23:38,  1 user,  load average: 0.28, 0.11, 0.04

Anyway, there should be an OTA update (v3.207) from Volumio that contains the fixed package, but IMO it’s not a critical vulnerability…

Attitudes towards security on IoT devices differ. Some people seem to think

  • It’s behind my LAN’s firewall, so it’s safe.
  • It’s just an IoT device, so who cares if an attacker did manage to get root on it.

Clearly we disagree on that, but I see no point in debating the issue.

What I want is to be able to decide for myself whether this issue merits fixing and be to able to avail myself of the fix that upstream developers have already provided.

I don’t believe my point made it through…

If someone got shell access to your Volumio device via the internet, then with the current Volumio architecture, it’s pretty much game over. You don’t need any vuln to get root access. volumio user can do pretty much what they please.

Hence in my book, PwnKit isn’t a critical vulnerability in the Volumio lens.There are easier attack vectors that don’t require any vuln.

But, no one is stopping you? Did you try upgrading?

If you look closely at my snippet, you would see I’ve been happily running fully up-to-date packages, and my system has been rock stable.

I fully agree with your view though, which is why
I’ve spent significant efforts in the build system rewrite to try and reduce Volumio’s aversion to user package upgrades.

On the flip side I do hope you see how the devs don’t have the resources to help/chase bugs when user package upgrades causes things to break. Hence the recommendation to use the OTA update route.


However …

I did upgrade one of my two Volumio boxes. We’ll see how that goes …

For those who think they know better:

Volumio’s architecture is designed to meet those goals:

  • Allow 1:1 updates to ensure predictability of updates.
  • Allow the ability to install new packages via APT - GET
  • Allow to quickly reset to factory settings
  • Provide a “maintained experience” to all users, not only tech savvy

This is achieved via:

  • Rootfs stored on squashfs, which is what changes during updates
  • An overlayfs which allows writing on top of squash, to allow tinkering and installing new packages.

This means that:

  • Whatever is written on overlay, will persist after updates. So if you install a package manually via apt, it will supersede what is on squash. So if you install vim 1.1 manually, it will persist even if we release an update that includes vim 1.2
  • This means that apt-get install will not harm anything only if you install packages which are not part of the core distro. If you overwrite packages part of the distro, is impossible to guarantee consistent behaviour after updates.

Our goal is to provide a secure distribution out of the box, which does not require manual intervention if you update regularly.

We believe this architecture is the perfect balance for the purpose we want: predictable and repeatable updates (good luck if you think that with apt upgrade you can have the same) but flexibility to install other packages for plugins or tinkering.

In a nutshell, if you want to manually upgrade a package part of the core distro, sooner or later you will have problems. And if you report to us, it will just make us loose time for a situation we can’t predict.

The security update you mention, is already done on our side, and will be released next week after QA.
Our approach allows everyone (even non tech savvy) to receive it, not only people which can apt get.
If the price to pay for this, is suggesting people not to do apt-get upgrade, then it’s a worth price to pay.

This also means you are free to do it manually, but then don’t complain if things don’t work, for things you seem not to understand.

I also kindly ask mods and devs to stop suggesting manual intervention, for the reasons mentioned above.