I want to install Volumio on my RPI3 which already has other applications up and running. I read the instructions it seems like it will flash my SD card. Is there any other method to install it? My RPI3 OS is Raspbian.
No, the only way to have applications next to volumio is to install them after flashing volumio.
But, do not use ‘apt -get upgrade’!
This is not because of Raspbian (volumio has that too), but because we have a specific kernel version, initramfs, specific versions of certain packages etc.
Edit: You could refer to https://volumio.org/forum/kodi-volumio-install-volumio-nonvolumio-image-t4222.html, there may be similarities to what you are looking for.
Would it be possible to set these packages on hold so that one can safely run “apt-get upgrade” and get other non-critical packages upgraded?
Hi,
why would you want to do an upgrade anyway?
Is an update not enough, you can more or less install anything you want.
Remember, we also choose a specific kernel version and add sound modules fitting that version.
is there anything you absolutely need, forcing you to do an upgrade? Please let us know.
– Gé –
It’s not that I need to do an upgrade, at least not now, but it’s nice to be able to stay as up to date as possible. Also, being an administrator of quite a few linux systems, I’m used to upgrading from time to time, it would also be nice knowing that I can run “sudo apt-get dist-upgrade” (for a good reason or not) without fear of breaking the installation.
An update is quite a different thing, it just synchronizes the list of packages with the repositories, it doesn’t change anything installed in the system.
Hi,
I don´t think that we need the upgrade. Volumio is a project that is maintained by enthusiatic people in their freetime. It is great what they have done and manged to get a difficult system to run.
To keep the kernel up to date they have to check all configurations and hardware that is supported, don´t think about the users if after an update it is not running any more. For the volumio team there would be no chance to reproduce the error or continue in development.
Just to be clear: I don’t mean being able to upgrade the kernel (or drivers, or other critical packages). What I would like is to mark these critical packages with “hold”, so I can safely upgrade other packages without fear of breaking the system
Well, it is not going to happen.
It would be impossible to maintain and we would have nill benefit for Volumio.
Anyway, who would start determining which packages to put ‘on hold’, and what about Debian x86, Debian armv7 and armv8? We are not just delivering for PI!
– Gé –
Is there at least a list of all the packages “pre-installed” in the image? If I put those on hold I should be safe, right? (Otherwise, it means that installing something else breaks volumio, which is probably something to be fixed.)
Why? Surely that’s exactly the information you, the developers need to have: which packages need to be “locked” at which version (on which platform). Otherwise, how do you know whether it is safe to upgrade package X, to the latest version, for the next release of Volumio?
All that’s being proposed is to remove the quotes around the word “locked” and to use the facilities built-into apt-get to manage this.
Doing so will actually make the task of the maintainers easier, not harder, and will allow users some assurance that they won’t accidentally break their installation when they do an apt-get install of some package (which, despite assurances, definitely can happen with the current lack of locking).
Then, prof, you seem to have all the knowledge and will to help us make it happen.
You can have a look at our build system :
github.com/volumio/Build
From there you should be able to understand if and which packages needs to be locked.
Side note: Volumio is a distribution meant to Work out of the box for a particular task: audio listening. It is not therefore a multipurpose distro, like there are many. We’ve made our best to leave the ability to mess with it (aka RW layer on top of the Squashfs), but only to the degree that’s made possible by an architecture that needs to depend on lots of packages working together.
So, if making all of this work is complicated , it would be overly-complicated to make it work in a way that the user could just do anything.
If someone wants to tinker and install stuff, we surely encourage it, but we can’t give much assistance nor we can adapt too much the distribution to fit such scenarios, as its out of our scope and will slow development a lot.
Hope that clears our position.
If anybody knows a viable solution to solve the above, and is willing to help, that would be very appreciated.
I did look at your Build repository to try to figure out precisely the answer to this question. But I have to admit that I was a bit lost.
I’ll explain what confused me below, but before doing that, let me point you to (say) this tutorial for how to “hold” a package at a particular version, both in apt-get and dpkg.
In your build scripts, repeat those instructions for every package that needs to be held at a particular version.
What confuses me is that, in your build setup, you seem to have forked quite a number of packages and install them (using dpkg) from your own site (instead of, say, fetching them from the “standard” raspbian repository), whereas you have apt-get set up to use the raspbian repository. This could be because
- You have actually customized them in some way, and really need to install your customized version.
- You just want to hold the package at a particular version and used this “workaround” when you could have achieved the same effect using “hold”.
It’s hard to ferret out which is which.
That said, I kinda decided to do an experiment, upgrading all my installed packages (a few at a time, to try to catch what breaks) using apt-get. The end-result is that I currently have Volumio 2.0.41 running (on a Raspberry Pi3) with all the latest versions of all the installed packages from the Raspbian Jessy repository (and, for good measure, the repository at lesbonscomptes for upmpdcli and its associated packages) and nothing seems to be broken.
“Seems” is probably the operative word here, and things may be different for other hardware platforms. But still …
Addendum:
The apt-mark manpage.
I really don’t see the point of this topic. If you want to play around with the current installation, then you are very welcome to do so (I install other stuff occasionally too). However, expecting any kind of official support or maintenance is unreasonable. If you want to make a guide on how to do so without damaging the functionality of Volumio, then feel free to do so in the appropriate forum (with a warning caveat as to potential problems now and in the future). Happy fiddling 
I think this is a good chance to explain how Volumio inner mechanics works:
- We install particular packages via dpkg because we custom compile them, sometimes to improve their performances, sometimes because we need newer versions (not available in jessie ). Its not a tentative of marking packages.
- As you might know volumio uses a combination of SquashFS (read only image written in RAM at boot) and overlayFS. Which consists:
- The core volumio image is written on RAM at boot. It will not be written to. When you update from our OTA update, we just download the difference from the current squashfs to the updated squashfs, and update the squash.
- The overlay is used to write on top of the squash, to allow file system modifications (mainly user data and settings). So, for example in the squashfs you have a file /etc/hostname with “volumio” written on top, and you edit it with “something”, a file called /etc/hostname with “something” is written on the overlayfs, and it will be the only /etc/hostname saw by the system.
So, if you manually update your packages (which in any case would be at most a couple months old), you loose the ability to upgrade them in future updates (via OTA updater): if you update now mpd for example, to a newer version, you will keep this version forever. Because if we will update mpd in the squash, it will be always overridden by the copy you have on the overlayfs.
I hope this explanation will solve all doubts related to why we discourage upgrading packages (but as long as you know the consequences you’re free to do it).
Thanks for the explanation. I’m not actually sure how the apt-mark hold … mechanism works (if it does work) in this SquashFS/OverlayFS environment.
Newer versions are not a problem for apt-get, but it would be good to apt-mark hold the custom-tweaked packages.
We could maintain a simple manifest of the package versions expected on a given squashfs. This would allow the auto upgrade mechanism to alert the user that they need to reflash to upgrade due to local package changes.
Sent from my iPad using Tapatalk