Add to existing raspian system

[iwl]

Hi, I have a Raspian system with 1GB Fat Boot Partition, Can I add PINN to that system?
Move the existing raspian boot files to some subdir, Copy the PINN Files to the boot partition, change some configs...
May be some insider already know what to look for / do...
Thank You

[iwl]

Does removing runinstaller from recovery.cmdline prevent PINN from changing the SD-Card on first run?

[lurch]

That's technically possible, but unless you really know what you're doing, it's probably easier to just install PINN onto a fresh card and then follow https://github.com/procount/pinn/wiki/How-to-Create-a-Multi-Boot-SD-card-out-of-2-existing-OSes-using-PINN

[iwl]

Copying the PINN Files to the existing Boot Partition and removing runinstaller from recovery.cmdline should already make PINN boot without destroying the existing partitions as far I understood up to now.
Then I need to configure to boot the old existing system from there, but I only found how to boot a partition from there.
At least with a dos partition table, there aren't enough partitions for several systems, so may be booting from a different file / dir is already implemented, but haven't found how to do that.
I just wanna make mirrors from my system partitions before making bigger system changes probably destroying the whole system and don't want to remove the sd card for, just connect and use a usb drive for.
I have downloaded pinn.zip, think the os's there need to be installed first to make a boot config I can analyze...

[lurch]

Then I need to configure to boot the old existing system from there, but I only found how to boot a partition from there.

The way that a Raspberry Pi boots, the Linux kernel is stored on the boot partition. See https://github.com/raspberrypi/noobs/wiki/Standalone-partitioning-explained and https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained for a detailed description.

So unless you come up with some wacky system whereby you modify confg.txt each time you boot (which isn't recommended) there's no way to have the Linux kernels for PINN (recovery.img) and Raspbian (kernel.img) stored on the same partition.

At least with a dos partition table, there aren't enough partitions for several systems

PINN uses logical partitions https://en.wikipedia.org/wiki/Extended_boot_record

so may be booting from a different file / dir is already implemented, but haven't found how to do that.

If you really want to get your hands dirty, then see https://www.raspberrypi.com/documentation/computers/config_txt.html#os_prefix

I just wanna make mirrors from my system partitions before making bigger system changes probably destroying the whole system and don't want to remove the sd card for, just connect and use a usb drive for.

I still don't know what it is you're trying to do, but the FIRST thing you should do is make a backup of your current system. And that can't be done safely from within a running operating system, because there may be several files in use where the changes to those files haven't been written to disk yet, whilst the OS is still running.

[lurch]

I've just remembered that if you're using Raspberry Pi OS, you can use the included SD Card Copier tool to make a backup of your running system (it has a brief description in https://www.raspberrypi.com/news/another-update-raspbian/ ).

[iwl]

Since the recovery seems to have similar files like the main system with different name recovery, you should be able to copy it to the same partition. Your link says it is booted if the main files are not readable, may be with pressing the shift key also.
At least that makes sense, why else the different naming.
BTW why PINN uses the recovery naming being the only system on first partition anyway, booting os from other partition.
I essentially was looking for such a little recovery running in ramdisk, able to copy / backup the clean unmounted root partiton.
That SD card copier tool runs with the system up, so the copy should be a little dirty, while it seems to work for most people.

[lurch]

BTW why PINN uses the recovery naming being the only system on first partition anyway,

It's for "historical reasons" - PINN is a fork of NOOBS, and when NOOBS was first written, things were much simpler than they are now, because there was only a single model of Raspberry Pi. IIRC the only files in the first versions of NOOBS were bootcode.bin, recovery.elf, recovery.img, recovery.cmdline and recovery.rfs - not even a config.txt was needed. Nowadays with dtoverlays, device-specific DTB files, CPU-specific kernels, etc. things are a lot more complex.

I've never actually checked to see what happens if both recovery.elf & recovery.img and also start.elf & kernel.img are all present on the first FAT partition - you're obviously welcome to try it, but don't blame me if it makes your system unbootable 😉

booting os from other partition.

When NOOBS was first written, SD card corruption (resulting in a totally unbootable SD card) was a common complaint - this is the reasoning behind the "NOOBS prime directive" mentioned in https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained . The NOOBS partition never gets written to, so the NOOBS partition can't get corrupted, and your SD card will never become unbootable. But each OS is still able to write to it's own separate boot partition. PINN / NOOBS also allows many different OSes to be installed at once, and this requires the use of different boot partitions, as each OS will have different Linux kernels, different config.txt settings, etc.

[iwl]

Do you know a which Boot Stage the Shift Key is checked?
https://forums.raspberrypi.com/viewtopic.php?t=264710#p1612051
says something about USB-Support at the lower stages, so may be Shift-Control is possible at that stages for choosing between main and recovery.
I don't know if PINN uses the official or some changed binaries for that stages....
BTW PINN build on Raspi 3 still runs ~3h now.

[lurch]

Do you know a which Boot Stage the Shift Key is checked?

After the recovery image (which contains PINN) has booted... https://github.com/procount/pinn/blob/master/recovery/main.cpp#L542
(the recovery.rfs is an initramfs image which runs a binary named recovery which is the actual PINN "application")

BTW PINN build on Raspi 3 still runs ~3h now.

Yes, building PINN directly on a Raspberry Pi will take a loooong time as it uses buildroot, which builds EVERYTHING from source, including a whole set of cross-compilers, the whole of QT, a couple of different Linux kernels, etc. etc.

[iwl]

I've created a dual boot config with a modified pinn that can be copied into an existing raspbian buster boot fat partition and started with reboot '0 tryboot'
I've modified a complete downloaded binary since my build still stuck with error.
I've had to fiddle a lot since the low level boot configuration seems to be inconsistent, things don't work like to expect from documentation.

[lurch]

the low level boot configuration seems to be inconsistent, things don't work like to expect from documentation.

If you're referring to the NOOBS documentation / wiki that I referenced above, then yes that's out of date because NOOBS is now archived and no longer developed.

If you're referring to the documentation at https://www.raspberrypi.com/documentation/ then you can report any problems at https://github.com/raspberrypi/documentation/issues

can be copied into an existing raspbian buster boot fat partition

Raspbian Buster is very old now - Raspberry Pi OS Bullseye and Raspberry Pi OS Bookwom have both been released since then, so Buster might not be getting any security updates (or bug-fixes) any more?

[lurch]

But I'm glad to hear that you've managed to come up with a working solution for what you were trying to do 👍

[procount]

What have you done with the SETTINGS partition (5) that PINN uses when adding PINN to an existing system? I assume that is part of your modifications....?

BTW, future version of PINN (starting with v3.8.9 beta) no longer use the recovery naming system, since this is not supported by the Pi5. So if you are relying on this, you may have to adjust in future, maybe use the os_prefix setting, and/or look at the initramfs and kernel options in config.txt 🤷‍♂️

[lurch]

since this is not supported by the Pi5.

Buster (and Bullseye) aren't supported on the Pi 5 either 🙂

[procount]

Agreed. I only mention the Pi5 as the reason for the name change, but it also applies if the OP wants to install Buster/Bullseye on another model of Pi (e.g. Pi4) using a (user-modified) future version of PINN (>=v3.8.9)

[lurch]

Although I guess theoretically (I've not tested this myself!) if the Pi5 doesn't support the recovery naming system, you could still use the "recovery naming system" for Pis 0-4, and just provide a kernel_2712.img for use by the Pi5 (which will get ignored by other models of Pi) and put any Pi5-specific config.txt options inside the [pi5] conditional filter? Pi5 doesn't need (or look at) bootcode.bin or start.elf as these are contained within the Pi5's EEPROM.

Although of course having one mechanism for Pi5 and another mechanism for everything else might just be too much maintenance-overhead.

Hmmm, although thinking about it a bit more, that might not work as kernel_2712.img requires the use of 16k-pagesize binaries rather than 4k-pagesize binaries, and you probably don't want to include two separate root filesystems!. To use 4k-pagesize binaries on a Pi5 you need to use kernel8.img, and of course that would also get loaded by Pis 3 and 4. What if you renamed kernel8.img to kernel8_pi5.img (so that it gets ignored by Pis 3 and 4) and then add

[pi5]
kernel=kernel8_pi5.img
[all]

in config.txt ? 🤷‍♂️ (This may well be a rabbit-hole that you've already explored 😂 )

[procount]

@lurch - You should try the new 3.8.9 beta :)
I'm using the 6.1 kernel on all models, without the recovery naming, and using kernel8.img for PI3, Pi4 and PI5.
I may drop back to the 5.10 kernel for the arm6 & arm7 kernels if I can't resolve the USB initialisation order /delay.
And I need to understand why the recovery program occasionally locks-up on the PI5 with exactly the same rootfs and kernel8 as a Pi4 that works fine.

[lurch]

You should try the new 3.8.9 beta :)

I would if I had the time, but unfortunately I don't 😕

[procount]

That's why it has taken me 4 months to get this far, too! 😄
We need longer days