Does anyone try Fedora IoT 33 with Raspberry Pi Compute Module 4? We used Fedora 33: Raw Image for aarch64 with CM4 but the module doesn’t seem to boot.
First, it searches for firmware image but then switches to TFTP boot and looks for filename C0A802C6.img which seems like default file name it reads from EEPROM.
Does anyone encounter this issue ?? any suggestion ??
Look at the attached picture for reference:
Welcome to the forum
TFTP-boot drops in if neither a bootable sdhc-card nor, if availabe, a propperly flashed eMMC is found. Booting Fedora from sdhc-card as well as using USB-boot on a standard raspi 4 or a cm4 development board works out of the box. So if you’re not using an development-board with a card-reader you might want to take a look here for Flashing the Compute Module eMMC.
Also using an sdhc-card first for basic setup and toubleshooting might be the way to go. For firmware and/or bootloader updates you will need an raspberry OS image anyway to play it safe.
Hi Gunther, Thanks for your response. I already tried above methods it didn’t seem to work. I continually get similar error. Changing uboot to latest version worked for me.
Now, I have problem in login into fedora iot. I followed the procedure mention here: https://provision.fedoraproject.org/ own the device, and gave my public key and selected the fedora-installed then initiated run request. How long does it take to copy the keys into my device. Is there any other way like headless start ??
So I guess you followed Setting up a Device with Zezere ?
Copying the keys only takes a few seconds.
Troubleshooting your setup is kinda hard without sufficient information. So apart from the headless setup is the regular setup using access via keyboard and monitor working? Do you have access via console or ssh this way?
Ok, I kinda missed that IOT works a little different. You are supposed to ssh into the device using the keys and set a password from there…
So if supplying the keys doesn’t work and you don’t have root access you could try to re/set the root password in Rescue Mode…
A regular pi4 will refuse to boot up entirely without a monitor connected unless you set hdmi_force_hotplug=1 in the config.txt file located in /boot/efi/ - I’m not sure if the cm4 is affected too since I don’t have access to one ATM. Use a serial console if possible when troubleshooting the headless setup. Anything else is much like reading a crystal ball
Hi Gunter, Thanks for you great suggestion and help.
I precisely followed the device provisioning procedure with no luck: Setting up a Device with Zezere :: Fedora Docs
I try to set ssh key using arm-image installer but it didn’t work:
sudo arm-image-installer --image=/home/…/Fedora-IoT-33-20201215.0.aarch64.raw.xz --media=/dev/sdb --resizefs --addkey=/home/…/.ssh/iot.pub
I tried debugging it using UART but it stuck at:
EFI stub: Booting Linux Kernel…
EFI stub: EFI_RNG_PROTOCOL unavailable, KASLR will be disabled
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map…
then I attached HDMI and keyboard and tried rescue mode, which seems to be the only option for gaining root access but it failed SELinux permissions.
bash-5.0# touch /.autorelabel
touch: setting time of ./autorelabel: No such file or directory
because of this SElinux not relabeling the files and we have no effect on password change.
Is there any fix to this problem?
Let’s try a clean start
You need to do this as root, so take care !
# become root.
# write the image to the cm4. Doublecheck the target device since all data will be lost!
arm-image-installer --image=/path/to/Fedora-IoT-33-20201215.0.aarch64.raw.xz --media=/dev/sdx --resizefs
# We need a place to mount the device.
# Mount the efi partition.
mount /dev/sdx1 /mnt/tmp/
# Force hdmi while headless.
echo "hdmi_force_hotplug=1" >> /mnt/tmp/config.txt
# Mount the root partition.
mount /dev/sdx3 /mnt/tmp/
# Relabel on restart.
# Add public key.
mkdir -m 700 /mnt/tmp/root/.ssh/
cat /path/to/iot.pub > /mnt/tmp/root/.ssh/authorized_keys
chmod 600 /mnt/tmp/root/.ssh/authorized_keys
rm -fr /mnt/tmp/
If it doesn’t work at least you have a clean base to start diggin’
To access via ssh use:
ssh -i /path/to/iot.key firstname.lastname@example.org
Thanks for your detailed answer. I tried above method, It still has same login issue. Even if we copy ssh-keys it has no effect on the system. very strange!
After trying every possible method, I think somehow Fedora developers left SElinux relabeling disabled for Fedora IoT Images. Even if we manually add /.autorelabel it doesn’t have any effect. the file system keeps booting without having to change relabeling.
I tried adding autorelable=1 in rescue mode so it might relabel filesystem but no success.
Is there any new image for fedora iot, more recent image? I highly doubt that current fedora iot 33 supports rpi CM4.
thank for your time and help
Ok, I’m running out of options…
You can turn off selinux for testing by adding enforcing=0 to the kernel cmdline…
This way you will see if selinux is the culprit.
If so you could use:
restorecon -Rv /etc
restorecon -Rv /root
while logged in via rescue mode. Selinux has to be either in enforcing or permissive mode for restorecon to work.
May I ask if there is a special reason to use IOT? For general use and especially debugging the standard Fedora-Minimal-33-1.3.aarch64 might be the better option. You should at least give it a try.
After trying every possible solution, I finally switched to Fedora IoT 34 (pre-released) : Fedora nightly compose finder. It works perfectly! It took just a few seconds to provision the device from zezere. I will further evaluate that nightly build.
We can fairly say that Fedora IoT 33 bootloader is not compatible with the RPI CM4 module. so either switch to fedora iot 34 nightly build or move to ubuntu64.
Fedora IoT its lightweight and uses atomic updates which is very handy when deploying IoT device, it support hybrid image generation using rpm-ostree. These are few reason we wanted to evaluate fedora iot with our new design.
Thanks for your support, I really appreciate it.
Hey @ffwali @gus67
I used this thread as a reference to setup my Raspberry PI CM4 with Fedora IoT 34. Till now everything is smooth and I am able to login Fedora using “root” after provision my device over Zezere platform.
Right now, I am encountering an issue that my serial port (UART i.e. pin 14/15) are not working properly. I have connected the serial to a PC and also connected HDMI to CM4 IO board. I am receiving serial port output i.e. my boot logs onto HDMI but when I see my COM port (COM4 in putty), the output at serial console halts after these lines:
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
Before these lines, I get GRUB menu with Fedora IoT 34 entry in it … but no output after these lines at console but my HDMI screen shows all output of boot-up.
I tried disconnecting HDMI, but no use …
Any help in this regard? How can I solve it ??
P.S: Everything is working flawless with Ubuntu 20 on same CM4 + IO board …
Welcome to the forum
U-boot uses it’s own console-settings, so for the kernel make sure to include
in your kernel cmdline.
Your /etc/default/grub might look like
# Replace x with the console used and adjust the baud-rate to your needs.
GRUB_CMDLINE_LINUX="console=tty1 console=ttySx ... rhgb quiet"
GRUB_SERIAL_COMMAND="serial --unit=x --speed=115200 --word=8 --parity=no --stop=1"
On the kernel cmdline the parameters for the serial-console can be omitted if GRUB_SERIAL_COMMAND is set.
When omitting –word, –parit and –stop, defaults will be used.
When using extlinux.conf on the 32-bit armhfp spin the parameters are needed in the cmdline.
Dont forget to regenerate grub.cfg.
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.