Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2269373 ** Information from BlockerBugs App:
The votes have been last counted at 2024-03-14 13:43 UTC and the last processed comment was #comment-900433
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)
BetaBlocker +1
BetaBlocker
FinalBlocker
BetaFE
FinalFE
0Day
PreviousRelease
+1
0
-1
BetaBlocker -1
As described on the ticket, if you skip this it install correctly and boot. It only fails at hash check at windows FMW. But if it boot correctly afterwards, so I think this don't hit the criterion.
This is not a new problem, I saw it even on Fedora many many years back and sometimes it pops up. If it happens more frequently now on Windows, that's unfortunate, but at least in my testing, it didn't happen, so it's not a universal problem. Also, FMW always verifies the image after burning, and so the image was definitely written correctly. Just for some reason (probably something mounted it in the meantime), it changed before booting it in the target computer.
We can talk about FinalBlocker, but it is definitely not a good fit for a BetaBlocker. Furthermore, FMW is completely decoupled from Fedora release, and these issues already happen for F39 images and older, so blocking F40 achieves very little.
My original understanding was that the image was written incorrectly (and therefore could result in an incorrect install). Since it's just the automatic verification, I think it's worth a CommonBugs entry and not blocking.
Metadata Update from @blockerbot: - Issue status updated to: Closed (was: Open)
Release F40 is no longer tracked by BlockerBugs, closing this ticket.
Log in to comment on this ticket.