procount wrote: ↑

Fri May 30, 2025 3:54 pm

Your cmdline.txt should only be one single line of text. It looks like you have 2 carriage returns before your video parameter, so it will be ignored.

If the background wallpaper image does not fill the screen, you can also add `wallpaper_resize` to cmdline.txt to make it fill the whole screen.
The main dialog window can be resized by dragging the corners of it with your mouse to make it as big as you want.

The font size can be increased using Ctrl & "+" or reduced using Ctrl & "-" to your preference.

Thanks,
Just to clarify. The two first lines is acutally one line. Should the video parameter be to the right side of this line, or can i be line 2 without any carriage returns?
Another question:
PINN is installed on a M2.MVMe disk. When installing Raspberry OS and Ubuntu I set aside 25GB extra on both. I want to use the rest of the disk for other purposes, formatted with exfat and with Samba. But it seems tthe free space is not one continus space that can be partitioned for that purpose.
Any suggestions on how to do that at the time of installing Raspberry OS and Ubuntu from PINN?

Landavardir wrote: ↑

Fri May 30, 2025 5:22 pm

Thanks,
Just to clarify. The two first lines is acutally one line. Should the video parameter be to the right side of this line, or can i be line 2 without any carriage returns?

OK. It's not easy to tell from your post. Best to include such text in code blocks to make it more readable

It doesn't matter where the video parameter is on the line, as long as all parameters are on the first line before the first carriage return. Some people advocate adding new parameters to the beginning of the line to avoid any confusion over carriage returns.

Landavardir wrote: ↑

Fri May 30, 2025 5:22 pm

Another question:
PINN is installed on a M2.MVMe disk. When installing Raspberry OS and Ubuntu I set aside 25GB extra on both. I want to use the rest of the disk for other purposes, formatted with exfat and with Samba. But it seems tthe free space is not one continus space that can be partitioned for that purpose.
Any suggestions on how to do that at the time of installing Raspberry OS and Ubuntu from PINN?

PINN will allocate any remaining space equally between all the remaining flexible partitions of all the installed OSes.
What you can do is add a Data Partition from the Utility category and allocate any remaining space to that. Afterwards, just format it as exFat or whatever you need it as. You will have to reinstall RaspiOS and Ubuntu with the Data Partition, though.

[Someone else has just posted an issue with installing RaspiOS using PINN on an NVME drive with it freezing on the splash screen. If this happens to you, please mention it, but I am looking into it and the fix will probably be just a reinstall of RaspiOS at worst - you shouldn't need to reinstall Ubuntu or the Data Partition]

I've tried your suggestion. Created a 512MB partition in Utility and then chose RaspiOS and Ubuntu. Set 25GB extra on both RaspiOS ans Ubuntu. What was left I expanded the 512MB partiton. When booting it stopped at the RaspiOS welcome screen. After a while I pressed ESC. Got this message on top left upper corner on a black screen:
Error: Can't have a partition outside the disk!
Ignore/Cancel?

Tried I or C. Somehow PINN came up and chose to boot RaspiOS. Then ran Gparted and got the same message when trying to format the partition. So I'm stuck.Can't use the partition. Both OS boots normally though.

EDIT:
I took the Nvme disk out and put it in a Nvme USB-cabinet. Plugged it in my pc and ran a partiton program. It found errors on the partition and repaired it. Formatted it and mounted it in the Argon case again. Partition looks good in both RaspiOS and Ubuntu.
When Installing I expanded the 512MB partition to all of the remaining disk. Zero left. What I beleive is that the remaining MB shown in PINN is not quite accurate and that the partition was created beyond last sector. The partition program said something about it, that the end sector was wrong and it repaired it.
But the video=HDMI-A-1:1920x1080@60D made the screen go black. Have to start all over. RaspiOS Imager. This time I leave 2MB free when expanding the partition.

But an annoying issue is when the downloads of the OS'es starts, the initiation of the download decides the download speed. Several times I had to shut it down because it states the download time takes XXX hours, 0-0,1MB sec. This happens several times and are totally random. This attempt takes about 1 hour.

Thanks for the additional information.
I managed to replicate this freezing of RaspiOS once only, but when I repeated it, it installed fine. This is very odd, but you've given me some clues that need further investigation.

I would avoid using Gparted with multi-boot as it often changes the disk identifier when resizing partitions, which can cause problems with PARTUUID references.
The Data Partition would have been formatted as ext4 according to its metafiles. Of course you can create your own data partition metafiles that use a different format, or just reformat the partition as exfat from RaspiOS or Ubuntu using mkfs. You should be able to set the size in PINN's installation dialog. But of course, if something is going wrong with the size calculation, this might be a problem. If you leave a few MB, PINN will still allocate this extra space (in theory!). There is a `provision` cmdline option that can be used to reserve some space at the end of the disk. Maybe try this option to provision a few MB? See https://github.com/procount/pinn/blob/m ... ne-options

Landavardir wrote: ↑

Sat May 31, 2025 9:14 am

But the video=HDMI-A-1:1920x1080@60D made the screen go black. Have to start all over.

That is surprising. But rather than start all over, why not just remove that parameter from cmdline.txt? You could always enable SSH before trying such changes in future, then you can get into PINN and edit the file remotely from another computer.

Landavardir wrote: ↑

Sat May 31, 2025 9:14 am

But an annoying issue is when the downloads of the OS'es starts, the initiation of the download decides the download speed. Several times I had to shut it down because it states the download time takes XXX hours, 0-0,1MB sec. This happens several times and are totally random. This attempt takes about 1 hour.

Yes, I often experience this myself. Most of the OSes are stored on Sourceforge which is great because it's Content Delivery Network has many mirrors around the world so in theory it should pick a mirror closest to you geographically to give you a quicker download. Unfortunately, some of their servers are very slow - I guess this is the price you pay for having free storage ;) . At the moment I have no control over which server mirror is chosen, but they have provided an API so I can at least see which mirrors are available. In the future I hope to use this to switch servers when the download speed is unacceptably slow.

In the meantime, if you identify the folder where the OS is stored, you can download it manually from a PC where you can select a mirror manually, and store the files in a folder under /os on a USB stick. PINN can then install the OS from the USB stick. There is a download feature within PINN to do this for you, but again the mirrors are not selectable.

procount wrote: ↑

Sat May 31, 2025 11:32 pm

I would avoid using Gparted with multi-boot as it often changes the disk identifier when resizing partitions, which can cause problems with PARTUUID references.

Yes. I tried Gparted but canceled it as it can't format exfat nor change volume label on an exfat partition. Took the disk out as earlier and tried Diskgenious (free software). It complained about wrong disk identifiers on several partitions. Skipped that one too and used AOMEI Partition Assistant. No complaints about wrong disk identifiers and went on to format to exfat and set the volume label. Booted both OS'es and all is good.

procount wrote: That is surprising. But rather than start all over, why not just remove that parameter from cmdline.txt? You could always enable SSH before trying such changes in future, then you can get into PINN and edit the file remotely from another computer.

Yes I know. But yesterday I had maybe 25 attempts from scratch and I forgot to activate SSH. Started to be a bit cross eyed after many attemps.
One strange behavior in PINN I noticed on this many attempts is that the OS'es on the list changes places. And so do the tabs? The Utility tab went to be the second tab to the first. And sometimes after pressing install the "The install process will begin shortly" takes several minutes, and sometimes a few seconds only. Not a big deal, just an observation.

One suggestion for future PINN version could be to streamline the use of NVMe's as they become more used for booting and disks becomes lager and not to set the space for OS'es only. In my case the exfat partition will be used for the music library with Lyrion music server and accesible with Samba from different devices. It replaces my noisy Synology NAS for that purpose.

INow I've reach my goal so hopefully smooth sailing form here on.

I am currently running PINN on an NVMe SSD on a Raspberry Pi 5 (8GB).

In addition to PINN, LibreELEC and Batocera (in that order) were installed.

Now Batocera is to be replaced by Raspberry Pi OS Lite.

However, the installation using "Replace" fails because the disk space of the partition previously created for Batocera is too small.

I would therefore have liked to repartition.

To be on the safe side, I would have liked to create a backup of the LibreELEC installation beforehand using the backup function integrated in PINN. However, the backup fails (display and control on the Raspberry freezes directly; SSH access is still possible, but no img.gz and tar.xz archives are created).


Unfortunately, the Raspberry is embedded and the SSD is therefore not accessible from the outside.

What would be the recommended procedure for backing up the system, repartitioning the partitions appropriately and finally replacing the Batocera installation with Raspberry Pi OS Lite?

hektor wrote: ↑

Sun Jun 01, 2025 4:15 pm

To be on the safe side, I would have liked to create a backup of the LibreELEC installation beforehand using the backup function integrated in PINN. However, the backup fails (display and control on the Raspberry freezes directly; SSH access is still possible, but no img.gz and tar.xz archives are created).

I just tried 2 backups of a newly installed LibreELEC - one immediately after installing it and a second immediately after booting it for the first time. Both backed up ok without freezing.
Did you just try it the once? Maybe it was another instance of the Pi5 freezing? I've only ever seen that on the initial network connection, but it could happen. Maybe try backing up again?

hektor wrote: ↑

Sun Jun 01, 2025 4:15 pm

What would be the recommended procedure for backing up the system, repartitioning the partitions appropriately and finally replacing the Batocera installation with Raspberry Pi OS Lite?

Like you did, I would try backing up LIbreELEC again, then select that backup plus a new Raspios installation and just install them again as a fresh installation.

procount wrote: ↑

Mon Jun 02, 2025 6:26 pm

Did you just try it the once? Maybe it was another instance of the Pi5 freezing? I've only ever seen that on the initial network connection, but it could happen. Maybe try backing up again?

I must have tried it 10 times already.
Every single time the system froze as described above.
To make sure that it is not a standard behavior and possibly even desired that the system cannot be operated during the backup, but the backup simply lasts very long, I have also tried twice to let the backup run overnight. Both times with the same result as the other attempts.

Did you also use an NVMe SSD during your attempts?
Otherwise, I didn't notice anything special with my setup.

Is there a way to better analyze the misbehavior or a method to make sure the backup works?

I've thought of another approach that might help me get around the problem.

Would it be possible to use a micro SD card with e.g. Rasperry Pi OS on said Raspberry Pi 5 in parallel to the NVMe SSD, then change the boot loader so that it primarily boots from the micro SD, and then access the partitions of the NVMe from "externally"?

What steps would then be necessary to back up the LibreElec installation and partition the SSD so that the Raspberry Pi OS Lite can be run in parallel with LibreELEC under PINN as desired?

hektor wrote: ↑

Mon Jun 02, 2025 6:40 pm

Did you also use an NVMe SSD during your attempts?

Yes.

hektor wrote: ↑

Mon Jun 02, 2025 6:40 pm

Is there a way to better analyze the misbehavior or a method to make sure the backup works?

I am still looking into the backup/restore of LibreELEC. Whilst my backups were created, there was a problem restoring them.

hektor wrote: ↑

Wed Jun 04, 2025 8:41 am

Would it be possible to use a micro SD card with e.g. Rasperry Pi OS on said Raspberry Pi 5 in parallel to the NVMe SSD, then change the boot loader so that it primarily boots from the micro SD, and then access the partitions of the NVMe from "externally"?

Yes, this is possible. If you have the latest bootloader, you can press the space bar at startup to temporarily alter which media to boot from on this occasion (6 for NVME, 4 for USB, 1 for SD card - IIRC)

hektor wrote: ↑

Wed Jun 04, 2025 8:41 am

What steps would then be necessary to back up the LibreElec installation...

Still looking into this issue.

hektor wrote: ↑

Wed Jun 04, 2025 8:41 am

... and partition the SSD so that the Raspberry Pi OS Lite can be run in parallel with LibreELEC under PINN as desired?

Ordinarily, after creating a successful backup of LibreELEC, you would just install the backup with Raspios-lite.
(By "run in parallel" I assume you mean that they can co-exist on the SDD and be selectively booted. They can't actually "run" at the same time without e.g. a hypervisor or virtual machine ;) )
Alternatively, just do a fresh install of LIbreELEC and copy your media in afterwards (?).
There also appears to be a small problem installing Raspios under PINN on an SSD at the moment. I hope to have this resolved soon.

Can you explain what is sticky PINN? I'm interested but pleaseeee helpp meee!!! :?: :roll:

maestro13 wrote: ↑

Wed Jun 04, 2025 12:21 pm

Can you explain what is sticky PINN? I'm interested but pleaseeee helpp meee!!! :?: :roll:

Please see https://github.com/procount/pinn/blob/m ... default-os

Or perhaps you are referring to this thread's title. The "STICKY:" part just means this thread is pinned to the top of the General Discussion section because it is a popular topic that many people might find useful, so it can be easily found.

For more info on PINN, see the links in the first thread of this topic.

maestro13 wrote: ↑

Wed Jun 04, 2025 12:21 pm

Can you explain what is sticky PINN? I'm interested but pleaseeee helpp meee!!! :?: :roll:

There are some threads on the forum that are marked as STICKY, that means they stay at the top of the thread listings (no matter how long it is since the thread got an update). This thread for PINN (which is PINN is Not NOOBS) has that sticky marker.

PINN is an OS loader for Raspberry Pis that allows you to boot one or multiple OSes from one SDCard that's maintained by Procount. It's been around for years. Original as a fork or NOOBS until the RPF folks dropped NOOBS and PINN became completely separate.

Thanks, very helpful

Just installed PINN on my Raspberry Pi 5. Are there supposed to be 2 drives on the desktop (system-boot and writable)? If not, how do I remove them?

I assume you have used PINN to install Raspberry Pi OS and maybe Ubuntu and you are describing the Raspberry Pi OS desktop?

By default, the Raspberry Pi OS file manager will display a drive icon for any additional drives not mentioned in its /etc/fstab file, such as when you plug a USB stick in. In this case it looks like it is detecting your Ubuntu partitions. If you had installed more OSes, those would have been displayed as well.

If you don't want these to be displayed there is an option in the file manager not to display them I think it is under Edit-Preferences-Volume Management.

:D nice

Created a GitHub issue regarding my (initramfs) prompt problems (see latest post of this forum here).

Raspberry Pi OSes have been updated

If you've experienced problems getting RasPiOS Bookworm booting on an nvme drive (and maybe SD cards as well) with PINN like Landavardir posted about above, with it freezing on the splash screen, or stopping around the 4 second mark for the lite version, then please re-install them and try again.

There was an issue with the Raspios disk expansion code that was not detecting the presence of PINN correctly, causing an unnecessary partition resize that failed. I have patched all 6 versions to avoid this problem and bumped their release dates to 08/05/2025 to identify the new versions.

bumped their release dates to 08/05/2025 to identify the new versions.

August 5th?

Or maybe May 8th?

Hmmm.

My posts may be "controversial" and/or out-of-sync with the party line.

Nothing I write should in any way be taken as an official statement by any organization connected with (any branch of) RPi and/or any of its funding sources.

8th May - 1 day after the previous RPL release.

@procount

Apologies if its already posted.
Which github repo file I can look and understand what build version of an OS is going to be installed by PINN?
For eg, for Konstakang lineage os 22 ATV.

sim_tcr wrote: ↑

Tue Jun 10, 2025 8:33 am

@procount

Apologies if its already posted.
Which github repo file I can look and understand what build version of an OS is going to be installed by PINN?
For eg, for Konstakang lineage os 22 ATV.

Whilst I am responsible for most of the OS conversions, some are done by other third parties, so the list is distributed across various repositories.
1. If you are in PINN, hovering your mouse over an OS entry should display the data and version of that OS.
2. You can go to http://pinn.mjh.nz. Select your media, size and RPi model, and it will show the list of suitable OSes along with their version and dates.
3. If you want to piece it together yourself from the original data, start at https://github.com/procount/pinn-os/blo ... _list.json and follow the URL links for information on the OSes of each repository.

Is it correct that bluetooth devices are not supported by PINN's boot selector?

Eamoex wrote: ↑

Mon Jun 23, 2025 7:11 pm

Is it correct that bluetooth devices are not supported by PINN's boot selector?

yes