#1801 [kernel] Fedora 42 crashes while booting on IPU6 laptops with an ivsc chip | rhbz#2353148
Closed by blockerbot. Opened by blockerbot.

Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2353148 **
Information from BlockerBugs App:
2353148

Current vote summary

Commented but haven't voted yet: lbrabec

The votes have been last counted at 2025-03-24 18:22 UTC and the last processed comment was #comment-962634

To learn how to vote, see:
https://pagure.io/fedora-qa/blocker-review
A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)


[Removed]

[Removed]

Dell laptops are popular and I'd gladly delay the release a bit for them, but given that this affects just 2023 and newer models, it's just a small segment of our user base, and I'm not sure if a full block is warranted here. I'm currently leaning more towards
FinalBlocker -1

I agree.
FinalBlocker -1

I disagree, If this is violating a criterion then it must be granted blocker status. If we are going to waive it due to "just a few hardware over there" rationale, then ok, but first it must be voted as blocker.

FinalBlocker +1

I'm assuming live media doesn't boot, so you can't even get to the installer? That feels pretty hard to fix after release.

FinalBlocker +1

I disagree, If this is violating a criterion then it must be granted blocker status. If we are going to waive it due to "just a few hardware over there" rationale, then ok, but first it must be voted as blocker.

Here's the criterion:
https://fedoraproject.org/wiki/Basic_Release_Criteria#Release-blocking_images_must_boot

See section "System-specific bugs":

System-specific bugs don't necessarily constitute an infringement of this criterion - for instance, if the image fails to boot because of a bug in some specific system's firmware, that is unlikely to constitute a violation unless the system is an extremely popular one. See Blocker_Bug_FAQ for more discussion of this.

It is a firmware bug, in this case, see the description here:
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3741

And then finally this (please read):
https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues?

We can't block the release until it works on all hardware devices in the world. For IoT, we specifically list just a few supported devices. For x86_64, a judgement call is needed.

I'm assuming live media doesn't boot, so you can't even get to the installer? That feels pretty hard to fix after release.

Yes, unfortunately. A workaround would be to a) install F41 and upgrade, b) wait for F43, or c) use unofficial (but regularly updated) F42 respins, once the fixed kernel is stable:
https://dl.fedoraproject.org/pub/alt/live-respins/

Maybe another workaround would be to install from Everything-netinst.
Anyway, I support the non-blocking path with CommonBugs.

FinalBlocker -1

Maybe another workaround would be to install from Everything-netinst.
Anyway, I support the non-blocking path with CommonBugs.

FinalBlocker -1

How does this help? Fedora 42 doesn't even boot, it's a specific combination of GCC and kernel. It don't see a way to workaround it unless you create a custom image with a different kernel.

I don't think we shouldn't released until every hardware runs OK, but I think we should at least try not to ship a release that is completely broken on a very popular line of laptops among Linux users.

FinalBlocker +1

yeah, this is a tricky one. "Dell laptops since 2023" is probably not a very large chunk of users absolutely, but it's going to be enough to show up as a noticeable trend in the feedback at least, and the bug is a pretty bad one (I really need to at least figure out a kernel arg recipe to workaround it, for now there's just no known workaround).

Also, if we don't fix this before release, the official release images will never boot on these systems, and we don't do official respins. It just won't ever be possible to install 42 on the affected systems using an official image, bar kernel arg workarounds. Your only option will be to use an unofficial live respin, AFAICS.

I think this is at least a slam dunk:

FinalFreezeException +1

i'm torn on blocker status.

Discussed during the 2025-03-24 blocker review meeting [1]:

  • AGREED: 2353148 - punt (delay decision) on blocker status, AcceptedFreezeException (Final) - the vote on blocker status for this is split, but there is clear consensus for a freeze exception. As the fix for this is already lined up, we expect it will land before deciding the blocker status becomes crucial

[1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-03-24/f42-blocker-review.2025-03-24-16.02.log.html

AGREED AcceptedFinalFE

The following votes have been closed:

  • Accepted FinalFreezeException (+1, 0, -0)

Metadata Update from @blockerbot:
- Issue status updated to: Closed (was: Open)

Release F42 is no longer tracked by BlockerBugs, closing this ticket.

Log in to comment on this ticket.

Metadata