Bug 2264794 - Need to include devcietree files on aarch64 systems iso media
Summary: Need to include devcietree files on aarch64 systems iso media
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: lorax
Version: 40
Hardware: aarch64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker RejectedFreezeException
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-02-19 03:38 UTC by Dennis Gilmore
Modified: 2024-02-26 16:47 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dennis Gilmore 2024-02-19 03:38:38 UTC
Some AArch64 systems require devicetree files to boot. 
looking at a Fedora 40 Workstation image 
/run/media/dennis/Fedora-39-BaseOS-aarch64/images/pxeboot/
initrd.img  vmlinuz

there should be a dtb folder there that includes all of the contents under 
/lib/modules/<kernel version>/dtb/ so that when needed you can add a devicetree option to boot and specify the dtb file needed for the system 

Reproducible: Always

Comment 1 Brian Lane 2024-02-19 16:59:12 UTC
I need more details, or someone with easy access to aarch64 to patch the aarch64.tmpl file at https://github.com/weldr/lorax

It sounds like it needs to:
* copy the `dtb` directory matching the kernel to `images/pxeboot/dtb/`
* add a `devicetree` option to the kernel cmdline. What does this argument need to look like?

Are you sure that changing this isn't going to break other systems that are currently working?

Comment 2 Adam Williamson 2024-02-19 18:26:25 UTC
What images does this affect - particularly with reference to the blocking media list at https://docs.fedoraproject.org/en-US/releases/f40/blocking/ - and what hardware does it affect - particularly with reference to either of the ARM team's "supported hardware" lists, https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices or https://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms (we really need those to be revised and combined)?

Comment 3 Dennis Gilmore 2024-02-19 19:09:38 UTC
By default, we should not add a devicetree option to the iso. The machine where I came on this issue is the Lenovo x13s. After upgrading the NVMe disk and starting with a blank disk I was unable to install Fedora. The system firmware will load the dtb only from the root of the esp partition of the internal NVMe drive. In order to bootstrap the install, if the dtb files were available, I could load one. 

It is probably not a blocker, but it would be nice to have a fix as I am trying to make installing Fedora 40 a viable option for the hardware.

Comment 4 Brian Lane 2024-02-19 21:36:54 UTC
Ok, maybe add a new boot entry with it then? It doesn't seem like it will be of much use to most people if they have to fiddle with the cmdline themselves.

Comment 5 Dennis Gilmore 2024-02-19 23:49:22 UTC
find /boot/dtb-6.8.0-0.rc4.20240212git716f4aaa7b48.35.fc40.aarch64/ -name "*.dtb" |wc -l
830

You would need to add one boot entry per dtb or select a limited number of systems that could use a dtb at boot time. It is an edge use case and with documentation on how to use it when you need it. I think the experience, while not perfect, would be covered. Ideally, the system vendors shipped working ACPI tables or in firmware dtb. if someone was booting the livecd on a u-boot based system to do an install. u-boot should post install load the dtb file by itself from the disk if it is not shipped with u-boot. in this particular case, Lenovo has the firmware set to only load the dtb file from one place. I can not use the raw disk images in my case because I need to encrypt my rootfs, something not possible on the premade images.

Comment 6 Geoffrey Marr 2024-02-20 05:40:54 UTC
Discussed during the 2024-02-19 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as the report does not explain which images or hardware platforms are affected by this, which seems like required information to make a blocker decision.

[0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-02-19/f40-blocker-review.2024-02-19-17.00.log.txt

Comment 7 František Zatloukal 2024-02-26 16:47:36 UTC
Discussed in ticket: https://pagure.io/fedora-qa/blocker-review/issue/1465

The decision to classify this bug as an RejectedFreezeException and RejectedBlocker was made:

"The scope of Hardware this issue affects doesn't apply to any of the "blocking" hardware (at this point, it seems it is just one device). The fix kinda complicated and is of marginal benefit, so rejecting both as blocker and freeze exception. If there is a fix developed during the beta phase, it can be pushed after the beta release and before the final freeze starts."


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