User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Sat Jan 23, 2021 8:16 pm

@THX1182 - Please follow the Lineage FAQ about booting from USB -> https://konstakang.com/devices/rpi4/LineageOS17.1/
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Sat Jan 23, 2021 10:08 pm

jharris1993 wrote:
Sat Jan 23, 2021 6:34 pm
I am not sure if you are understanding me correctly. Let me try again.
I think it is just a question of terminology.
Apologies if I laboured (labored?) the point a bit about raw installation images, but I was replying also to the wider audience.

To use the terminology in the PINN README, what I create and provide via PINN are raw installation images in PINN format.
What you have been creating manually is a "Custom OS", mostly based on Raspberry Pi OS.
Using PINN to backup an installed OS is an alternative way of creating a "Custom OS".
The format is essentially the same. There is no real difference between any of them. They are all installed in the same way by PINN.

I think my off-the-cuff comment concerning the setup script has been taken too seriously. I think it is a red herring concerning your wifi.
The problem is that this script is being used for 2 purposes, for 2 use cases.
1) The main purpose is to locate the partition references which will be in a different location than when it was created.
2) This file can also used to convert a raw installation image to a multiboot capable OS, or do some convenience customisation.

Case 1 is done on each installation, whether it is a raw installation, custom OS or backup image.
Case 2 is only done on first installation of a raw image. It is determined by the original creator of the image.
The $restore variable was only introduced when an issue was discovered on a certain OS that couldn't handle being configured twice.
Since this script is unique to each OS, there's not a lot PINN can do about it.

In your case, there is no difference between your original custom OS and a backup of it (apart from the few outstanding issues I have which will be fixed shortly). I don't see the distinction you are trying to make between an installation backup and a standard backup, or what PINN should do about it over and above what it is already doing.
The normal PINN behavior is to display the wallpaper delaying for "x" number of seconds waiting for the shift key, then progress to the boot selection menu, waiting for an additional number of seconds before eventually timing out and booting either the "sticky default" or whatever was booted previously. This takes an unacceptably long time for a headless system to boot. Ideally it should boot as if there is an "autoboot.txt" file present - immediately booting to the requested O/S.
PINN has a lot of flexibility in this respect. If you want to use an autoboot.txt file, you can do. This is the quickest way to boot to an OS as PINN is totally bypassed.
If you want the ability to chose an arbitrary OS at boot time, then you need to boot into an OS like PINN. Here you are at the mercy of however long the firmware takes to startup. PINN is pretty quick to start thereafter because it is very minimal.
It is necessary to wait a certain amount of time for the user to make a selection, but PINN again allows you to alter nearly all the timeout settings, so you can make it as fast or as slow as you want. If there is only one OS loaded, it is booted immediately. If you have more than one, you can have another programmable timeout to select which one you want, or choose a sticky default so that it boots like there was only one os. Or you can set forcetrigger so that the user stays in PINN and must interact with it to boot an OS.

When you have GPIO configured, you will be able to boot directly from PINN into a selected OS without using any timeouts. Maybe one of the switch settings could be to boot into PINN itself for customisation, or manual selection. Unfortunately, the RPI firmware does not provide the facility to boot directly into a different OS by reading different GPIO settings (like autoboot.txt), unless they all share the same boot partition, but you've already tried that method. so you have to suffer a double boot with the associated time delays of loading 2 firmwares etc.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Sun Jan 24, 2021 9:43 am

Thanks for the clarification. Terminology is the rope that has hung many a fine project.

Maybe I am being too picky, but this has been a confusing journey and I want make sure I don't paint myself into a corner.

Thanks!
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Sun Jan 24, 2021 10:08 am

:thumbsup:
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Sun Jan 24, 2021 3:25 pm

Quick question:

Can the Raspberry Pi boot from a GPT partitioned disk? Or, for larger boot sets, should I stick with a MS-DOS partition table and create extended partitions?
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Sun Jan 24, 2021 3:47 pm

The short answer is no.
The firmware does not support it and therefore neither does PINN.
You can have a secondary disk as GPT though.

If you read other posts you may find those who get USB boot working with a hybrid GPT/MBR partitioning scheme, but PINN will not support it.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Sun Jan 24, 2021 5:26 pm

procount wrote:
Sun Jan 24, 2021 3:47 pm
The short answer is no.
The firmware does not support it and therefore neither does PINN.
You can have a secondary disk as GPT though.

If you read other posts you may find those who get USB boot working with a hybrid GPT/MBR partitioning scheme, but PINN will not support it.

Ahh! Interesting!

I was reading an article that (alleges to) describes a way to dual boot a Pi, without using a boot manager like PINN. The first thing he has you do is partition the target device as GPT, create a handful of partitions, and then rsync a bunch of data. Sounded reasonable on the surface, but the GPT partitioning threw me for a loop. Made me wonder - since he's talking about the Pi-4 exclusively, is that possible? Even if it is, I'd be more likely to stick with the well-known MS-DOS partitioning, using extended partitions if necessary since everybody knows that works.

Makes me wonder if maybe this guy is smoking dope?

Totally different question:

If I execute "reboot 'x' ", where 'x' is a partition within the PINN formatted media, should 'x' be the respective boot partition for a particular O/S, or the O/S's root partition? My gut feeling is you want to jump through the boot partition.

I have a ultimate design that will have me booting as many as five different operating systems within PINN. The only reason I haven't already loaded up a SSD with the five operating systems is that jumping through all the hoops that I already did, five mortal times, makes me hesitate.

BTW, have you considered a PINN image of the 8/8 version of the Raspbian 64 bit beta? The one you have is from May, not August. and I want to load up the August version.

Likewise, if I were to slip you a copy of an operating system or two, (Raspbian based), would you be willing to run your script on them? Or maybe slip me a copy of the script "on the down-low" (under the table, or whatever you call it where you are.)
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Sun Jan 24, 2021 6:23 pm

Well it seems since the Pi4 boot loader is now in EEPROM, it has been modified to also allow GPT.
Please see https://github.com/procount/pinn/issues/413 for more information.
However, as is stated on that page, there's a lot of jiggery-pokery to get PINN to work on it and PINN will not be able to create the partitions. PINN has to support all RPI models, so it will stick with MBR.

Reboot 'X' refers to the boot partition number.
It should work on all RPI models before the PI4, and also on the Pi400 and Pi4 rev 1.4, but not the Pi4 before rev 1.4.

Re: 64-bit Raspberry Pi OS - it's just a question of time and getting my resources together to test it. I have a number of OSes that I need to add....

Regarding scritps, I suggest you look at PINNIFY https://github.com/sakaki-/pinnify as Sakaki is much better at explaining things than me.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Sun Jan 24, 2021 7:16 pm

Here's a tough one for you:

Given a group of operating systems to back up, of which the compressed root tarballs will be greater than 4 gigs in size.
Also given a target drive that is more than sufficiently sized to accommodate the entire data set - but is formatted as FAT-32 so that it can be read anywhere.

Question:
What happens?

Does the backup fail because the filesystem can't handle files larger that 4 gigs?
Or does it cope with that by "chunking" the backup tarball into pieces small enough to fit?

Right now my "Installation" media is formatted as ext4 so it will fit everything and be readable by PINN.
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Sun Jan 24, 2021 7:27 pm

jharris1993 wrote:
Sun Jan 24, 2021 7:16 pm
Does the backup fail because the filesystem can't handle files larger that 4 gigs?
Yes
jharris1993 wrote:
Sun Jan 24, 2021 7:16 pm
Or does it cope with that by "chunking" the backup tarball into pieces small enough to fit?
No, It has the premise that every partition has only one tar file.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Sun Jan 24, 2021 9:23 pm

Re: 64 bit Pi images:

Here is the Genuine and Official location for ALL 64 bit images, as specified by the engineering types at Raspberry Pi:

https://downloads.raspberrypi.org/raspios_arm64/images/

It contains both the May and August releases. The version available in the PINN repo is the May version.
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 11:28 am

Suggestion 1:
When backing up an operating system, after creating the checksums and after the entire operation for that particular O/S completes, PINN should go back and verify all the checksums to ensure the backup is valid.

Justification:
On several occasions, when backing up my installed images, there is one image in particular that NEVER passes validation when I try to restore it. If I attempt to verify the tarball, (in this case, the root tarball), using sha512sum, the boot tarball always verifies and the root tarball always fails with a distinctly different checksum than listed.

I only find out that the backup is invalid after completing everything, preparing a new installation target, and restoring several images.

Note: I have copied all my installation images and backups to a new SD card on the off chance that one card was going bad. After copying the installation/backup images to the new card and erasing the invalid backup, I recreated the backup and was able to successfully restore it.

Suggested behavior:
Case 1:
Backup succeeds and verify of both tarballs succeeds.
Continue to the next OS to backup if exists, otherwise end with success message.

Case 2:
Backup succeeds and verify of one or both tarballs fails.
Offer the user these options:
1. Retry the current backup
2. Skip to the next OS to backup, converting this backup space on the target device to a project space so that it can be reused later to retry a backup or reinstall the original O/S.
3. Abort the entire process, with a failure message that, when acknowledged, returns to PINN's main screen for further action if necessary.

Suggestion 2:
Verify the checksum of both of the installation/restore tarballs BEFORE attempting to install or restore an image.

Justification:
It appears that the tarball checksum is only verified AFTER the installation/restore completes as PINN proceeds with the entire extraction and writing of the filesystem before checking to see if the tarballs are valid.

As some of the images can be non-trivial in size, it wastes a considerable amount of the user's time only to discover that the restore/installation isn't valid.

Suggested behavior:
Check the tarballs for validity before the installation or restore operation continues, continuing with the suggested behaviors of the first suggestion.

What say ye?
Last edited by jharris1993 on Mon Jan 25, 2021 11:47 am, edited 1 time in total.
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 11:45 am

Now that sounds very odd! I've never seen that before. The checksum is really to guard against download errors and file corruption, so I wouldn't expect it to fail when writing to a local USB drive.
I have recently improved the error options when a checksum fails, so I thought most of case 2 is already covered.
It probably warrants further investigation as to why the checksum fails. If you're willing to share that image with me, I can see what I can find out.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 12:05 pm

If you encounter a checksum error, you should get a dialog box with the following options (and associated actions):

Abort - Aborts the entire process, but keeps any existing OSes that installed properly.
Discard - Deletes all installed files from this OS (but keeps the partition space unused) and continues with the next OS
Keep - Keeps the installed files, but marks the OS as unbootable.
Retry - Deletes the installed OS files and then tries to download/install the OS again.

So I think this caters for all of your suggestions already, except for the conversion to a project space, which is not always feasible.

EDIT: Checking the checksums immediately after backing them up is something I could optionally add.

See viewtopic.php?p=1454137#p1454137 for more info and follow link to README_PINN section.
That reminded me that backup checksums are calculated after the files have been committed to disk, so I do wonder about the merits of checking them again immediately. Maybe something else is amiss here?
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 12:56 pm

jharris1993 wrote:
Mon Jan 25, 2021 11:28 am
Suggestion 2:
Verify the checksum of both of the installation/restore tarballs BEFORE attempting to install or restore an image.
This would only be applicable to local files, and won't work with files installed from the internet.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 1:00 pm

procount wrote:
Mon Jan 25, 2021 11:45 am
Now that sounds very odd! I've never seen that before. The checksum is really to guard against download errors and file corruption, so I wouldn't expect it to fail when writing to a local USB drive.
I have recently improved the error options when a checksum fails, so I thought most of case 2 is already covered.
It probably warrants further investigation as to why the checksum fails. If you're willing to share that image with me, I can see what I can find out.

Unfortunately I have already deleted that image. Since I was not sure how PINN handles multiple backups of the same image, (and I have learned that PINN often does not do what I would expect it to do), I decided better safe than sorry.

Also, checksumming the backups is an excellent idea because, (obviously), media can go bad and/or bit-rot can corrupt an image. So, even if you're writing to local media, a checksum to validate the image is worthy and important.
I have recently improved the error options when a checksum fails, so I thought most of case 2 is already covered.

Is there a new release since a couple of weeks ago?


Additional suggestion:
Please, please, pretty please have PINN either not save installation selections when quitting, or clear them on startup. It's really annoying to have a previously selected O/S re-install in a subsequent run. Especially if there are a limited number of slots to install things into.

Update:
I noticed an interesting behavior: If I - inadvertently - select an O/S for install that is already installed, instead of installing a second copy, it re-installs over the original, destroying any work I have done with it. What if I want two installs of the same thing, because I want to do two different - and incompatible - things with them?

PINN should - at the very least - give the user a warning that O/S "X" is already installed and do they want to overwrite it?

Update 2:
It's even worse than that.
Given target PINN media that already has several operating systems installed - and no additional space reserved as project spaces - inadvertently installing something else overwrites everything on the installation target, replacing it with the one installation. In this case wiping out about three hours of work.

My expectation would be that PINN would warn me that there are no more installation slots available and bail.

Also:
It would be damned convenient if PINN would label the partitions it creates with the name of the operating system within it.

Thanks!
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 2:02 pm

jharris1993 wrote:
Mon Jan 25, 2021 11:28 am
there is one image in particular that NEVER passes validation when I try to restore it.
jharris1993 wrote:
Mon Jan 25, 2021 1:00 pm
Unfortunately I have already deleted that image.
Sorry, I assumed you meant each time you BACKED UP and restored that image it failed. But in this case it might have been a one-off error, not a consistent error.
jharris1993 wrote:
Mon Jan 25, 2021 1:00 pm
Since I was not sure how PINN handles multiple backups of the same image,
Take as many as you like - that's why the date&time is added to the OS name of backups, to keep them associated, yet separate.
jharris1993 wrote:
Mon Jan 25, 2021 1:00 pm
Is there a new release since a couple of weeks ago?
See the link. It was v3.2. I'm surprised that was nearly 2 years ago!
jharris1993 wrote:
Mon Jan 25, 2021 1:00 pm
Additional suggestion:
Please, please, pretty please have PINN either not save installation selections when quitting, or clear them on startup. It's really annoying to have a previously selected O/S re-install in a subsequent run. Especially if there are a limited number of slots to install things into.
This is original NOOBS behaviour. I added the Clear button so users can deselect them. I never was sure why this behaviour was there, so maybe good to remove it.
jharris1993 wrote:
Mon Jan 25, 2021 1:00 pm
Update:
I noticed an interesting behavior: If I - inadvertently - select an O/S for install that is already installed, instead of installing a second copy, it re-installs over the original, destroying any work I have done with it. What if I want two installs of the same thing, because I want to do two different - and incompatible - things with them?

PINN should - at the very least - give the user a warning that O/S "X" is already installed and do they want to overwrite it?
See https://github.com/procount/pinn/issues/380. It's on my todo list.
PINN cannot ADD OSes to an already installed drive. If you want 2 installs, or the ability to add an OS later, you have to use ProjectSpaces to reserve space. Install is always Destructive. There is a warning message that tells you.
jharris1993 wrote:
Mon Jan 25, 2021 1:00 pm
Update 2:
It's even worse than that.
Given target PINN media that already has several operating systems installed - and no additional space reserved as project spaces - inadvertently installing something else overwrites everything on the installation target, replacing it with the one installation. In this case wiping out about three hours of work.

My expectation would be that PINN would warn me that there are no more installation slots available and bail.
It does. Please read the dialogs that are displayed.
This will be solved in Issue #380 in the future.
If you just want to reinstall or replace one or two OSes, then use those options in the Maintenance menu instead.
jharris1993 wrote:
Mon Jan 25, 2021 1:00 pm
Also:
It would be damned convenient if PINN would label the partitions it creates with the name of the operating system within it.
Thanks!
That's up to you! (for your custom OSes, anyway). You don't have to call them Boot and Root. In fact, when I convert an OS for PINN, I try to add the OS name into each partition, or at least an abbreviation, since it is restricted in length according to the files system used. But Pi OS is created by the RPT and I can't change them.

By the way - for bugs and suggested enhancements to PINN, I suggest you add an issue on my github yourself. It means I can keep track of them more easily as they may get lost in the pages of posts we have created here. It's also useful to have a browse through the issues there first to prevent duplicates.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 3:02 pm

If I re-label a partition after install, will that break PINN?
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 3:07 pm

No. It might break your OS if it uses the partition names to find its partitions (like Ubuntu does), but if yours are based on Raspbian, then it should be ok. If you reinstall, then the partition names may be changed back.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 4:33 pm

Update 2:
It's even worse than that.
Given target PINN media that already has several operating systems installed - and no additional space reserved as project spaces - inadvertently installing something else overwrites everything on the installation target, replacing it with the one installation. In this case wiping out about three hours of work.

My expectation would be that PINN would warn me that there are no more installation slots available and bail.
It does. Please read the dialogs that are displayed.
This will be solved in Issue #380 in the future.
If you just want to reinstall or replace one or two OSes, then use those options in the Maintenance menu instead.
I did, and do, read the dialogs.
Insofar as I remember, the dialog says something like "The operating system is going to be installed to your such-and-so media" [OK] - [Cancel]

I don't remember it saying anything about nuking your drive back to the stone-age. In any event, if you are doing something potentially hideously destructive, like nuking the last five installations on the drive, the system should detect and warn you explicitly that there are existing installations that will be blown to hell-and-gone if you continue.
Sorry, I assumed you meant each time you BACKED UP and restored that image it failed. But in this case it might have been a one-off error, not a consistent error.
You are exactly correct in your assumption. It was a backup that repeatedly failed. Not only that, but removing the backup file, and re-creating the backup always failed on restore.

This was only solved after I changed the media the images were being written to.
PINN cannot ADD OSes to an already installed drive. If you want 2 installs, or the ability to add an OS later, you have to use ProjectSpaces to reserve space. Install is always Destructive. There is a warning message that tells you.
Absolutely true.

What had happened is that subsequent reinstalls had inadvertently consumed all the available "slots", (project spaces I installed anticipating subsequent installations). In fact, since I want the operating systems to be installed in a specific order on the disk, I installed the first OS and added enough project spaces for all the additional installations plus 1, just in case. I then boot to the installed O/S, let it do it's little fixups, (like fsck'ing the new filesystem), and get settled down. I then reboot back into PINN and install the second O/S, rinse and repeat until all the desired operating systems are in place.

What I suspect happened is that I consumed all available project spaces - or something else weird happened - and instead of telling me that there's no more space to install anything in, it simply made space for itself by nuking everything else.

I don't know if the behavior is repeatable. Frankly, I'm in no hurry to experiment with it until I get a stable installation that works the way I want it to.


P. S.
I have to admit to being a bit "gun shy" when it comes to posting bugs on GitHub. No matter how polite the maintainers - and their friends - may be on the forums, they get damned nasty on GitHub. Too many times I have gone to the project's GitHub page and entered a bug, only to be castigated by either the maintainer, or others, complaining that:

1. My bug is a duplicate of another bug entered five years ago, never fixed, and buried so deep that you'd have to be an archeologist to find it. (And yes, I do search and read.)

2. My bug is actually "by design" as specified in another obscure bug entry, (that has an entirely different name), and was stated so in the previous bug.

3. My bug is abysmally stupid and I should have read the man-page for [insert obscure command that I'd never heard of before]. And/or it's documented in some web article that is not referenced anywhere, and there's no clue whatsoever that I should read it. (i.e. It's not in the provided documentation, or even hinted at in the provided documentation.)

4. I used to be a professional software QA analyst. I pride myself in writing the clearest bug reports I can make. So, when someone replies to my bug asking for information I already provided AT THE VERY TOP of the bug report, and then criticizes me on the quality of my reporting - it really burns my biscuits and demonstrates that these idiots don't even bother to actually read the reports.

5. Etc., etc., etc. I get enough abuse in real-time, I don't need it on the forums I visit.

Once burnt, twice shy. I may eventually try that, but I'll have to wait for the burns to heal from my last foray into GitHub bug reports.

Sorry for the rant, but that's one of my hot buttons.

Thanks for your patience.
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 6:05 pm

jharris1993 wrote:
Mon Jan 25, 2021 4:33 pm
Insofar as I remember, the dialog says something like "The operating system is going to be installed to your such-and-so media" [OK] - [Cancel]
From the source, It actually says:
"Warning: this will %1 the selected Operating System(s) to %2. All existing data on the %3 will be deleted.".
But when I get around to fixing #380, you will be better protected from nuking your installations.
jharris1993 wrote:
Mon Jan 25, 2021 4:33 pm
This was only solved after I changed the media the images were being written to.
Any idea what was wrong with your media? It doesn't sound like calculating the checksum twice in succession would have guarded against this. But I'm not understanding how it failed.
jharris1993 wrote:
Mon Jan 25, 2021 4:33 pm
What I suspect happened is that I consumed all available project spaces - or something else weird happened - and instead of telling me that there's no more space to install anything in, it simply made space for itself by nuking everything else.
There's never "any more space" available. You have to replace an existing OS or projectspace if you already have installations. If you choose 'install' by mistake and don't heed the warning, then it starts from scratch and "nukes" your installations. (#380 will be bumped up my priority list).
jharris1993 wrote:
Mon Jan 25, 2021 4:33 pm
I have to admit to being a bit "gun shy" when it comes to posting bugs on GitHub. No matter how polite the maintainers - and their friends - may be on the forums, they get damned nasty on GitHub
.........
Once burnt, twice shy. I may eventually try that, but I'll have to wait for the burns to heal from my last foray into GitHub bug reports.

Sorry for the rant, but that's one of my hot buttons.
No worries. I've not had that experience. It's mostly just me on my issue page, with the occasional learned input from Lurch (who was a NOOBS developer some time ago)
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

buzzypi
Posts: 2
Joined: Mon Jan 25, 2021 5:43 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 6:23 pm

PINN backup of Raspberry Pi OS (32-bit) after restore to formatted sd-card the mounted drives do not show on desktop and cannot be accessed by "pi" user.

I'm totally new to the forum. Please forgive me if this is not the right place for this and point me in the right direction.

Used PINN to create a fresh install of Pi OS (32-bit) with raspberry pi desktop (2021-01-11 version) but not "full" with extras. Made a few configuration changes including display settings and adding doublecmd-gtk then created a backup with PINN. Removed and formatted the sd-card and using fresh install of PINN restored the backup of the Pi OS.

The restored Pi OS does not show mounted drives on the desktop, neither the extra partitions on the sdcard nor the usb drive that has the backups and other files. These were visible on the desktop on the original install. These do show with the taskbar icon so the usb drive can be ejected. As pi user cannot view the contents of the /media/pi/ directory but can view the directory as root user.

Is this a bug and what can I do to restore the behaviour of showing the mounted drives on desktop and allowing access by logged in user such as "pi" user?

Thanks.

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 6:55 pm

There's never "any more space" available. You have to replace an existing OS or projectspace if you already have installations. If you choose 'install' by mistake and don't heed the warning, then it starts from scratch and "nukes" your installations.
I would beg to suggest that this is not intuitively obvious.

From my, "been around the block a few times" point of view - and how I understood the documentation - is:
1. There are three install options:
* Install an operating system for the first time. I would expect the utility to tell me if there's enough space without overwriting existing installations.
* Re-install a previously installed operating system using an "original" image, or one from a backup, (which replaces the original operating system being reinstalled).
* Replace a previously installed operating system, which replaces the original operating system with something entirely different.

2. A "project space" is a placeholder for a future installation, done at the user's discretion, at some future point in time. In essence, it anticipates additional installs and reserves space for them.

3. A "project space" is NOT an operating system. It can neither be selected at boot time nor can it be booted. Depending on how things are set up on your target system, it may not even automount.

Therefore:
1. A "project space" exists as a pigeonhole, waiting for something to fill it.

2. Since, (with regard to the operating systems), a "project space" is "empty space", it should be possible to "install" into the next available "project space".

3. With regard to "replacing" an "empty space" with an operating system automatically, this is done when the first operating system is installed.

Again, IMHO, reading the documentation from the eyes of someone totally unfamiliar with PINN, this is not at all obvious. Your explanation makes sense of the behaviors I have been seeing. I go to install O/S number two, expecting to fill the next available "empty slot", (project space that is unoccupied), and it ends up nuking the entire drive.

As far as paying attention to the dialogs, perhaps they can be made a bit more distinctive so they look less like each other?
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

User avatar
procount
Posts: 2454
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: STICKY: PINN - An enhanced version of NOOBS.

Mon Jan 25, 2021 10:08 pm

jharris1993 wrote:
Mon Jan 25, 2021 6:55 pm
There's never "any more space" available. You have to replace an existing OS or projectspace if you already have installations. If you choose 'install' by mistake and don't heed the warning, then it starts from scratch and "nukes" your installations.
I would beg to suggest that this is not intuitively obvious.
If you have not picked that up already, then I apologize for not making it more obvious. Since PINN is a fork of NOOBS, I must have expected it to be well known. I have written it countless times in various posts, but I can't immediately find it in the documentation.

So this is the Modus Operandi of PINN (& NOOBS).
  • PINN is normally copied to a FAT32 formatted drive (originally for ease of installation when friendly tools were not available. Nowadays, I also provide an image file that can be written using Balena Etcher or RPI Imaging Utility, or plain old DD).
  • When PINN boots, it shrinks the first partition as small as possible, creating an extended partition that fills the rest of the drive. A small 32MB logical settings partition is created in here for PINN's use.
  • PINN is then used to install one or more OSes into the remainder of the extended partition.
  • Each OS consists of multiple partitions. Some are fixed in size and some are expandable with a minimum size.
  • PINN will summate the sizes of all the fixed partitions with the minimum sizes of all the variable partitions to provide the minimum space required to install the selected OSes on your drive.
  • Any free space over and above this size is divided equally between all the variable size partitions (i.e. those marked with "want_maximized": true) which are therefore expanded to their maximum size possible.
  • During initial installation, PINN creates the fixed and expanded variable sized logical partitions in the remainder of the extended partition and installs the OS files into those partitions.
  • At the end of this process, the extended partition is completely allocated. There is no more space. Thus PINN does not have the ability to ADD any OSes to a drive that already has had OSes installed on it.
Everything above also applies to NOOBs.
One of the goals of NOOBS was to provide an easy method to restore an OS in case it got corrupted by the user, or rogue program or whatever. This worked well for a single OS, but for a multiple OS installation, it had to start again from scratch and reinstall ALL the previously installed OSes, losing anything that had been created in all the OSes.

This is the point at which PINN started. PINN added the following pertinent features in an attempt to improve upon NOOBS deficiencies:
  • The ability to re-install a single OS without nuking the others.
  • The ability to replace a single OS with another of a similar partition layout.
  • The ability to backup an OS in the same NOOBS format, so that it could be restored, or transferred to another PINN formatted drive.
  • ProjectSpaces (similar to WD PiDrive's implementation) that reserve space in the extended partition for a 2 partition Raspbian-like OS, that can be replaced with another OS.
jharris1993 wrote:
Mon Jan 25, 2021 6:55 pm
1. There are three install options:
* Install an operating system for the first time. I would expect the utility to tell me if there's enough space without overwriting existing installations.
* Re-install a previously installed operating system using an "original" image, or one from a backup, (which replaces the original operating system being reinstalled).
* Replace a previously installed operating system, which replaces the original operating system with something entirely different.
So Yes that is correct. But there is a distinct difference between these actions.
Installation occurs once and divides the entire drive into partitions which are expanded to fill the entire drive. It repartitions the entire extended partition, thus nuking any existing installation. It is a destructive operation, which is why issue #380 has been raised.

Re-installation, or replacement of existing OSes does not do any partitioning; it just re-uses the partition layout created at installation.

PINN has improved al lot of things over NOOBS, but it does not have GParted's capability, for example, to shrink, grow or move partitions. The partitions are fixed at installation time.

A ProjectSpace is not the same as empty-space, if you consider that empty-space is unpartitioned. A ProjectSpace consists of a partition layout, with each partition typically formatted with a file-system. It is basically the meta-files of an OS installation without any of the data tar.xz files.
PINN cannot install into empty-space. It can only install into partitions. Partitions are only created at initial installation when they fill the entire drive.

Use "INSTALL" to create a ProjectSpace, but REPLACE to "put" an OS in an existing ProjectSpace

I hope that crystallizes a few things for you.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

jharris1993
Posts: 164
Joined: Sat Oct 05, 2013 10:26 pm

Re: STICKY: PINN - An enhanced version of NOOBS.

Tue Jan 26, 2021 6:32 am

I hope that crystallizes a few things for you.

Yes it does.

Unfortunately - especially for later generation Pi users - not everyone is familiar with the oddities of NOOBS, especially since it has been depreciated in favor of flashing single images directly to SD cards for quite a long time now.

My first experience with NOOBS was back when the original Pi's came out, and then it was a one-OS-at-a-time thing. By the time the Pi-2 came out, NOOBS was well on it's way to being depreciated and the Pi-3's saw NOOBS relegated to the "legacy" software download link with flashable images being the norm.

Not everyone has the in-depth knowledge you have of NOOBS and it's development history. I'd say at least 90% - or even more - of the current Pi users have never used NOOBS. "Used" it? I bet they've never even SEEN it, so expecting the typical PINN user to have a close familiarity with NOOBS and the way NOOBS works might be misplaced.

This is important to remember.

The other side of this, if I could be so bold as to suggest, is that though PINN is essentially a fork of NOOBS, it doesn't have to BE NOOBS.

When the Pi came out, it was a watershed event in small form-factor computing in the same way that the Intel 8008 was a watershed event that ushered in the age of the microprocessor chip. Just think of it - a card small enough to fit in a shirt pocket that could run a "full fledged" Linux operating system! Unprecedented! People who would never think of themselves as "tinkerers" bought them and didn't know which side faced up - so the need for NOOBS.

Nowadays, people are a bit more sophisticated and flashing direct to the SD card is the norm. As a consequence, PINN is more of a "specialty item" that people use to fill a specific need that the standard installation tools don't fill - like multi-booting.

Because of this, (again, IMHO), PINN should not be constrained by ". . .well, that's the way NOOBS did it". PINN is NOT NOOBS, and should be free to expand and evolve in ways that don't necessarily have to be constrained by a tool invented back in the time of wooden ships and iron men. (And computers that burned coal and had wind-up keys! ;) )

What should be the constraining forces are the ways the current potential user-base would expect a tool like this to behave, not what an archaic tool of years gone by used to do. None of us uses punched cards, or even paper tape anymore.

What I would suggest is an interface where, someone coming to it for the first time and never even hearing the word "NOOBS", could sit down in front of it and have the tool behave in ways that the user would naturally expect it to behave.

What say ye?
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

Return to “General discussion”