Bug 2389221 - F43 Branched 20250815 KDE aarch64 will not boot
Summary: F43 Branched 20250815 KDE aarch64 will not boot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bcm283x-firmware
Version: 43
Hardware: aarch64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: BetaBlocker, F43BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2025-08-18 17:03 UTC by Derek Enz
Modified: 2025-08-26 01:26 UTC (History)
13 users (show)

Fixed In Version: bcm283x-firmware-20250813-2.040c0fd.fc43
Clone Of:
Environment:
Last Closed: 2025-08-26 01:26:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Derek Enz 2025-08-18 17:03:53 UTC
Cannot get either the iso or raw KDE aarch64 images to boot on a Rpi4.

The Rpi4 would just loop looking for boot media.

Invalid ELF header: 'start4.elf and Firmware not found were two messages.

The Rpi4 firmware was updated. A fresh F42 KDE aarch64 image works fine.

Reproducible: Always

Steps to Reproduce:
1.Flash SSD
2.Run Rpi4 off SSD with new image.
3.
Actual Results:
Rpi4 just loops looking to boot.

Expected Results:
Should boot to login screen.

Additional Information:
Flash image with the Fedora ARM installer. Usually works for me.

Comment 1 Fedora Blocker Bugs Application 2025-08-18 17:23:30 UTC
Proposed as a Blocker for 43-beta by Fedora user derekenz using the blocker tracking app because:

 Cannot get either the iso or raw KDE aarch64 images to boot on a Rpi4.

The Rpi4 would just loop looking for boot media.

Comment 2 Peter Robinson 2025-08-18 21:56:15 UTC
(In reply to Derek Enz from comment #0)
> Cannot get either the iso or raw KDE aarch64 images to boot on a Rpi4.

Which ISO, live or installer?

> The Rpi4 would just loop looking for boot media.
>
> Invalid ELF header: 'start4.elf and Firmware not found were two messages.

Can you put exact details, was it start4.elf complaining?

Might be corrupt firmware update, but it's the same build that went stable with f42.

Comment 3 Derek Enz 2025-08-18 22:33:57 UTC
(In reply to Peter Robinson from comment #2)
> (In reply to Derek Enz from comment #0)
> > Cannot get either the iso or raw KDE aarch64 images to boot on a Rpi4.
> 
> Which ISO, live or installer?
> 
> > The Rpi4 would just loop looking for boot media.
> >
> > Invalid ELF header: 'start4.elf and Firmware not found were two messages.
> 
> Can you put exact details, was it start4.elf complaining?
> 
> Might be corrupt firmware update, but it's the same build that went stable
> with f42.

Live

Invalid ELF header: 'start4.elf and Firmware not found, were two messages I could read as the Rpi4 was trying to find something to boot from.
Would just keep trying over and over again.

The F42 KDE image would boot fine.

Comment 4 Peter Robinson 2025-08-19 09:34:45 UTC
> Live

That's expected, the Raspberry Pi needs an FAT partition where it can load the early boot firmware from, it can't do that from a .ISO image. That is unsupported.

> The F42 KDE image would boot fine.

As in Fedora-KDE-Desktop-Disk-43-20250815.n.0.aarch64.raw.xz

Comment 5 Derek Enz 2025-08-19 16:15:08 UTC
(In reply to Peter Robinson from comment #4)
> > Live
> 
> That's expected, the Raspberry Pi needs an FAT partition where it can load
> the early boot firmware from, it can't do that from a .ISO image. That is
> unsupported.
> 
> > The F42 KDE image would boot fine.
> 
> As in Fedora-KDE-Desktop-Disk-43-20250815.n.0.aarch64.raw.xz

Nope

Incorrect. The RAW was also giving me the same issue.

I just flashed a ssd with the current f43 KDE aarch64 RAW image. AGAIN the image would not boot. It sits there trying to find the ssd and never does.

Re flashed with the F42 KDE aarch64 RAW image and it boots as expected. I can create an account and login to Fedora KDE.

Comment 6 Neal Gompa 2025-08-21 16:48:47 UTC
In the original post, it's mentioned that this also occurs with the disk images, which have the correct layout to boot.

Comment 7 Peter Robinson 2025-08-21 17:00:56 UTC
(In reply to Neal Gompa from comment #6)
> In the original post, it's mentioned that this also occurs with the disk
> images, which have the correct layout to boot.

TBH that wasn't clear to me hence the question. I will be looking into this but I am currently traveling. It's weird, the same firmware build works on F-42, but doesn't on F-43. I will investigate further when I'm home because low level debug is impossible to do remotely.

Comment 8 Derek Enz 2025-08-21 17:49:49 UTC
(In reply to Peter Robinson from comment #7)
> (In reply to Neal Gompa from comment #6)
> > In the original post, it's mentioned that this also occurs with the disk
> > images, which have the correct layout to boot.
> 
> TBH that wasn't clear to me hence the question. I will be looking into this
> but I am currently traveling. It's weird, the same firmware build works on
> F-42, but doesn't on F-43. I will investigate further when I'm home because
> low level debug is impossible to do remotely.

Hey Peter, apologies for not being as clear as it could of been. Safe travels.

Comment 9 Peter Robinson 2025-08-23 11:30:27 UTC
Starting to test locally. The sha sums of the firmware have changed on the device I just upgraded, where I see the same problem. Now to work out what's happening and why. The same build on f42 works fine so it might be something happening during the build process that's changed on F-43+

Comment 10 Peter Robinson 2025-08-23 12:55:55 UTC
Looks like strip has started affecting the firmware, disabled it and it seems to work now.

Comment 11 Peter Robinson 2025-08-23 13:22:41 UTC
I suspect this is the culprit: https://fedoraproject.org/wiki/Changes/StaticLibraryPreserveDebuginfo

But the new builds are working for me. Will leave this open until I can test fresh images direct from the build system.

Comment 12 Simon de Vlieger 2025-08-25 06:56:07 UTC
`Fedora-KDE-Desktop-Disk-43-20250824.n.0.aarch64.raw.xz` boots correctly on my Raspberry Pi 4B rev 1.2. It contains Peter's strip-fix: https://bodhi.fedoraproject.org/updates/FEDORA-2025-4e807de42b which is likely what solved the issue.

I'm going to needinfo Mark on this because I think he should be aware of this, I don't know if any other firmware(s) have/could break due to the change?

Comment 13 Mark Wielaard 2025-08-25 12:07:16 UTC
(In reply to Simon de Vlieger from comment #12)
> `Fedora-KDE-Desktop-Disk-43-20250824.n.0.aarch64.raw.xz` boots correctly on
> my Raspberry Pi 4B rev 1.2. It contains Peter's strip-fix:
> https://bodhi.fedoraproject.org/updates/FEDORA-2025-4e807de42b which is
> likely what solved the issue.
> 
> I'm going to needinfo Mark on this because I think he should be aware of
> this, I don't know if any other firmware(s) have/could break due to the
> change?

Thanks for including me. Also adding Frank and Nick
since they might know better what could be going on here.

The change that fixed issues is:

commit 54af9c16b0b90d8d5905a49b4e3fb26f49f526fe (origin/f43)
Author: Peter Robinson <pbrobinson>
Date:   Sat Aug 23 13:54:38 2025 +0100

    Disable strip so it doesn't break firmware

diff --git a/bcm283x-firmware.spec b/bcm283x-firmware.spec
index 453bb8e51982..4f94ab2d3b19 100644
--- a/bcm283x-firmware.spec
+++ b/bcm283x-firmware.spec
@@ -1,4 +1,5 @@
 %global debug_package %{nil}
+%global __strip /bin/true
 
 # Tarfile created using git            
 # git clone https://github.com/raspberrypi/firmware.git

__strip is normally set to /usr/bin/strip (the binutils one).

I believe that macro is used in the various brp-strip-(comment-note|static-archive|lto).
But given this package already defines debug_package %{nil} I am not sure when/if these scripts ever run.

Comment 14 Peter Robinson 2025-08-25 12:39:10 UTC
> But given this package already defines debug_package %{nil} I am not sure
> when/if these scripts ever run.

If you look at the various build logs for the package you can see them run:

https://kojipkgs.fedoraproject.org//packages/bcm283x-firmware/20250813/1.040c0fd.fc43/data/logs/aarch64/build.log

https://kojipkgs.fedoraproject.org//packages/bcm283x-firmware/20250514/1.6f2b7e2.fc42/data/logs/aarch64/build.log

F42 you get:

+ /usr/lib/rpm/brp-strip /usr/bin/strip
+ /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
/usr/bin/strip: Unable to recognise the format of the input file `/builddir/build/BUILD/bcm283x-firmware-20250514-build/BUILDROOT/boot/efi/start.elf'
/usr/bin/strip: Unable to recognise the format of the input file `/builddir/build/BUILD/bcm283x-firmware-20250514-build/BUILDROOT/boot/efi/start4.elf'
/usr/bin/strip: Unable to recognise the format of the input file `/builddir/build/BUILD/bcm283x-firmware-20250514-build/BUILDROOT/boot/efi/start4cd.elf'
/usr/bin/strip: Unable to recognise the format of the input file `/builddir/build/BUILD/bcm283x-firmware-20250514-build/BUILDROOT/boot/efi/start4db.elf'
/usr/bin/strip: Unable to recognise the format of the input file `/builddir/build/BUILD/bcm283x-firmware-20250514-build/BUILDROOT/boot/efi/start4x.elf'
/usr/bin/strip: Unable to recognise the format of the input file `/builddir/build/BUILD/bcm283x-firmware-20250514-build/BUILDROOT/boot/efi/start_cd.elf'
/usr/bin/strip: Unable to recognise the format of the input file `/builddir/build/BUILD/bcm283x-firmware-20250514-build/BUILDROOT/boot/efi/start_db.elf'
/usr/bin/strip: Unable to recognise the format of the input file `/builddir/build/BUILD/bcm283x-firmware-20250514-build/BUILDROOT/boot/efi/start_x.elf'
+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip

F43 you just get:
+ /usr/lib/rpm/brp-strip /usr/bin/strip
+ /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip

So clearly something has changed.

Comment 15 Adam Williamson 2025-08-25 15:13:30 UTC
+5 in https://pagure.io/fedora-qa/blocker-review/issue/1874 , marking accepted. Also, since Simon reported the fix working, shall we close this? Or did you want to confirm, Peter?

Comment 16 Peter Robinson 2025-08-25 22:06:11 UTC
I was waiting for Derek the reporter to confirm it was working for him.

Comment 17 Derek Enz 2025-08-26 00:44:11 UTC
(In reply to Peter Robinson from comment #16)
> I was waiting for Derek the reporter to confirm it was working for him.

Ok the  Fedora-KDE-Desktop-Disk-43-20250824.n.0.aarch64.raw.xz build is booting and running as expected on a Rpi4.

Thanks Peter!

Comment 18 Adam Williamson 2025-08-26 01:26:31 UTC
Awesome. Let's close it.


Note You need to log in before you can comment on or make changes to this bug.