Bug 2008537

Created attachment 1827042 [details]
5.14.0-60.fc35.aarch64 device-tree

Created attachment 1827043 [details]
5.14.1-300.fc35.aarch64 acpi default

Proposed as a Blocker for 35-final by Fedora user pbrobinson using the blocker tracking app because:

 The move to ACPI by defualt is a RHEL specific patch that shouldn't be applied to Fedora. In Fedora we use the upstream defaults because it causes us less issues because on a lot of devices that present both we want to use the upstream supported means.

Sorry I missed that one, patch reverted and will show up in 5.14.10+ kernels.

Discussed during the 2021-10-04 blocker review meeting: [1]

The decision to classify this bug as an AcceptedFreezeException (and to punt decision on blocker status) was made:

"We don't have a clear vote on whether this is serious enough to constitute a release blocker bug, but we definitely agree it's at least bad enough to grant a freeze exception, and expect the fix will land soon enough as to render the blocker question academic."

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2021-10-04/f35-blocker-review.2021-10-04-16.02.log.html

The problem we have is that the ACPI tables may be quite different to the DT ones, and changing this in an upgrade can break the device because the initrd will be generate based on the current devices loaded/running where on reboot their may be different devices due to prioritising ACPI over DT and the user would end up with a non functional device.

This could affect a number of devices that have DT/ACPI firmware options, such as the RPi running EDK2, and the Jetson Xavier devices supported by Fedora IoT.

It's due to this which is why I believe it's a blocker.

Pasting the following from the blocker review app bug, because why would we have one location for the discussions:

So the reason I feel this is a blocker is that it affects the install media and can't fixed with an update. It can change how the HW looks so and in some cases what HW actually works and we're changing that experience and when run from the installer stuff may not work at all.

FEDORA-2021-79cbbefebe has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-79cbbefebe

FEDORA-2021-9dd76a1ed0 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-9dd76a1ed0

FEDORA-2021-ffda3d6fa1 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ffda3d6fa1

FEDORA-2021-ffda3d6fa1 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ffda3d6fa1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ffda3d6fa1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-9dd76a1ed0 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-9dd76a1ed0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-9dd76a1ed0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-79cbbefebe has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-ffda3d6fa1 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-9dd76a1ed0 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.