STICKY: PINN - An enhanced version of NOOBS.

[procount]

Gentoo64 and gentoo64pt v1.2.1for the PiTop have now been upgraded for the RPi3B+ and are available for installation through PINN.
Also added to the catalogue of distros is OpenPlotter v0.10

[procount]

PINN has been updated to v2.5.4

V2.5.4

• Countdown - Fixed the Boot selection countdown timer display that had disappeared.

Also added the Raspex distro of Ubuntu 18.04 LTS with Lubuntu desktop for the Pi2, Pi3 and Pi3B+

[Patrick76]

How I can manually force a search for an update from v 2.49 in PINN if the popup doesn't apear?

[procount]

How I can manually force a search for an update from v 2.49 in PINN if the popup doesn't apear?

Please see the last paragraph of this section of the documentation: https://github.com/procount/pinn/blob/m ... elf-update

Self-updating was introduced in v1.9.5.
It broke in v2.4.3 onwards until it was fixed in v2.4.4c.
The manual self-update, as described in the above documentation, is only available from v2.4.4c onwards.

I don't recall there being a v2.49 version of PINN, so I'm not sure which version you have, but even if the self-update feature is not included in your version, you can update it manually. Download the latest pinn-lite.zip and unzip all files EXCEPT RECOVERY.CMDLINE to the PINN recovery partition. (If you accidentally overwrite recovery.cmdline, your SD card will be reformatted and you will lose all your installed OSes.) See also viewtopic.php?f=63&t=142574&start=200#p1239359

[mattrix]

Hello!
Sorry for the stupid question , but is it possible to install Volumio on the Raspberry using PINN?

Volumio just added to PINN
https://github.com/matthuisman/pinn-os/ ... f85ef89c6a

Everything works great (except updating.)
Their update replaces the initramfs which has to be modified initally to work with PINN.
So, updating breaks it.

However, a future update to PINN should allow re-running the initial partition_setup.sh script to re-modify the files needed.
So, you would then update Volumio, boot PINN, re-run the partition_setup, and then all OK.
But for now - just don't update.

[zenji101]

Hi,
Any plans to update Retropie to test stretch versions for RPI 3B+ owners?

Thanks for all your hard work

Z

[procount]

Hopefully soon....

[Patrick76]

Error contacting update server!!!!

[procount]

PINN has been updated to v2.5.5

V2.5.5

• self-update - Fixed a minor problem with the self-update.

Ignoring an update would keep prompting to download the update even after it had been downloaded.

Retropie3 (testing version 4.3.15 from their forum) is now available for the 3B+

[Patrick76]

Why it is necessary to switch manually PINN's firmware before (or after ) changing SD-card between Pi 0123 and Pi 3+ hardware?
Is this process also necessary with the actual NOOBS-version?

[procount]

Why it is necessary to switch manually PINN's firmware before (or after ) changing SD-card between Pi 0123 and Pi 3+ hardware?
Is this process also necessary with the actual NOOBS-version?

Addressing your 2nd question first, NOOBS does not switch firmware, so this is purely PINN related.

OK, so back to your first question... There are 2 main issues here which make it a bit complicated.

Firstly, since the RPi3B+ has slightly different hardware to the other models, it requires different (newer) firmware that knows how to interface with it. This firmware will run quite happily on ALL RPi models, so PINN is distributed with the NEW firmware to work on all models.

Secondly, in order to multi-boot, The RPi will first run bootcode.bin from the PINN recovery partition, which will then run start.elf from the desired OS partitition, which will then load the kernel and rootfs. But bootcode.bin, start.elf and the kernel need to be compatible with each other in order for this to work. During the evolution of the RPi, there seems to have been a couple of occasions where some inevitable differences have arisen. (This is just me paraphrasing for a simple explanation).

PINN supports about 50 different OS versions (if you include all the variants for the different models). A lot of these were produced before the RPi3B+ was known about, and some a lot longer ago than that. So some of them have very old firmware that is not compatible with the latest firmware and they will not boot when launched from PINN's latest bootcode.bin.

So my solution is to downgrade PINN's firmware when it detects it is being run on a RPi model other than the 3B+ for the first time. This means it can continue to install and boot all the old OSes on the older models. On the RPi3B+, it will keep the new firmware to be able to run on the 3B+ and load the latest OSes that are suitable for it.

If you try to run older firmware on the 3B+. you will just get the rainbow screen with a lightning bolt and 4 quick followed by 4 long flashes of the red power led. (See many forum posts). Now it should be clear that if PINN is used on an older model and had its firmware downgraded, when it is put in a 3B+, it will not work as its firmware is no longer suitable for the 3B+. Therefore it is necessary to put the PINN SD card back in an older model and upgrade the firmware before putting it in a 3B+.

Automatic downgrading only works once. So if you constantly switch from a 3B+ to another RPi model, you must manually change the firmware to match.

It is possible to run the new firmware on the older RPi models by manually upgrading it, but most of the older OSes will not be compatible with the new bootcode.bin. So, PINN will attempt to upgrade the firmware of these OSes to allow them to work. This may or may not be successful in all cases, so the `nofirmware` cmdline option has been added to disable this upgrading.

Sorry if this sounds complicated. When all the OSes get upgraded to use the latest firmware, this firmware switching will no longer be necessary.

[n67]

An interesting read, that.

I'm curious why all this machination wasn't necessary in the past.

We've been through several iterations of:

1) New Model of Pi comes out.
2) People complain that their old cards don't work on the new boards.
3) People are told that they need to upgrade their firmware - by booting the card on the older board and doing update/upgrade.
4) Card will now boot on the new board (as well as, of course, on the older board).

Why does that sequence not work with the 3B+ ?

[procount]

Well, firstly, it was occasionally necessary, but in the case of PINN, I hid it from you by upgrading some of the OS firmware before publishing them. But at that time it was a similar but different `autoboot` incompatibility.

Essentially that sequence still works, and is what PINN still tries to do automatically when necessary.
But the difference with the 3B+ is that it now has a new USB controller, ethernet controller and wifi. So upgrading the firmware may get the red led to stop flashing and for it to boot, but you still need to add the additional drivers for the new hardware for the OS to work properly.

There is a thread on here about getting Ubuntu 18.04 working on the 3B+ (viewtopic.php?f=63&t=208538) which details everything you need to do to get 1 OS converted. Now multiply that effort by 50, and that's why I've not done it. Converting an OS to NOOBS format is one thing, but I'd rather leave updating an OS to their respective maintainers.

And besides, what goes on in the firmware is only known by the RPF engineers, so only they really know why these incompatibilities exist, but sometimes these changes are necessary in order to progress.

And as I stated, the multiboot nature of PINN adds an extra complication that does not exist if you burn a single OS to your sd card.

[mironto]

Hello,

I have a question regarding the boot time of PINN and RaspPi2B. It takes 15s to display PINN OS selection menu after power-up. Till the menu is displayed, there is no other output to the monitor (using NTSC CVBS via 3.5 jack).

I've put the latest 2.5.5 PINN onto the 8GB SD card and after boot installed LibreELEC and Raspbian Lite onto the card. Everything works great except the long delay on initial boot. Once I reach the PINN menu and select LibreELEC, it takes just another 17s to boot completely into KODI (17.6) GUI (Raspbian takes longer, but that's ok), so it's definitely not due to a slow SD card. Are there some switches/options to make this initial PINN boot faster? It feels really weird that to display a simple selection menu takes almost as long as booting full LibreELEC. Thank you.

[procount]

I normally use HDMI or DSI output rather than the composite output.
Normally, on the HDMI, you should get the rainbow square screen first, then the raspberry logo prompting to press the shift key to enter the recovery menu, and finally the boot menu showing the list of installed OSes to choose from.

You can press keys 1,2,3 or 4 to change display modes and it should remember that choice once you've selected the best one for your setup.

Alternatively, you could add appropriate commands to a new config.txt file to ensure composite mode is selected as soon as it is booted.

There are plenty of options to reduce the boot time and even to boot quickly into a specific OS if you use it most of the time. Please see the detailed instructions in: https://github.com/procount/pinn/blob/m ... ME_PINN.md

[mironto]

There are plenty of options to reduce the boot time and even to boot quickly into a specific OS if you use it most of the time. Please see the detailed instructions in: https://github.com/procount/pinn/blob/m ... ME_PINN.md

I read through the entire post but I found no option to reduce the boot time of PINN itself. As I wrote, it takes 15s to show the PINN OS selection menu. I get no other output on the monitor before this menu (no rainbow square or raspberry logo).

I have selected NTSC output by pressing 4 on the first install, so this option is remembered and all OSes display via NTSC as expected. I don't need to change this setting as my NTSC monitor is the only output source.

This is my recovery.cmdline, nothing fancy there, I just disabled check for updates and shortened timeout for OS selection.

Code: Select all

quiet ramdisk_size=32768 root=/dev/ram0 init=/init vt.cur_default=1 elevator=deadline repo_list=http://raw.githubusercontent.com/procount/pinn-os/master/os/repo_list.json no_update bootmenutimeout=2

Can you please measure your boot time to PINN OS selection menu? If 15s is standard, I can live with it, I just wanted to know, if this can be shortened or I have some problem with my RPi2 and such a long boot time is not normal. Thanks.

[procount]

I can't test for a while....
15s sounds about right though. Doesn't seem as long when you can see something on the screen.
Some of the time is loading pinn (which is a small linux system itself)
Some of the time is delays allowing for you to interrupt the process.
Some of the time is delays waiting for the network to start.

The more choice you allow, the longer the startup.
If you mainly use 1 OS, make it a sticky default.
If you ALWAYS use 1 OS set autoboot.txt and PINN will disappear taking no time, but you will have to re-enable it manually to switch to another OS.

[mironto]

Would it be possible to disable network adapter to shorten the boot process? If I add keyboardtriggerdisable, I can shave off about 1s from the boot time.

I need to keep the OS menu, because I use RPi in car as entertainment system and switch from LibreELEC to Raspbian from time to time. I already have LibreELEC as sticky default.

I found one problem when running PINN for the first time on a fresh SD card. If there is a new version of PINN after the first boot (popup window shows), I am unable to switch output through 1-4 keys. I first have to cancel the popup through ESC. After that typing 4 changes output to NTSC and I can see the PINN menu (I had to connect a monitor through HDMI to troubleshoot and find out what's preventing me switching the output to analogue).

[mattrix]

@mironto

You could use the autoboot.txt method and use my KODI add-on to boot from KODI -> Raspbian.
https://www.matthuisman.nz/2017/02/kodi ... dd-on.html

If you also do "Install boot-back", it'll add a shortcut into Raspbian to boot-back to KODI.
Or a normal reboot would also do that (due to the autoboot.txt)

Note:
autoboot.txt did cause some issues with OS's not booting at all.
But worth a try! Worst case, you can just delete the file.

[gnad]

Hello procount, thanks for the amazing work. I have a few questions here, really appreciate if you can give an input.

My goal is to figure a way to add an OS to an existing multiboot PINN setup.

Supposed on the PINN sdcard I have Raspbian and Openelec (they would occupy mmcblk0p6, 7, 8 and 9). Then I use Gparted, resizing other logical partitions to create mmcblk0p10 and mmcblk0p11.

On another sdcard, I flash Retropie normally, then back it up with bsdtar to boot.tar and root.tar. Then I copy boot.tar to mmcblk0p10 and root.tar to mmcblk0p11, and edit installed_os.json in PINN settings (mmcblk0p5) to add the new OS info.

Is this all it need for this to work?

Similarly, if I want to remove an OS, I would need to format its 2 partitions with Gparted, remove its entry from installed_os.json, and edit entries of other OSes if the partition number shift. And that would be it?

[procount]

In principal you have the right idea, but there is a bit more to do.
By default, an OS expects its Boot partition to be at partition /dev/mmcblk0p1 and its root partition to be at /dev/mmcblk0p2 (or more recent OSes may use a PARTUUID expression)
When you move an OS to different partitions, references to these partitions need to be updated accordingly. This is the job of the partition_setup.sh script which is specific to each OS. Typically you need to modify cmdline.txt in the boot partition, and /etc/fstab in the root partition, but some OSes are a lot more difficult.

[gnad]

Hey, thank you.

So to summarize: To add an OS, I need to create a new FAT and a new ext4 partitions with Gparted, move the files over, edit /etc/fstab in root and cmdline.txt in boot to update the partition number. After that, create an entry in installed_os.json.

To remove an OS, I need to delete its 2 partitions, remove its entry from installed_os.json. If the partition numbering shift, I also need to edit /etc/fstab, cmdline.txt and installed_os.json of other OSes.

Tell me if I have got it right.

[procount]

That sounds about right.
I think removing an OS might have a few issues but I wish you luck!

[gnad]

What are the potential issues with removing an OS? The only issue I could think of is that the sdcard could be corrupted while we mess with resizing and creating partitions. Other than that, in term of setting files that need to be adjusted, I think we got it all.

[procount]

I only experimented a bit, but IIRC, I think the kernel didn't manage the partition numbers as I expected.
But it was a long time ago, and if you're doing it manually, I'm sure you can fix things up.