Boot into raw OSes with raw boot partition (e.g. WoR)

[strolch101]

Hello,

I am trying to get Windows on Raspberry Pi (WoR) to boot along with other OSes on RPi4. Refering to this Github-Repo , which I was able to apply, it seems to be somewhat possible. However, I would like to get over the limitation of an exclusive drive for the OS in question.

As far as I understand, which is most likely wrong, this is just tricking PINN to see the OS as installed and PINN - not knowing what to do with this - just falls back into leaving the Pi alone with whatever it can natively boot, leading to plain recognition of a bootable USB drive (possibly with correct label according to partitions.json). Now I was wondering whether it might be possible to teach PINN to boot OSes which are "deaf" to PINN and vice versa.

The idea is placing the raw boot partition and the raw system partition at the exact position they themselves assume to be i.e boot beginning at sector x, system beginning at sector y and just leave them alone from the perspective of PINN. I even have PARTUUIDs and the separate partition images. The only problem which might probably occur is the different MBR as seen from the raw system. However, I would like to gamble on maybe it doesn't matter if the modified multi-system MBR "shows respect" to these positions.

Now my question is basically: How are the chances, to make this work as far as PINN is concerned. I know this might be dependent on how WoR looks at this. But let's assume it is just PINN: Is it capable to essentially boot something it doesn't know and leave it unmanaged alongside managed systems? If not, what is needed to accomplish that? Please don't bother too much about WoR. I know the community hates Windows - especially on ARM - or will be telling me to just switch SD-cards/drives. But this might be even useful for any system, able to boot on the Pi but just unknown or inexplicable to PINN.

Thank you in advance. Best regards.

[paulwratt]

you should already be able to do this, that is in essense what RISCOS does (hog specific locations).

my feeling is you didn't go through all the docs tho as "modified multi-system MBR" does not sound right, especially with WoR (which requires GPT + UEFI), thats not how PINN (or NOOBS) works.

I would say that if you set WoR up manually as the 1st OS on a PINN drive, with the correct .json, you should easily be able to add other OS's to the same drive, but that "PINN would still have to come first".

Theoretically it would be possible to "inject" WoR (any) partirions into a PINN setup, by masking partitions (on a non-PINN drive) in such a way as the "OS only gets installed to a specific partitions", which can then be copied to a PINN drive, along with manual .json fixes.

If there is an Ask here, then I would say "Can PINN import an OS from another drive?".

If you are wanting to move a WoR (or any) installation, this could probably be done with a second install of the same OS, and knowing exactly what to change after that OS has been moved.

[procount]

There are a few clarifications needed here.

1. PINN does not actually boot anything. It has a boot-selection dialog to allow the choice of which OS is to be booted, but then it tells the firmware to boot the OS on that particular partition, but it must be on the same drive.
2. In order for PINN to be used as an OS selector, it must be the first bootable partition on a drive, which is probably why WoR needs to be on a separate drive.
3. As an OS installer, PINN requires the drive to be MBR and carves up the partitions in a particular way. It has no notion of GPT and cannot create GPT partitioned drives.
4. As an OS boot selector, it may work on GPT (maybe requiring a hybrid GPT/MBR format), since the latest firmware can boot GPT drives, but they would have to be created manually.
5. For a split SD/USB hybrid solution, PINN partitions the USB as a PINN drive first otherwise it will not recognise it as a target. So you cannot use PINN to install additional OSes onto a USB drive with WoR on it. You'd have to essentially repeat the same technique (as WoR does) for all other OSes and manually partition and install them.
6. Often, the hardest thing about getting an OS to multiboot is to actually get it to recognise the new location of its partitions. Any OS that requires its partitions to be on specific partition numbers, or having specific partition Labels, instantly becomes harder to multi-boot. Similarly anything that uses UBoot needs to have that stripped out (because it hardcodes the use of partition 1).

So in summary, you could probably use PINN as a boot selector, but not as an OS installer. The OSes would have to be installed or copied into their own manually created partitions and /settings/installed_os.json updated to reflect what is there. You may be able to use the fixup function to adapt the OSes to their new locations according to installed_os.json, but this will depend on how the partitions need to be referenced. Be prepared for some manual work because PINN was not designed for this.

[strolch101]

"modified multi-system MBR" does not sound right, especially with WoR (which requires GPT + UEFI), thats not how PINN (or NOOBS) works.

WoR let's you choose between MBR and GPT Version. I have the MBR Version.

you should easily be able to add other OS's to the same drive, but that "PINN would still have to come first".

Setup is PINN on SD-Card and the OSes on USB-SSD. SD boots first. My first attempts failed. I will elaborate on this if I have the feeling I tried hard enough and can address a particular problem reduced to it's bottom line.

Theoretically it would be possible to "inject" WoR (any) partirions into a PINN setup, by masking partitions (on a non-PINN drive) in such a way as the "OS only gets installed to a specific partitions", which can then be copied to a PINN drive, along with manual .json fixes.

Apart from the "masking" in particular this approach seems to match what I actually did. WoR was installed on an 32 GB USB-Stick. In order to benefit from higher speeds I created an image of this Stick and put it onto a much bigger SSD. However, the SSD is supposed to hold all OSes at the end and not only Windows. Which is why I made the partition images after install.

If there is an Ask here, then I would say "Can PINN import an OS from another drive?".

Well, if you consider telling PINN there is no need for an explicit installation anymore as "import" - then yes. I cannot "install" WoR. I just can use the already-set-up partitions.

If you are wanting to move a WoR (or any) installation, this could probably be done with a second install of the same OS

It's not necessarily move the OS. Just boot it alongside other OSes on the same drive.

and knowing exactly what to change after the OS has been moved

I am trying to circumvent exactly this

[lurch]

You may find the info in these wiki articles helpful: https://github.com/raspberrypi/noobs/wiki/Standalone-partitioning-explained https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained

PINN does not actually boot anything. It has a boot-selection dialog to allow the choice of which OS is to be booted, but then it tells the firmware to boot the OS on that particular partition, but it must be on the same drive.

Just to elaborate on this slightly... this is a firmware restriction, not a PINN restriction. I've not done any USB-booting experimentation myself (so apologies for any mistakes I might write), but the way I think it works (with some simplification) is:

• There's a special register in the SoC (PM_RSTS) which can store a very small amount of information that survives a reset. The RPi uses this to change which partition it boots from (but note that this is only the "partition number" and not the "partition device).
• At power-on, the PM_RSTS defaults to 0.
• The RPi firmware (bootloader) tries to boot from partition 0 on the SD card (i.e. the first partition) which must be FAT-formatted.
• If this fails, it then tries to boot from partition 0 of a USB drive (i.e. the first partition) which must be FAT-formatted.
• If PINN is installed, and used to select a different OS to boot, this works by setting the desired partition number in PM_RSTS and rebooting the RPi.

So for the sake of the first example, let's assume that PINN is installed onto the first partition of an SD card, and Raspberry Pi OS has been installed by PINN, and the RPiOS boot partition (which must also be FAT-formatted) ends up on the 5th partition of the same SD card.

1. Power on the RPi, PM_RSTS is 0.
2. The RPi tries to boot from the first partition on the SD card.
3. This works, and PINN loads.
4. The user tells PINN they want to boot RPiOS.
5. PINN sets PM_RSTS to 4, and reboots the RPi.
6. The RPi tries to boot from the fifth partition on the SD card.
7. This works, and RPiOS boots (and PM_RSTS gets reset back to 0, so the next time the RPi reboots it loads PINN again).

In the second example, let's assume that there's no SD card inserted, and that PINN is installed onto the first partition of a USB drive, and Raspberry Pi OS has been installed by PINN, and the RPiOS boot partition ends up on the 5th partition of the same USB drive.

1. Power on the RPi, PM_RSTS is 0.
2. The RPi tries to boot from the first partition of the SD card.
3. But this fails (because there's no SD card inserted), so the RPi tries to boot from the first partition on the USB drive.
4. This works, and PINN loads.
5. The user tells PINN they want to boot RPiOS.
6. PINN sets PM_RSTS to 4, and reboots the RPi.
7. The RPi tries to boot from the fifth partition on the SD card.
8. But this fails (because there's no SD card inserted), so the RPi tries to boot from the fifth partition of the USB drive.
9. This works, and RPiOS boots (and PM_RSTS gets reset back to 0, so the next time the RPi reboots it loads PINN again).

If there's both an SD card and a USB drive inserted, then the RPi bootloader will always boot from the SD card (and effectively ignore the USB drive). EDIT: In a "split SD/USB hybrid solution" the RPiOS boot partition still needs to be on the SD card, but it's possible to have the RPiOS root partition on the USB drive, by modifying the cmdline.txt file on the RPiOS boot partition as necessary (so that Linux knows where to find the root partition). But note that this is a "Linux kernel thing" and not a "RPi firmware thing".

(And I've never looked at WoR / Android / uboot / etc. myself, so I've no idea how they work or are partitioned.)

[paulwratt]

Hmmm... @lurch that last example of yours spells out a solution to multi-drive boot of PINN - I wounder how this can be manipulated, and weather it would work on a 3rd device in the "lookup-chain".

Without getting into "PINN installing on various devices at the same time", I believe this could be manipulated so PINN can boot multiple OS on various different devices based on the fact the RPi looks for a bootable partition. I believe there are some other threads discussing this, and no real solution being offered.

Is anyone up for "a play test" (presuming that last example is acurate as to how the boot process will operate)?

If it works, maybe a readme example setup could be added, of how to use PINN as a multi-drive boot manager ..

[lurch]

I wounder how this can be manipulated, and weather it would work on a 3rd device in the "lookup-chain".

The more you get into "tweaking the edge cases", the more likely it is that things will suddenly stop working when you make an unrelated change :wink: But if you want to have a play yourself, no-one's stopping you.... (I don't have the time for that myself)

(presuming that last example is acurate as to how the boot process will operate)

As I said, it's just how I think things work, and may not be entirely accurate? :shrug: And of course things get even more complicated when you start playing around with the BOOT_ORDER stuff on the Pi4 (which is also something I've not yet done myself). https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#BOOT_ORDER

[paulwratt]

I might be able to test this in a week or so, I have some sd-cards coming, and a spare 4G RPi (hopefully the mini-HDMI is still working - physically), otherwise I might be able to test it with a RPi3B+