STICKY: PINN - An enhanced version of NOOBS.

[riccetto80]

Hi people noob here!

I was wondering, is normal for pinn to boot much slower compared to stand alone raspbian or libexec on a pi4b 4gb?

i mean, the rainbow first screen stay 2-3 second more compared to boot directly with a sd with raspbian stand alone, and the black screen after the rainbow one seems to need too more time compared to raspbian stand alone.

[ShiftPlusOne]

Yes, since it needs to load initramfs.

[procount]

"Much slower" is a very subjective term, but I don't think it is excessive.

Are you comparing the rainbow screen and black screen times of PINN compared to plain Raspbian, or the rainbow/black screen times of "Raspbian installed by PINN" compared to plain Raspbian? I think the latter case should be the same.

As Shiftplusone said, the architecture of PINN and Raspbian is a little different in order to ensure PINN's recovery partition is kept read-only as much as possible so that you always have a reliable recovery mechanism. This may make the rainbow screen stay a little longer, but overall the boot time is still pretty fast (although it seems a little slower on the Pi4 compared to previous models, probably due to the bootloader being stored in the eeprom :shrug: )

If the overall boot time into Raspbian when using PINN is a concern, there are many ways to speed this up by trading off flexibility:

• Many of the timeouts can be configured in PINN e.g. to avoid waiting too long for the shift key or wifi etc
• The "sticky default" option can be used when multiple OSes are installed to auto-choose a particular OS instead of waiting for user input
• The Autoboot.txt file can be used to avoid loading PINN altogether and boot directly into your OS of choice (e.g. Raspbian). This should be a comparable boot time to plain Raspbian. The autoboot.txt file would need to be removed in order to enable PINN again.

[sakaki]

@Sakaki - Many thanks for pinnify. It looks very promising and I hope to incorporate it into some of my own scripts.

Some minor points:
1) The readme is a bit ambiguous concerning "..normal practice or a bootfs" which refers to being a fixed size, but someone could infer it applied to the "maximize it to take up all remaining free space".

1) - agreed, will fix that.

2) Perhaps more detail could be added about the "supports_backup" keyword that is added in your worked example and the use of the $RESTORE variable, so that it is more comprehensive?

2) on "supports_backup", in an email (12 Mar) you said:

Supports_backup is a bit complicated and the correct value depends on history. It's all related to whether partition_setup.sh is capable of restoring an OS or not.
(This feature also makes the "fix - rerun partition_setup" better, which may now solve the gentoo upgrade scenario you mentioned a while back where the user messes things up).
The decision flow is a bit like this:
1. If your OS has always been able to be backed up by PINN (good partition_setup.sh since day 1), then supports_backup can be true.
2. If your backup is not capable of being backed up (bad partition_setup.sh, or strange btrfs files system like XBian) then supports_backup must be false.
3. If your OS was at any time not capable of being backed up, but has now been modified so that it can be, then supports_backup="update".

The reason is because PINN caches some meta-files when it installs an OS in order to permit the backup to be performed offline (if possible).
If PINN has an old copy of an OS installed that could not be backed up, and uses the latest os.json file which indicates it now is capable, it would back it up when it shouldn't.
Supports_backup="update" informs PINN to check partition_setup.sh for the "supports PINN backup" comment and if it is not present, it will download a newer version to make an old OS capable of being backed up.
It's safest/easiest to keep it as "update" and to ensure the correct comment exists in partition_setup.sh.

Is that still a reasonable reflection of the current reality? If so, I'll add something to that effect.
Also, please remind me about the $RESTORE variable?

3) The gentoo64 template for partitions.json has fixed "boot_gen" and "root_gen" file names, whereas it would be better if they were parameterized to match the partition label name parameters (if supplied). (Or are these file_names inserted to match the partition names when the template is created?)

3) Yes: when you create a template for an OS, you get to specify the partition naming. e.g.:

Code: Select all

# pinnify -f -p "boot_gen root_gen" create-template gentoo64 https://isshoni.org/pinn/os/

That (arbitrary, space separated list of partition names passed to the -p option) is then what pinnify uses to create its baseline partitions.json, and tarball names for os_list.json.

Best, sakaki

PS: I've just released a v1.3.0 of raspbian-nspawn-64 (which adds RPi4 compatibility, a Raspbian Buster host OS, and official 64-bit kernel support); details here. Using pinnify, I've made this new release simultaneously available for installation via PINN (as well as direct download), called nspawn64 there.

[procount]

Is that still a reasonable reflection of the current reality?

Yes.

please remind me about the $RESTORE variable?

The $RESTORE variable is set when a backed-up OS is being reinstalled or restored over an existing installation. In this case, some one-time operations in partition_setup.sh that are only required on first installation can be prevented from being executed a second time, as these operations would have already been done. However, modifications to the partition references (for example) should always be done.
This $RESTORE variable is also set during the "fix - rerun partition_setup" action.

3) Yes: when you create a template for an OS, you get to specify the partition naming.

Ah yes, it is substituted from the meta-template, not the os-template where I expected it to be.

[RaspberryPi4BFan]

Hello!

I'm working on a buildroot update for pinn.
If you want to try: https://github.com/RaspberryPiFan/pinn- ... p?raw=true
It's untested!
I don't know if it even boots up!

[costel78]

Hello,

When I add quiet option to cmdline.txt and hdmi_enable_4kp60 in config.txt, no matter what OS in Raspberry Pi 4, PINN do no show up at reboot to be able to select OS. It is working, last OS boot after ~ 10 seconds, but no image. Keyboard, and probably mouse, are working: arrow down, tab, enter select and boot next OS in the list.
By no image I mean blank screen, monitor is active, image is black-grey, not completely off.

It is by design, is PINN using framebuffer instead kms or fkms ?
Thank you!

[procount]

Yes, PINN uses the framebuffer and is not aware of kms/fkms.

You are free to enable such configuration to any OS that PINN installs, but adding it to PINN itself is unnecessary, unsupported and likely to cause issues as you have reported.

Remember that PINN is like a totally independent OS to the other OSes that you install.
Modifying the config.txt file of PINN will have no effect on any of the other OSes you install.
You must modify the appropriate config.txt on the correct partition of each OS independently.

[costel78]

No, I enable config to OS boot partition, not to PINN itself, I mean like /dev/mmcblk0p7, but this affect PINN itself and I wondered why.

Code: Select all

fdisk -l
Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mmcblk0: 29,74 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000dcf8f

Device          Boot    Start      End  Sectors  Size Id Type
/dev/mmcblk0p1           2048 15494140 15492093  7,4G  e W95 FAT16 (LBA)
/dev/mmcblk0p2       15494141 20766719  5272579  2,5G  5 Extended
/dev/mmcblk0p5       15499264 15564797    65534   32M 83 Linux
/dev/mmcblk0p6       15564800 16089087   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p7       16097280 16621567   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p8       16629760 17154047   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p9       17162240 17686527   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p10      17694720 18219007   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p11      18227200 19275775  1048576  512M  c W95 FAT32 (LBA)
/dev/mmcblk0p12      19283968 19808255   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p13      19816448 20340735   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p14      20348928 20553727   204800  100M  c W95 FAT32 (LBA)
/dev/mmcblk0p15      20561920 20766719   204800  100M  c W95 FAT32 (LBA)


Disk /dev/sda: 238,49 GiB, 256060514304 bytes, 500118192 sectors
Disk model: 2115            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8445f389

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1            8192    137215    129024    63M  e W95 FAT16 (LBA)
/dev/sda2          137216 500118191 499980976 238,4G  5 Extended
/dev/sda5          139264    204797     65534    32M 83 Linux
/dev/sda6          204800  50536445  50331646    24G 83 Linux
/dev/sda7        50536448 100868093  50331646    24G 83 Linux
/dev/sda8       100868096 151199741  50331646    24G 83 Linux
/dev/sda9       151199744 193142781  41943038    20G 83 Linux
/dev/sda10      193142784 203628541  10485758     5G 83 Linux
/dev/sda11      203628544 237182973  33554430    16G 83 Linux
/dev/sda12      237182976 287514621  50331646    24G 83 Linux
/dev/sda13      287514624 342704125  55189502  26,3G 83 Linux
/dev/sda14      342704128 367869949  25165822    12G 83 Linux
/dev/sda15      367869952 384647165  16777214     8G 83 Linux
/dev/sda16      384647168 439812093  55164926  26,3G 83 Linux
/dev/sda17      439812096 500118191  60306096  28,8G 83 Linux

On /dev/mmcblk0p6 is official Rasperian-Full boot partition, on 7 is gentoo 32 bits, on 8 is gentoo 64 bits and so on.
I wonder why OS config affects PINN iteself.
I am sorry for my English, not a native speaker.

[procount]

OK.
So you said PINN does not show up on "reboot".
Do you mean when rebooting FROM an OS that is already in fkms mode? Or do you mean it happens even if you start PINN from a power off condition?

One more point to check - PINN only displays on HDMI0, so make sure your HDMI monitor is connected to the socket nearest the USB-C power connector (but I think if this was your problem, you would at least see a more purple-like rainbow screen instead of just a blank screen).

[costel78]

First, sorry for the delay. As it seems nobody else encounter this behavior, at your suggestion, I started to look for an hardware error - the cause of delay. It seems that my aten hdmi switch is the culprit . It does not output anything if Pi reboot and the resolution is changed. If manually input port is change the image appear.
The only thing that puzzle me is why and how quiet option trigger that...

Thank you very much for your support!

[procount]

No Idea, but glad you resolved it.

[pbreneman]

Can PINN Lite be set up to have both the Ultibo Demo https://github.com/ultibohub/Demo and also Raspbian Lite https://wiki.freepascal.org/Ultibo_Quick_Start as two operating systems? It would be nice to show what Ultibo can do, and then be able to compile other Ultibo examples and see the new result with a reboot.

[MisterFloppy]

Could you please remove "Lakka" from the "blacklist" in this situation so that it can be downloaded and installed via "Pinn lite?", too? Thank you in advance!

Thanks for the notification. I will verify this and adjust as necessary. (May take a week before I can do this unfortunately).

There had been a database corruption at https://www.lakka.tv a few weeks ago which resulted into the issue that not a single file could be downloaded from their website , but they have resolved this problem in the meantime and also published an update to "Lakka 2.3 with RetroArch 1.7.8".

But nevertheless, "Lakka" has vanished from the list of available OSs that "PINN" can "see" at all, even when booting from a SD card.

I'm assuming that they have changed all download URLS because of the database corruption - could you have a look at it and adjust "PINN", please?

And it would be great if at the same time you could solve the problem mentioned at https://www.raspberrypi.org/forums/view ... 8#p1523908 regarding "PINN" not listing "Lakka" when booting from USB without a SD card in the device, too, of course

Thank you in advance!

[procount]

The maintainers are in the process of rebuilding Lakka for NOOBS. When it is ready it will automatically be available through PINN.

[MisterFloppy]

See https://github.com/procount/pinn/issues/310 for details.
I will address this issue soon.

Regarding your last posting at github where you wrote "I think it is related to changes in the firmware related to the new Pi4 and Buster multiple display capability. This shouldn't affect RPI models prior to the Pi4, however, and I hope to be able to get it working again for the next release.", I agree with you:

The symptoms of this issue seem to "spread", for example, see here:

- "Composite out broken on RetroPie 4.5", source: https://retropie.org.uk/2019/07/composi ... ropie-4-5/
- "After upgrade To buster Composite output stop working", source: https://www.raspberrypi.org/forums/view ... 5#p1519473
- "No video after the splash screen/bootloop with RPi3B and LibreELEC 9.1.501 when using composite output instead of HDMI", source: https://forum.libreelec.tv/thread/20337 ... post127368
- "Lakka - Composite Output to CRT is broken on Pi 3", source: https://forums.libretro.com/t/lakka-bro ... pi-3/24229

I ran into the same problem today when I upgraded "Lakka" to v2.3.1 - the logo appeared, but then nothing happened anymore...
I could solve this issue by following the hints regarding updating the firmware files manually given at https://forum.libreelec.tv/thread/11921 ... #post84908 :

I downloaded bootcode.bin, start_x.elf and fixup_x.dat from the RPi firmware github repository at https://github.com/raspberrypi/firmware ... aster/boot, renamed start_x.elf to start.elf and fixup_x.dat to fixup.dat and copied the 3 files to the /flash partition - problem solved!

Hope you can resolve the issue for "PINN" soon, too - good luck!

[g55]

@g55
TL;DR

"You need to boot with sdhci.debug_quirks2=4 in cmdline.txt of each OS for it to work, but it will sacrifice SD speed (I don't know how much)."

Hi + Thx for the reply.
I just found the time to test it ... yep, with this setting im cmdline.txt the SD speed decreases by almost 50% , here my tests with hdparm -t :
before : Timing buffered disk reads: 126 MB in 3.05 seconds = 41.35 MB/sec
after : Timing buffered disk reads: 68 MB in 3.05 seconds = 22.30 MB/sec

Ok, I would say : "sacrifice" is the best "description" for that

Anyway, I will continue testing, the "autoboot.txt" as alternative as well. For me personally, the SD speed is not that critical on RPI4, as all root + data partitions are on the attached SSD via USB3 adapter . The SD card itself contains only PINN + settings + boot partitions ...

[pbreneman]

Can PINN Lite be set up to have both the Ultibo Demo https://github.com/ultibohub/Demo and also Raspbian Lite https://wiki.freepascal.org/Ultibo_Quick_Start as two operating systems? It would be nice to show what Ultibo can do, and then be able to compile other Ultibo examples and see the new result with a reboot.

I've now used PINN Lite to install only Raspbian Lite (on a zero wireless) and compiled Ultibo and it's Hello World program (see wiki page above for details). I now hope to change PINN to boot a second OS (not really an OS but the Ultibo Hello World program) on the same SD card. Can anyone help me?

[BRX7]

I have a project space entry which I wish to convert to arch linux,
I have extracted all boot and root files from the compress image from arch wiki guide, now how would I make it visible in PINN os selector,

this is for a RPI4 i am running on SDcard

[procount]

I've now used PINN Lite to install only Raspbian Lite (on a zero wireless) and compiled Ultibo and it's Hello World program (see wiki page above for details). I now hope to change PINN to boot a second OS (not really an OS but the Ultibo Hello World program) on the same SD card. Can anyone help me?

Sorry, I've not had time to look at this for you yet.
Unfortunately, it's not easy to add more OSes after you installed them since it allocates the whole of the SD card to all the OSes that you initially install. (The projectSpaces are a way around this for most common OSes.)

The easiest way (not necessarily the best, but what I can think off the top of my head) to do this for you now is as follows:
1. Format a USB memory stick as FAT32
2. Make a directory on it called 'os' (no quotes)
3. Use PINN to backup your existing Raspbian-Lite to the USB stick (see the PINN README.md for full details)
4.Now you have to use PINN to install your backup copy of Raspbian-lite AND a ProjectSpace.

As you have a PiZeroW, you may also need a USB hub or a usb shim at the least to attach your USB stick.
If you don't have these, an alternative is to just start again with PINN and this time install a new copy of Raspbian-Lite AND a ProjectSpace. If you can copy your ultibo files first and then restore them to the new copy afterwards, that may be just as good.

The idea is to use the BOOT partition of your ProjectSpace for your ultibo projects, but you have to tell PINN this ProjectSpace is now in use.
From PINN. press ctrl-alt-F2 and login with username=root, password=raspberry.
Then:

Code: Select all

cd \settings
cp installed_os.json installed_os.bak
nano installed_os.json

The installed_os.json must be in valid JSON format, so please try to keep all synta the same, otherwise PINN may not work, hence the command to backup it first above, so you can recover if you make a mistake.
You should see two entries in there: one for RaspbianLite and the other for ProjectSpace1.
In the ProjectSpace1 entry, IIRC, you need to change bootable to TRUE for the entry to be visinble in PINN's Bootmenu.
Here you can also change the name (to Ultibo?) and maybe the description to something more useful.
Make a note of the 2 partition references used for this ProjectSpace/Ultibo. the first one is the partition nuber that you will use to store your new Ultibo programs on, so you would mount it from Raspbian Lite and store all necessary firmware, boot and ultibo files that you need.
Save it and reboot.
Sorry these are brief instructions. I may make a specific Ultibo installer when I have more time.

[procount]

I have a project space entry which I wish to convert to arch linux,
I have extracted all boot and root files from the compress image from arch wiki guide, now how would I make it visible in PINN os selector,

See my post above about manually converting a ProjectSpace entry in installed_os.json to a bootable OS entry.
I assume you have already copied the extracted Arch files to the project space partitions...?
I'll get around to an updated Arch installation when I have a bit more time.

[pbreneman]

....
Sorry these are brief instructions. I may make a specific Ultibo installer when I have more time.

Thanks for the help! I will try to figure out what to do.

[BRX7]

Thanks I managed to loop mount and install manjaro img onto project space boot n root
Superb stuff

[procount]

@BRCX7 - glad it worked for you.

JFYI (and anyone else): Another option would have been to install an older version of Arch instead of the ProjectSpace (You may have to add the 'showall' option in order for it to show up as installable, especially on a Pi4), and then manually replace the files with the latest Arch/Manjaro files by loop mounting as before. (A full Manjaro installation is in the works...)

[thatchunkylad198966]

Has this been updated for the new .ISO's?