STICKY: PINN - An enhanced version of NOOBS.

[hectorkvs]

I recently bought new Argon One M2 case for Rpi4 with Kingston 240Gb M2 ssd sata drive..installed Pinn OS properly with RPiOS and Twister OS on it..the problem that i'm encountering is that sometimes when i boot my Pi from cold start, it's stuck on loading boot menu and it says can't find Pinn OS files..what is odd is that after few tries ( forced shutdowns and unplugging the power cable) Pinn boot menu eventually starts..and after that i can boot to both of my installed OS..i suspected that my Kingston M2 ssd may be faulty, tried with another Biostar M2 ssd 120Gb, but the problem persist..anyone with similar problem?
I forgot to mention, that when i manage to boot to any of my 2 OS , after that everything work fine, i can reboot and shutdown both properly every time until next powering on few hours later..very odd...

How old is the drive?

Has it seen a lot of use? If so, the drive may need to be trimmed.

SSD's work very differently than a regular mechanical hard drive. Hard drives can read or write to any area on the disk, whenever it wants.

SSD's on the other hand are arranged into three tiers of storage:

• Read blocks are tiny areas on the SSD - the equivalent of "sectors" or "clusters" on a mechanical hard drive. A SSD can read any read block anywhere in the SSD, any time it wants.
• Write blocks are large groups of read blocks - hundreds or even thousands of read blocks per write block.
• Write blocks can only be written to ONCE, even if you are only writing a tiny amount of data. If you need to add data to a pre-existing write block, it first has to read everything in the existing write block, add the new data to it, then find a NEW write block that's empty, write all the data to it, and then mark the pre-existing write block as "available to be erased".
• Erase blocks are huge groups of write blocks, (which if you remember are huge groups of read blocks).
• The only way to erase an area on an SSD is to erase an ENTIRE ERASE BLOCK. If there's active data in that erase block, it has to read all the active data, move it to somewhere else, and THEN erase the entire erase block making everything inside it ready to be used.

If the drive has seen a lot of use, the SSD cannot find available erase blocks to move data into, so it has to "guess" what data can be cleared to make room for new data. Unless the operating system tells the SSD what is important, the SSD doesn't know what to erase and what to leave alone.

The cure is to "trim" the SSD.

"TRIM" for SSD's is like de-fragmenting a mechanical hard drive. A SSD has no way of knowing what parts are still important and what parts are free to be used. Without knowing this, the SSD cannot perform the necessary wear-leveling to ensure a long life.

The "TRIM" command is how the O/S tells the SSD what is, and is not being used. With this information the SSD can reclaim all the empty erase blocks, freeing up a lot of space and allowing the SSD to work better. Depending on how long it's been since the drive has been trimmed, you can see orders of magnitude increase in speed and responsiveness.

There is an excellent article about enabling TRIM on the Raspberry Pi here:
https://www.jeffgeerling.com/blog/2020/ ... spberry-pi

One thing to note is that this is specific to the individual SSD - if you change SSD's, you have to re-enable it for the new one.

Hope that helps.

Thanks for your answer..both M2 SSDs are new...one week old, 120Gb Biostar and 240Gb Kingston..i'll try to check out if Trim is enabled, but i doubt it will make a difference..btw, bootloader is the latest..once again thx for help

[HappyTux]

Thanks for your answer..both M2 SSDs are new...one week old, 120Gb Biostar and 240Gb Kingston..i'll try to check out if Trim is enabled, but i doubt it will make a difference..btw, bootloader is the latest..once again thx for help

You have to do it yourself on Pi, on my desktop machines running Ubuntu & Kubuntu when I checked there it was already enabled.

[jharris1993]

Age doesn't really matter. Unless you have done something like a full security erase, a trim is always helpful.

I took two 500 gig drives brand new out of the box and reformatted them as ext4. Then I ran a trim on them. After about two minutes it had trimmed the entire drive and returned almost 500gigs to the free pool.

[MarkMcCoskey]

I recently bought new Argon One M2 case for Rpi4 with Kingston 240Gb M2 ssd sata drive..installed Pinn OS properly ...

I encountered a similar problem. I'm new to the Pi 400 and PinnOS. Formatted FAT32 and copied Pinn to a 1TB Kingston SSD and it would not boot. Did the same on a 120GB drive and works perfectly. Was wondering if there's a size limitation with PinnOS?

[procount]

If you have a large drive, there is no point formatting it all to FAT32. For these drives I provide an Etcher type image that you can directly flash to your drive using Balena Etcher or RPi Imaging Utility etc.
Here is a link describing it ->viewtopic.php?p=1638508#p1638508
I have also updated the first post in this thread (near the bottom) with alternative ways to install PINN

[jharris1993]

If you have a large drive, there is no point formatting it all to FAT32. For these drives I provide an Etcher type image that you can directly flash to your drive using Balena Etcher or RPi Imaging Utility etc.
Here is a link describing it ->viewtopic.php?p=1638508#p1638508
I have also updated the first post in this thread (near the bottom) with alternative ways to install PINN

Another solution is to use something like Gparted and format the first 100 Meg's or so as FAT-32 and leave the rest unallocated.

You copy all the PINN files to this tiny FAT-32 partition, restart, and PINN will boot quite well.

Once PINN boots and sets itself up, it will reformat the drive and configure things to its liking.

I did that on two 500 gig Seagate SSD's and it worked wonderfully.

[kosmicro]

Hi! I tried looking among the replies but didn't found it.

The HDMI port of my raspberry 3b+ isn't working,
¿how can I use RCA output first time booting PINN?

[procount]

Try pressing key '3' when it has booted. (https://github.com/procount/pinn/blob/m ... tomisation)

Also see https://github.com/procount/pinn/blob/m ... tput-modes
and https://github.com/procount/pinn/blob/m ... ne-options

[TheKenz]

Also, it seems like the developer of LineageOS updated his files too on 1/22/21. lineage-17.1-20210122 for both his ATV and regular android. I can't remember what version I installed

Hi all, I also just used PINN to install the Konsta LineageOS build as part of a multi-boot setup on my Pi4. It worked seemlessly, thank you procount for the continued development!

The version of LineageOS you get via PINN is the October '20 version. Is it possible to update the repo for the newer build? I'm happy to help if I can get my head around how.

[procount]

PINN has been updated to v3.5.5

V3.5.5

• Joysticks - New joystick drivers including triggers and deadzones. Support for 2 joysticks.
• Firmware - Removed firmware upgrades for very old OSes.
• Install - Install icon changed to warn against deletion {#380}
• CM4 - Added dwc2 USB driver for CM4
• Backup - Better backups by deleting socket files (#442) and setting attributes (#447).
• ssh - Uses permanent storage
• progress - prevent progressdialog from closing
• Shift - larger font for recovery hint message with additional options.

This version includes new joystick and gamepad support including triggers and deadbands for XBox controllers. Full details are included in joy_keys.md

Support for upgrading old OS firmwares has now been removed. This was only a transitional solution, but most OSes have now been upgraded to the latest RPi models. This was also causing problems with some more recent OSes.

After installing one or more OSes, the install icon now is now changed to a scarey skull to indicate that installing more OSes will overwrite any installed OSes. An additional dialog box is displayed to reinforce this message.

The dwc2 USB driver is now included to support the CM4. To enable USB on the IO Board for the CM4 the following has to be added to config.txt:
"dtoverlay=dwc2,dr_mode=host"

Some problems backing up and restoring OSes have now been solved by deleting useless socket files that tar cannot handle, and setting the correct permissions on media files on restoration.

The hint to press shift to enter recovery mode has been made more prominent and readable and now includes the additional methods of entering recovery mode.

A small change to SSH support means PINN can remember its host key which avoids the need to keep accepting the key on each reboot.

[jharris1993]

Issue:

Latest version of PINN does not recognize or display installed non-standard O/S's within the PINN application itself.

As you know, I have several custom versions of Raspbian installed and we went through hell and back to get them to be fully functional.

As of the latest update, within the PINN menu's, the non-standard O/S's I created no longer show up, and changed groups are not displayed.

Viz: Raspbian for Robots and GoPiGo O/S exist and are installed, but within the list of operating systems to install, etc, they do not appear.
Viz.: These two operating systems were given the group "Robotics" which worked with my previous version of PINN, but are not displayed in the current one.
Viz.: Raspbian 64-bit was categorized under "Beta". The "beta" group is now not displayed, though the O/S is, and is marked "installed"

Note that all installed O/S's are visible and bootable from the boot menu. It is only within PINN itself that they are not visible or categorized correctly.

Is it possible - from within PINN - to downgrade?

[procount]

I don't remember doing any changes which would affect that behaviour. There's no facility to downgrade within PINN, but it is easy enough manually provided you don't change your recovery.cmdline. I can write instructions later.

[jharris1993]

Update:

At least part of the behavior I am seeing may depend on the presence or absence of the backup USB media.

For example:
Categorization/re-categorization of the new operating systems appears to depend on the presence of the USB media.

Some of these behaviors may not be related to the new release - I am experimenting.

Two questions for troubleshooting:

1. There is a particular part of a particular file that triggers the reformat-and-rebuild process. You have documented this before, but I cannot find it and don't remember what it is.
I want to be able to copy files to PINN's "root" directory without accidentally triggering a total nuke-and-reinstall.
2. What happens when you select "ignore" for an update? How do you "un-ignore" an update?

I have an existing 3.5.4 installation on one media device and another one that has updated to 3.5.5, and I want to compare them to help characterize this issue.

[jharris1993]

Another issue:

I want to express my strongest and most fervent objection to the use of a skull icon - particularly for the "install" icon. IMHO it is in extremely poor taste and reflects poorly upon the excellent program you have produced.. The previous icon was better.

An even better choice might be what is used by Ubuntu and it's clones: an image of an optical disk with a downward arrow.

[jharris1993]

Update:

The appearance of the proper categories and installed programs appears to depend on the presence of the USB drive in both the 3.5.4 and 3.5.5 versions.

I am attaching a 7z file that contains pictures of both the 3.5.4 and 3.5.5 versions.

1. There are two sections:
(a) 3.5.4 - with the light background.
(b) 3.5.5 - with the "standard" background.

2. Each section has two parts:
(a) Without the thumb drive with backups and original images installed.
(b) With the thumb drive installed.

Turns out it's too big.

Here's a link to a folder on MediaFire that contains both the individual pictures and a 7z file of all of them.

http://www.mediafire.com/folder/uxl0wr0ad39cl/PINN

[gn77b]

Hi, first post here

I'm successfully using PINN to boot to 4 different OSes. I'm now trying to replace one of the OSes with another one which wasn't part of the initial install, namely an older LibreELEC nightly build with a newer one, erasing both boot and root partitions, I've no problem with it. I thought I could do this by replacing the corresponding LibreELEC install files in the /os dir of the RECOVERY partition of the SD card and using reinstall in PINN interface. But PINN tells me "No OSes selected or available", which is already suggested by the icon to the right of the LibreELEC item in the list (as I understand disc icon means the files are available on disc, ethernet connector icon means OS will be downloaded but the USB icon in this case, what does it mean?).

I looked as os_config.json for the partition I'm trying to reinstall to and it says: "imagefolder" : "/mnt/os/LibreELECnightly" (mnt is the mount point for the RECOVERY partition as I understand it). There is a valid PINN install in /os/LibreELECnightly in the RECOVERY partition. So currently I'm at a loss, what do I need to do make PINN "reinstall" LibreELEC (quotes mean that it'l install a newer build)? To avoid any confusion, I repeat: all the installed OSes, including the one I'm trying to overwrite boot and work just fine.

[procount]

It is only within PINN itself that they are not visible or categorized correctly.

This is by design. If you are in the Main Menu or Archive Menu, PINN displays OSes that are available to install or download. If the installable media is not available (either PINN is not connected to the internet or the source USB drive is not plugged in) then the OS will not show up, even if it is already installed. This is to avoid the situation where you select an OS to install, but the installation fails because the source is not available.
The list of installed OSes is available on the Maintenance Menu. This list is not categorized as typically there are not enough OSes installed to warrant it.

1. There is a particular part of a particular file that triggers the reformat-and-rebuild process. You have documented this before, but I cannot find it and don't remember what it is.
I want to be able to copy files to PINN's "root" directory without accidentally triggering a total nuke-and-reinstall.

I alluded to this file in my previous post: It is the recovery.cmdline. When you install a a new version of PINN, recovery.cmdline contains the "runinstaller" option which reformats the whole drive and nukes any installed OSes. Therefore if manually upgrading/downgrading PINN, always make sure you do not install the new recovery.cmdline. Self-update ignores this file.

2. What happens when you select "ignore" for an update? How do you "un-ignore" an update?

It remembers this version and will not show the update dialog until a newer version is released. You can perform a manual check by going to the Maintenance Menu, select PINN and opt to replace it.
See https://github.com/procount/pinn/blob/m ... elf-update

I want to express my strongest and most fervent objection to the use of a skull icon

Well, It was a first step towards resolving #380. Someone who was equally passionate about PINN not deleting his OSes. Happy to choose another "scary" copyright free icon that shows when OSes have been installed.

[gn77b]

Looks like I (kinda) answered my own question. I downloaded the source code and this seems to be because PINN looks at some fields in the os.json file and allows the update based on those ("release_date" being the main offender if I'm not mistaken). Am I correct? Anyway, I only updated System.tar.xz and Storage.tar.xz and now PINN allows me to ""reinstall" the OS. Everything is fine, it boots and it's completely functional. But it's a weird feature in case I'm not missing something, I mean IMO PINN should allow an update. I understand that it can lead to problems i.e. the updated OS doesn't fit in the allocated partitions etc but if someone gets this far it's assumed they know what they're doing. What do you think?

[procount]

@gnb77 - As you have downloaded the source-code, have a read of README_PINN.md. It should give you a better understanding of how PINN works, which is essentially just an enhanced version of how NOOBS works too.

PINN first searches for a list of OSes that can be installed. These can be located:

• In the /os folder of the SD card itself. This is the case with the FULL version of PINN, but does waste space on your SD card. OSes found here have an SD card as an icon. (I assume you have started with the FULL version of PINN to already have LibreELec in the /os folder?)
• On the internet. PINN searches 4 main repositories (including the NOOBS repository). OSes found here are shown with an Ethernet icon.
• In the /os folder of a USB drive. OSes found here have a USB icon.

When PINN finds 2 or more OSes with the same name, it looks at their release_date to decide which is the newest and will ONLY present that version. The icons will therefore show you the location of the newest version that it will install.
If any of those locations get updated, and you have already used PINN to install an older version, PINN will highlight that OS as being a newer version for you.
Regardless, you can always install, download, reinstall or replace any of the OSes that it has found, providing it is the latest one.

You said you only replaced the system.tar.xz and storage.tar.xz files. You should have replaced ALL the files. The other files tell PINN important information about the OS, like it's release_date so that it can pick the latest one, but also image size information.
Or, you could put all the files from your new Nightly build into a /os/LIbreElec folder on a USB drive and install it through PINN from there.

Once your new OS version is being listed as the latest, you can go to the maintenance menu and select the OS that you want to replace. If the new OS has the same name, then you can just use the Reinstall option which will reinstall the latest version.
If you want to replace your OS with an OS with a different name, then you must choose the Replace option. In this case, you must first select the new OS that you want to install, before selecting the old OS that you want to be replaced (otherwise it will say none are selected). Then match the 2 up and hit the Replace button.

[jharris1993]

Well, It was a first step towards resolving #380. Someone who was equally passionate about PINN not deleting his OSes.

I entirely agree with the poster of issue #380 - the current implementation of "install" is both counter-intuitive and destructive.

IMHO, until such time as a better implementation of "install" is done, I believe the suggestion proposed in the title is the best and simplest way.

Happy to choose another "scary" copyright free icon that shows when OSes have been installed.

Instead of simply adding a "scary icon" - which doesn't communicate what you want - simply disable the "Install" button after PINN has installed something for the first time.

P.S.
If you need any help with the design of an improved UI, I would be glad to help.

2. What happens when you select "ignore" for an update? How do you "un-ignore" an update?

It remembers this version and will not show the update dialog until a newer version is released. You can perform a manual check by going to the Maintenance Menu, select PINN and opt to replace it.
See https://github.com/procount/pinn/blob/m ... elf-update

However, what actually does PINN do internally? Does it set a command-line option?

In my case I wanted to temporarily disable the auto-update, and then re-enable it again. If I hit "ignore" to disable the auto-update feature, how do I reverse that action?

Thanks!

[procount]

In my case I wanted to temporarily disable the auto-update, and then re-enable it again. If I hit "ignore" to disable the auto-update feature, how do I reverse that action?

If it is just temporary, just select No.
But if you have selected Ignore, you can reverse it by deleting /settings/BUILD-DATA.

[gn77b]

@procount

I looked at the readme but I couldn't find the relevant info, maybe I didn't dig deep enough, sorry if that's the case.

I did some experimenting so I'm starting to get a feel of how things work. It looks like the crux of the matter is that the "name" field in os.json needs to match the one in SETTINGS/installed_os.json for that specific OS. It looks to be the one thing that PINN cares about when detecting an OS update. Still, I have one question. PINN only allows me to select the USB disk as destination drive in this case (LE update in the /os folder of the USB stick). Does this mean that it will install to USB instead of replacing the SD card installation?

[procount]

It looks like the crux of the matter is that the "name" field in os.json needs to match the one in SETTINGS/installed_os.json for that specific OS.

Yes. How else would it know its the same OS?
If the name is the same and the release_date is newer, then "A new version is available".

PINN only allows me to select the USB disk as destination drive in this case

On the main menu it will show you an update of an installed OS is available. But if you want to update an existing OS, you need to go to the maintenance menu, select your old OS and select re-install. There is no USB drive destination to set because you are updating the OS. The Destination Drive is for when you want to install everything from scratch, which will wipe the whole card first.

PLEASE NOTE: this is not an update operation (like apt-get update). It is a complete reinstallation of that OS, which will wipe any previous data files etc in the previous OS.

[gn77b]

Yes. How else would it know its the same OS?

I dunno, maybe the folder name? Assumption is the mother of all fuckups

There's a ready-made NOOBS tar available for LE nightly builds. The "name" field is updated to the name of the build, I'd assumed I could simply use it as is. I think this was the source of the confusion: thinking the NOOBS build can be used for updating without change.

But if you want to update an existing OS, you need to go to the maintenance menu, select your old OS and select re-install. There is no USB drive destination to set because you are updating the OS.

This is exactly what I did, go to maintenance, select the OS and click reinstall. The fact that "destination drive" is available in that menu is confusing.

PLEASE NOTE: this is not an update operation (like apt-get update). It is a complete reinstallation of that OS, which will wipe any previous data files etc in the previous OS.

I understand it's a complete wipe of the previous install, I have no problem with that (I have a backup image of the PINN install with all OSes just in case). I'm not taking PINN for more than it's trying to be, it can't possibly have knowledge of every OS it's used for installing.

[procount]

The fact that "destination drive" is available in that menu is confusing.

Sorry I was answering from memory. I didn't remember it was there, but must be there for some reason.
Edit: for backups.