Skip to content

provisioning: include instructions for RPI3 #784

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sbaeurle wants to merge 1 commit into
base: main
Choose a base branch
from
+32 −2
Open

provisioning: include instructions for RPI3 #784

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 32 additions & 2 deletions modules/ROOT/pages/provisioning-raspberry-pi4.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
= Provisioning Fedora CoreOS on the Raspberry Pi 4
= Provisioning Fedora CoreOS on the Raspberry Pi 4/3

Fedora CoreOS produces 64-bit ARM (`aarch64`) artifacts. These images can be used as the Operating System for the Raspberry Pi 4 device. Before trying to get FCOS up and running on your Raspberry Pi 4 you'll want to xref:#_updating_eeprom_on_raspberry_pi_4[Update the EEPROM] to the latest version and choose how you want to boot the Raspberry Pi 4. There are two options:

Expand Down Expand Up @@ -83,6 +83,37 @@ Now take the USB/SD card and attach it to the RPi4 and boot.

TIP: It can take some time to boot, especially if the disk is slow. Be patient. You may not see anything on the screen for 20-30 seconds.

== Adjust Partition Table on Raspberry Pi 3 models

In contrast to RPi4 GPT-compatible EEPROM based bootloader, the RPi3 Chip utilizes a hardcoded boot routine that looks for the first FAT32/FAT16 partition in the MBR of the SD card.
To support Core OS on these devices, on must configure a hybrid MBR enabling the chip to find the boot partition.

[source, bash]
----
sudo gdisk
Copy link
Copy Markdown
Member

@dustymabe dustymabe Jan 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it would be better to script this somehow, like by piping configuration through sfdisk or something?

Then it's less interactive (less chance for things to go wrong).

Copy link
Copy Markdown
Author

@sbaeurle sbaeurle Jan 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll come up with a small script for this


Type device filename, or press <Enter> to exit: /dev/sdX

r - recovery and transformation options
h - make hybrid MBR

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: 2

Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): N

Creating entry for partition #2
Enter an MBR hex code (default EE): 0E
Set the bootable flag? (Y/N): Y

Unused partition space(s) found. Use one to protect more partitions? (Y/N): N

w - write table to disk and exit

Confirm any questions with: Y
----

During the first boot, CoreOS overwrites the partition table, thus requiring a second creation of the hybrid MBR
Copy link
Copy Markdown
Member

@dustymabe dustymabe Jan 16, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. I wouldn't expect this but I guess maybe the growing of the root partition somehow undoes the changes you made.

Can you try booting an instance with an extra kernel parameter to disable the growfs from happening:

[dustymabe@media ~]$ cat /tmp/foo.sh 
#!/bin/bash                                                            
# Create dropin for disabling # ignition-ostree-growfs.service
DROPIN_CRED=$(base64 -w 0 <<EOF
[Service]
ExecStart=
ExecStart=echo "skipping ignition-ostree-growfs.service"
EOF
)
echo "systemd.set_credential_binary=systemd.unit-dropin.ignition-ostree-growfs.service:${DROPIN_CRED}"
[dustymabe@media ~]$ bash /tmp/foo.sh 
systemd.set_credential_binary=systemd.unit-dropin.ignition-ostree-growfs.service:W1NlcnZpY2VdCkV4ZWNTdGFydD0KRXhlY1N0YXJ0PWVjaG8gInNraXBwaW5nIGlnbml0aW9uLW9zdHJlZS1ncm93ZnMuc2VydmljZSIK

So the kernel parameter would then be:

systemd.set_credential_binary=systemd.unit-dropin.ignition-ostree-growfs.service:W1NlcnZpY2VdCkV4ZWNTdGFydD0KRXhlY1N0YXJ0PWVjaG8gInNraXBwaW5nIGlnbml0aW9uLW9zdHJlZS1ncm93ZnMuc2VydmljZSIK

When you do this you should get a CLHM warning about the root filesystem being smaller than recommended:

Fedora CoreOS 43.20260106.dev.0

############################################################################
WARNING: The root filesystem is too small. It is strongly recommended to
allocate at least 8 GiB of space to allow for upgrades. From June 2021, this
condition will trigger a failure in some cases. For more information, see:
https://docs.fedoraproject.org/en-US/fedora-coreos/storage/

You may delete this warning using:
sudo rm /etc/motd.d/60-coreos-rootfs-size.motd
############################################################################

Tracker: https://github.com/coreos/fedora-coreos-tracker
Discuss: https://discussion.fedoraproject.org/tag/coreos

[core@cosa-devsh ~]$


== Installing FCOS and Booting via EDK2

Expand Down Expand Up @@ -121,7 +152,6 @@ Attaching this disk to your Pi4 you can now install FCOS as you would on any bar

NOTE: The separate firmware disk will need to stay attached permanently for future boots to work.


=== EDK2: Combined Fedora CoreOS + EDK2 Firmware Disk

In combined disk mode the EDK2 firmware will live inside the EFI partition of Fedora CoreOS, allowing for a single disk to be used for the EDK2 firmware and FCOS.
Expand Down