#317 rhbz#1942443 Login using password failed after upgrade to Fedora 34
Closed 17 days ago by blockerbot. Opened 6 months ago by blockerbot.

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

Current vote summary

Commented but haven't voted yet: coremodule, chrismurphy, adamwill, kparal

The votes have been last counted at 2021-04-23 13:54 UTC and the last processed comment was #comment-729115

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)


Discussed during the 2021-03-29 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as this seems serious, but benzea believes it's the same as #1933520 and should have been fixed already. If it is not, we need to figure out under what circumstances that fix isn't working before we can decide if the impact is wide enough to be a blocker.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-29/f34-blocker-review.2021-03-29-16.00.txt

Given comments 19 and 20, it looks like a local configuration issue.
FinalBlocker -1

@chrismurphy it's not as simple as "local configuration issue". It's more "attempt to fix this does not work in some perfectly legitimate scenarios, like an old install that's been continually upgraded, or an install where the local config was changed outside of authselect in any way at all".

IMO the problem here is that the local config was somehow changed outside of authselect. That might be a Fedora bug, or it might be the user modifying files manually. Regardless, it should never happen. Once it has happened, we are stuck in a state where manual intervention is required to recover.

In that case I'm finalblocker 0, and need more info what the scope of the problem is. If there are cases coming from clean install of Fedora 32+ then I'm inclined to block. If these are older installations that have been upgraded, then I'm inclined to not block and instead recommend a clean install.

AGREED RejectedFinalBlocker
AGREED AcceptedFinalFE

Discussed during the 2021-04-05 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Final)" and an "AcceptedFreezeException (Final)" was made as the consensus was that it's just too narrow in scope to see as a release blocker (we believe it affects systems that started as Fedora 27 or earlier, and systems where nsswitch configuration was changed outside of authselect). It is accepted as a freeze exception.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-04-05/f34-blocker-review.2021-04-05-16.02.txt

The following votes have been closed:

  • Rejected FinalBlocker (+0, 0, -2)
  • Accepted FinalFreezeException (+0, 0, -0)

Given the new information, I am sad to report that I'm

FinalBlocker +1

If this really does affect almost all upgrades, then yeah...

FinalBlocker +1

Hmmm, it seems its going to affect lot of users

FinalBlocker +1

Sigh, I wanted to release next week, but I agree we should fix this first. This issue cannot be addressed with a system update because affected users will be unable to log in to apply the update.

FinalBlocker +1

I'm slightly confused by this. Is everyone voting to just fix the fingerprint issue? In that case we can close the bug, the update got already pushed stable (even though some verification would be nice, I'll try).
Or are people voting for a fix that would reset all authconfig files for people as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1942443#c51 (and I started talking about it in comment 42)?

I think people are voting on the belief the recent discussion means there are still real world cases unfixed by the current update. Is that not correct?

In any case, it seems to me that this could at least be a 0day, since it's an upgrade issue.

I'm slightly confused by this. Is everyone voting to just fix the fingerprint issue? In that case we can close the bug, the update got already pushed stable (even though some verification would be nice, I'll try).

If users can log in, then IMO that is sufficient. The blocker designation is because Fedora is effectively totally busted if you cannot log in to your user account.

Or are people voting for a fix that would reset all authconfig files for people as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1942443#c51 (and I started talking about it in comment 42)?

That seems like the most robust way to fix this issue, but surely it's not required to resolve the blocker issue.

In any case, it seems to me that this could at least be a 0day, since it's an upgrade issue.

Yes, this does not need to be fixed on install media, so it should be a 0day blocker.

Sigh, I wanted to release next week, but I agree we should fix this first. This issue cannot be addressed with a system update because affected users will be unable to log in to apply the update.

So that was incorrect. It can be fixed with an update. We just need to make sure the update is ready.

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

17 days ago

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

Login to comment on this ticket.

Metadata