@macmpi
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]
UPDATE:
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)
YAH!!
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
https://github.com/volumio/Build/pull/256#issuecomment-379428387
I have provided an example init script that I should would work quite nicely!