This is still happening on every Rawhide / F29 compose, KDE live image installs fail consistently with this error.

That's really weird - my guess would be a change in libpwquality causing this as we have not really touched the pasword checking code in quite a while. But the latest libpwquality build seems to be ~month back:

libpwquality-1.4.0-10.fc29 	fweimer 	2018-07-31 14:06:32

So maybe something libpwquality links against/calls changed, leading to this subtle changine in beheavior. Or maybe we are hitting another case of packages missing from the image, this time KDE live image specific (libpwquality tries to call something that's missing, resulting in the error).

yeah, that's approximately the lines I was thinking down too, but hadn't got any further with it :/ I'm hoping https://bugzilla.redhat.com/show_bug.cgi?id=1618794 gets fixed soon, then we'll know whether it's happening to Workstation lives too. I guess I could test it *manually*, man, crazy idea :P

Adam - not sure if this is related or not, but at work we're finding that if we image a machine with Fedora 28 and enable LUKS encryption, depending on whether we enable updates or not the following happens:

- if updates is enabled, `sudo cryptsetup luksAddKey /dev/nvme0n1p3` would fail with "Cannot check password quality: bad integer value of setting - minlen"
- if updates are not enabled during install (so these are the stock Fedora 28 packages from the release date) this works

We only notice this on Wednesday; granted we don't necessarily image Fedora every day so this might be off by a couple of days

There are no libpwquality update for F28 matching that time period though; the last update was 5 months ago:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-00c5193ae8

cryptsetup has a more recent update but it also landed 2 weeks ago:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-29d55e19b3

It certainly *feels* related somehow, but I have to admit I don't quite grok the linkage yet :( This is very odd.

So, from testing of today's F29 nightly, it seems this really is only happening on the KDE live. It does not happen on the Workstation live; the Workstation live install test fails, but later, after install is complete, it doesn't hit this bug.

(In reply to Adam Williamson from comment #6)
> So, from testing of today's F29 nightly, it seems this really is only
> happening on the KDE live. It does not happen on the Workstation live; the
> Workstation live install test fails, but later, after install is complete,
> it doesn't hit this bug.

So maybe KDe has some different/broken password quality standards and libpwquality reads that and produces the error ? Or it could still be some missing packages due to conflict that happen on the KDE Live and not elsewhere.

Adding libpwquality maintainer to CC in case he has some ideas what could be causing this.

In any case, comment 4 seems to indicate this is indeed not an Anaconda specific case, rather an issue with the tooling both Anaconda and cryptsetup use for checking password quality.

Could we find out what are the contents of /еtc/security/pwquality.conf at the time the error message appears?

Or if anaconda sets non-default path to libpwquality settings, what is the contents of that file?

This bug has creeped into the F28 respin media... all desktop flavors.

oh, wait, I know why it didn't happen on Workstation, now I think of it - Workstation live is customized to not *offer* root password setting during install. So of course openQA doesn't do it. So the bug may not really be KDE-specific indeed. I could check an Xfce Rawhide live, I guess.

Trying to repro the Fedora 28 cryptsetup issue on VMs now

Created attachment 1479108 [details]
/etc/security/pwquality.conf.d/10-authconfig-pwquality.conf showing up on netinstall with updates

This might be the culprit: there's a file /etc/security/pwquality.conf.d/10-authconfig-pwquality.conf that is not owned by any package, and is not present if I netinstall Fedora 28 without enabling updates

$ rpm -qf /etc/security/pwquality.conf.d/10-authconfig-pwquality.conf
file /etc/security/pwquality.conf.d/10-authconfig-pwquality.conf is not owned by any package
$ sudo mv /etc/security/pwquality.conf.d/10-authconfig-pwquality.conf /tmp/
$ sudo cryptsetup luksAddKey /dev/sda3
Enter any existing passphrase:
Enter new passphrase for key slot:
Verify passphrase:
$ sudo mv /tmp/10-authconfig-pwquality.conf /etc/security/pwquality.conf.d/
$ sudo cryptsetup luksAddKey /dev/sda3
Enter any existing passphrase:
Enter new passphrase for key slot:
Verify passphrase:
Cannot check password quality: Bad integer value of setting - minlen

$ cat /etc/security/pwquality.conf.d/10-authconfig-pwquality.conf
minlen=
minclass=
maxrepeat=
maxclassrepeat=
lcredit=0
ucredit=0
dcredit=0
ocredit=0

Hey, great catch! I just checked: that file is indeed present on the affected KDE live images too, with the same contents, and it seems like removing it before running the installer prevents the bug from happening.

So now we just need to figure out what package is creating that rogue file. It broke between 20180813.n.0 and 20180817.n.1 , so it's most likely a package that changed during that time...and also changed recently in F28 updates. That should help narrow it down a bit. Also, thinking about it, it should most likely be a package that's included in KDE live images, but not in the installer environment...

https://paste.fedoraproject.org/paste/82yK1XBjcakHphRQvPtGRw is the diff between the packages in the 0813.n.0 KDE live image (where this did not happen) and the 0817.n.1 KDE live image (where it did), we're likely looking at one of those as the culprit.

I am going to  guess that this might be a result of  https://github.com/pbrezina/authselect/commit/14c4653559a294fe114a773355fa3ef3dbdac326

Yes, the file is created by authselect and it is broken. All integer settings need to have an integer value or not be present at all if pwquality default is supposed to be used.

https://github.com/pbrezina/authselect/pull/78 should fix this. I'll see if I can test it.

Also, shouldn't the package own/ghost this file? It seems wrong for it to be on the filesystem with absolutely no indication of where it came from...

Proposing as at least a freeze exception issue for Beta, since Beta is frozen now. Not sure if we want to consider it a blocker.

This file is created through authselect-authconfig compat tool via an authconfig call. I will fix this and provide new build soon. 

If I understood the description correctly, this bug affects only LIVE images. All packages that depends on authconfig were switched to authselect in F28, including Anaconda. What calls authconfig in live image?

We don't really know that the bug only affects live images - we only know that it only *breaks the installer* on live images. This is likely because authselect isn't actually installed into the non-live installer environment.

I haven't checked if the problematic file is present *in the installed system* after an install from a non-live installer, yet.

At work we don't use the live image - we do a fully-automated install via Kickstart, and those are affected as well.

(In reply to Michel Alexandre Salim from comment #23)
> At work we don't use the live image - we do a fully-automated install via
> Kickstart, and those are affected as well.

Interesting! Can you be more specific ?
- which Fedora version (F28/F29/Rawhide ?)
- what do you have in kickstart (auth/authselect ?)
- or something that uses authconfig/authselect in %post ?
- what exact failure do you get ?

(we don't check the quality of passwords supplied via kickstart so libpwquality should not be involved in this case)

This bug, which does indeed put the mentioned file on the filesystem and it is there post install... is also the cause of this bug:

gnome-initial-setup runs but doesn't present dialogs for root / user account creation
https://bugzilla.redhat.com/show_bug.cgi?id=1622705

Since I knew what file to check, I used virt-edit to zero out the contents of /etc/security/pwquality.conf.d/10-authconfig-pwquality.conf from the VM disk image and then booted... and gnome-initial-setup ran, allowed me to create an account and set the password... and the system was working.

I don't recall it asking me if I wanted to set a root password, but maybe it wasn't supposed to to begin with.  I'm not a frequent GNOME installer / user.

Right, g-i-s should only prompt for a user account and password. That user is automatically made an admin (i.e. can sudo).

For now I'm going ahead and doing builds for Rawhide and F29 (and an update for F29) with my PR backported, as this is a bad bug and it'd be really useful to get composes that aren't affected by it. Of course Pavel may tweak the solution or use a different one and then replace my package later.

authselect-1.0-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fb80a3baee

I've switched the proposal for this to Beta blocker, as if it does break g-i-s, that means you won't be able to get a working Workstation live install at all; you won't be able to create a user account.

+1 blocker

+1 Blocker

That's +3, marking as accepted.

I can not reproduce the issue through pam_pwquality. If the configuration of libpwquality is bad, I would expected that it would not allow me to change password. And yet it seems it uses default setting for checks.

$ rpm -q libpwquality
libpwquality-1.4.0-7.fc28.x86_64
$ cat /etc/security/pwquality.conf
... default file, all lines commented out
$ cat /etc/security/pwquality.conf.d/10-authconfig-pwquality.conf
minlen=
minclass=
maxrepeat=
maxclassrepeat=
lcredit=0
ucredit=0
dcredit=0
ocredit=0

$ passwd
Changing password for user vagrant.
Current password: 
New password: 
BAD PASSWORD: The password is shorter than 8 characters
passwd: Authentication token manipulation error

$ passwd
Changing password for user vagrant.
Current password: 
New password: 
BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word
passwd: Authentication token manipulation error

$ passwd
Changing password for user vagrant.
Current password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.

I suppose pam_pwquality ignores this error from libpwquality?

Anyway, I will extend the patch a little bit so this file is not even written if no pwquality options were set.

This issue happens only if authconfig command is called since we implemented a simple compat tool (authselect-compat package) to provide minimum level of compatibility (do not break kickstarts and allow authentication with given sources) with authconfig. Previous version of the compat tool did not support pwquality related options.

Users can still keep authconfig in their kickstarts although there is a deprecation warning. But it should not be used by Fedora installation itself. Do we know what part of the installation calls authconfig? Does it come from custom kickstart of from elsewhere?

I don't know. All *I* know for sure at this point is that it is getting run during generation of the KDE live image at least. That doesn't mean anaconda is doing it; any scriptlet for any package in the KDE live image could be running it.

authselect-1.0-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fb80a3baee

authselect-1.0-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

*** Bug 1623939 has been marked as a duplicate of this bug. ***

(In reply to Martin Kolman from comment #24)
> (In reply to Michel Alexandre Salim from comment #23)
> > At work we don't use the live image - we do a fully-automated install via
> > Kickstart, and those are affected as well.
> 
> Interesting! Can you be more specific ?
> - which Fedora version (F28/F29/Rawhide ?)
> - what do you have in kickstart (auth/authselect ?)
> - or something that uses authconfig/authselect in %post ?
> - what exact failure do you get ?
> 
> (we don't check the quality of passwords supplied via kickstart so
> libpwquality should not be involved in this case)


- We use Fedora 28
- We have auth --useshadow --passalgo=sha512
- We enable LUKS (initially with a preassigned password)
- installation itself proceeds fine. machines boot as a generic 'fedora' user, and the employee that receives the laptop then run a script to customize their machine, which among others, add the user's password then disable the initial LUKS passphrase keyslot

It's the last step that fails because authconfig shipped the bad config file.

Sorry for reopening this, but should we push an update for Fedora 28 as well? I'll be happy to test the update (or even build it myself).

I opened a new PR [1] which builds up on Adam's patches and improve few more things. Here is a scratch build for F29 [2] if there is anyone willing to test it. Configuration for pwquality should be automatically fixed during upgrade.

[1] https://github.com/pbrezina/authselect/pull/79
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=29484777

I didn't send an update for F28 mainly as the worst impact seemed to be on the live images, and F28 is already released, and I expected Pavel to want to tweak the patch a bit (as he did). But we should definitely do one, yes. Thanks for the refinements, Pavel, I'll try to test them (especially the update-from-broken-build case).

As mentioned in comment #25, this bug does affect F28 post-GA media... aka the Fedora Respin SIG's media... and the fix should be applied to F28 unless you are happy breaking the respins.  All DE's anaconda have a yellow-bar warning about the password integer and have to click [Done] twice.  The Workstation respin has a failed gnome-initial-setup... so no way to set a password or create an account and the install is unusable.

We could fix it ourselves by adding something to the kickstart #post that deletes the file in question... I think that would work but I haven't tested it.

This screencast that is 6:47 in length shows that the fix is also needed in F28... although since it's recording Ben Williams said that he tested removing the file post-install (by booting with "rw init=/bin/sh") and that, "i removed the file and it hosed it".  In the video I just remove the contents of the file and that works.

https://www.montanalinux.org/files/videos/respin-problem-20180904.mp4

I reopened this bug since Adam set the version to F28 where the fix is not available. I will shortly push my patches there, once it get some feedback I will push them to F29 and rawhide which already contains Adam's fix.

authselect-1.0-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-502563d217

authselect-1.0-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-502563d217

authselect-1.0-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days