** Volumio2 added to PINN (NOOBS) **

** Volumio2 has just been added to PINN. **

PINN is a fork of NOOBS with more features and operating systems.
I help the developer (procount) by building and maintaining various OS’s.

It is running the latest version 2.389 so supports all Raspberry Pi models.
Everything works - including OTA updates.

About PINN:

How-to install PINN:

Available PINN Systems:

Set PINN System Sizes:

The Volumio PINN files:


So I guess this answers my previous question:

Volumio works fine on 3B+, even if some of the new hardware features aren’t yet fully supported.

@mattrix interesting, thanks.
As for supporting OTA updates, Data reset & al, you may want to check my berryboot integration work (and look at actual scripts): it might help getting the pieces together to support native updates.

Yes, an interesting concept Mattrix. Thanks for posting and keep us updated how things pan out.

Yes, I had spotted that.

PINN / NOOBS is a bit different to berryboot.
Berryboot uses it’s own kernel whereas PINN uses the OS’s original kernel / boot partition.
It’s pretty much booting the OS as it would be normally - except telling the Pi to boot from partitionX instead of partition1.
So, there is no way to always run a script on boot of the system.

When the OS is installed, it will set the partition sizes, untar the tarballs and run a script called partition_setup.sh
This can modify the OS’s files to point to the correct partition numbers.
This script currently can only run once (on initial install of the system).

Here is the current script I am using:
github.com/matthuisman/pinn-os/ … n_setup.sh

It updates the cmdline and init script inside the volumio.initrd with the correct partitions (which PINN parses to the script).
Line #38 is pretty special. It uses sed to append a sed line into the init to fix the fstab on each boot. LOL?
I try to keep changes to a minimum in the hope that they continue to work with later versions of the software.
I could obviously edit the raw tarballs and hack in some changes but I don’t like doing this.
I want the tarballs to be 100% original.

[i]As far as I can tell, the update script is compiled (so I can’t modify it) ?
I assume it downloads the update, applies it immediately (thus over-writing my modified inittab) and rebooting.
Therefore, I can’t have any changes in the inittab that fixes itself after an update.

I need something external to it that it creates on the first boot.
This something needs to be able to detect an update (before the reboot), and then fix the inittab.
Maybe a systemd script that waits for the reboot / poweroff, then checks if an update has been applied.
If so, then fix up the inittab.

Or maybe there is some post-update hook you know of (before the reboot)?
It appears the only files that are “safe” in an update are the data volume.
So, I’d need something in this that fixes the inittab. However, this data can also be wiped…
But that wiping is done in the inittab so I could make it wipe and then restore my post-update script.

Whatever it is, it needs to happen before the reboot.
As when it reboots, it will be booting straight into the new inittab and start trying to mount /dev/mmcbl0p1 -> 3
Which are all PINN system partitions.

I am in close contact with the developer of PINN and we came up with an idea that there could be a function in the PINN software,
that simply re-runs the partition_setup.sh script again. This could therefore fix up the init file after an update.

A lot of “NOOBS” compatible OS’s have changed their systems to not have hard-coded partition number or devices.
They simply get parsed the boot device in the cmdline and work out the relative partitions from this.
eg. boot=/dev/mmcblk0p8 so root is +1 /dev/mmcblk0p9 and data is +2 /dev/mmcblk0p10[/i]

I must of missed the kernel update step the first time I did an update!
I now see it reboots and then unpacks the new kernel (still using the old init script)
I can now run my partition_setup.sh after the unpack.
I’ll upload a new version soon!

I guess the correct “fix” would be for volumio to update their init script to not have hard-coded partitions and rely on parameters provided by the cmdline.txt.

I have posted over on the github pull request about updating the init script
I have provided an example init script that I should would work quite nicely!

:wink: awaiting a mid-term official fix allowing relocatable partitions, I’m glad you found some hooks (your first-boot script could also inject some permanent additional service, etc…).
One issue is to plan such hack robust enough, so that users are not left in the cold once relocatable partitions arrive…

PS: well aware about concept differences between NOOBS/PINN and Berryboot. What I do like in the latter is dynamic OS installation/removal.
Hope this will come to PINN at some point.

OTA updates now working.

It was getting really tricky to do modifications within a script.
Especially as it’s one script modding another script.

So, in the end I went for putting a custom volumio.initrd inside the imgpart tarball (so it will live in /imgpart/volumio.initrd).
After an update and a kernel extract, the custom init script will copy the /imgpart/volumio.initrd to /boot/volumio.initrd

This new script is the same as I posted in the github issue (with just 1x new line added to copy the /imgpart/volumio.initrd).
So, if that script (or similar) makes it into the main program, this copy won’t be needed either.

The only issue I see is if an update relies on something different in the init file.


I installed Volumio through PIMM, but after the update it can no longer boot :frowning:
Current PIMM image is version 2.457 while OTA tried to update it to 2.522. I only changed IP address to fixed one.

Shoudl I have done something before running OTA?

List of errors after reboot:

A very useful system.

But sadly it wouldn’t install RISC OS.

anyone know how this: https://github.com/matthuisman/pinn-os/tree/master/Volumio works for updates?

I dig out this topic.
It seems impossible to install Volumio/PINN when booting from USBkey/SSD?
Volumio does not appears in the OSes list.

I tried to add Volumio in /os, no way, PINN doesn’t list Volumio.
Any idea?