Bug 815413

Is this also true of DVD upgrades?

Proposing as a Final blocker, per Beta criterion "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria" - the upgraded system can't play audio, so fails that criterion.

I don't know, as I've not done any DVD upgrades.

It seems like the %post of systemd attempts to fix this: http://pkgs.fedoraproject.org/gitweb/?p=systemd.git;a=blob;f=systemd.spec;hb=HEAD#l202

But this didn't work for me. Prior to the authconfig shenannigans I mentioned, my pam.d/system-auth was last written to May 20th 2011. Here's the file:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so try_first_pass nullok
auth        required      pam_deny.so

account     required      pam_unix.so

password    requisite     pam_pwquality.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so


And here is the regenerated file:

[root@ehw1 /etc/pam.d 204K]# cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

I had the same issue on my system that had been yum upgraded (through many releases). Sound worked fine until one week ago. Writing new config with authconfig-tui and restarting fixed it.

Possibly related: Bug 812624 - Gnome Shell constantly using > 100% cpu load

I think that I'm +1 blocker on this (due to the criterion mentioned in c#1) even if it just affects preupgrade. It would be nice to get a little more testing in order to have a better idea of how bad the impact really is, though

Discussed at 2012-05-03 blocker review meeting. Accepted as a blocker per criterion "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria".



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

On a f17 (yum upgraded from f16), if i start in multi-user.target, audio works from tty, but not in X if i run startx from there. I tried in Gnome3-fallback, WindowMaker, XFCE and KDE.

(In reply to comment #2)
> It seems like the %post of systemd attempts to fix this:
> http://pkgs.fedoraproject.org/gitweb/?p=systemd.git;a=blob;f=systemd.spec;hb=HEAD#l202

Yes, this isn't a preupgrade bug at all. Preupgrade doesn't poke around on the system doing this kind of thing before or after the upgrade, it's up to either anaconda to deal with breakage, or (better) the postscripts to fix this per-package on update.

I'll change the component accordingly.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

So I just did a fresh F16 to F17 preupgrade and I believe I've reproduced this. One thing that jumps out at me is that /etc/pam.d/system-auth-ac - before I try to re-generate it manually - contains this line:

-session    optional    pam_systemd.so

I don't know why there's a - prefix to it. I don't think that's valid syntax. But that line will satisfy the systemd %post script's grep and hence, I think, prevent the re-generation from happening. So that might be the problem?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

hum, actually, seems like my file was already 'post'. I guess something else caused the sound problem.

how old was your F16 install? I ask because, as I just noticed, mine already had the "-session    optional    pam_systemd.so" line...

(In reply to comment #10)
> -session    optional    pam_systemd.so
> 
> I don't know why there's a - prefix to it. I don't think that's valid syntax.

It is valid syntax. man pam.d :

      If the type value from the list above is prepended with a - character
      the PAM library will not log to the system log if it is not possible
      to load the module because it is missing in the system.

right. so the line is fine, and my up-to-date f16 install already had it. this whole bug smells like older left-over configs, though you'd still think systemd %post would have fixed it up at some point. 



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

anyone have a guess why systemd %post isn't fixing this up? I can't see anything wrong with its logic.

(In reply to comment #2)
> But this didn't work for me. Prior to the authconfig shenannigans I mentioned,
> my pam.d/system-auth was last written to May 20th 2011. Here's the file:

Was it a regular file or a symlink to system-auth-ac?
Is it a symlink now?

I don't see anything wrong with the scriptlet and I cannot reproduce the problem.
Perhaps Tomáš Mráz, the maintainer of authconfig, has an insight. CC'd.

Unfortunately I have no idea why the systemd %post seems to fail to change this sometimes. What I can do is to add pam_systemd to the pam configuration in the base pam package - it might help in case the original file is unmodified, but it will probably not fix all the cases.

pam-1.1.5-6.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/pam-1.1.5-6.fc17

> how old was your F16 install?

I'm not entirely confident in this memory, but I think I installed it as F15 and preupgraded it to F16.

So, whatever the cause of this, I'm starting to wonder about whether it's really a blocker bug. My 'archive' F15 and F16 installs in virt-manager both have the line in their /etc/pam.d/system-auth files. I suspect you have to go back to pre-systemd days - F14 - to find the case where it's *not* there after a default install. Have both the affected systems been installed since F14 or earlier?

I guess the change in F17 is you now need that line to be present in order to get sound, right? Previously ConsoleKit was handling it.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

It was already important in F16 to have pam_system.so in the PAM config.
(See for instance F16 bug 753160.)

FWIW, a fresh minimal install of *F14* already has the pam_systemd.so line in the PAM config.

Do any of you use any automated tools to deal with *.rpmnew files?
I'm thinking about the possibility that the update of the pam package created system-auth.rpmnew and then someone/something moved it to system-auth without much thinking.

I do use rpmconf, but I usually look at the diffs and don't recall anything relevant. I can't in good conscience rule it out either, though. A chain of events of a PAM upgrade undoing the change done by systemd's %post could have happened I guess.

Do anaconda in a 'booted media' upgrade run authconfig differently than a preupgrade upgrade? Or what can possibly explain that it appears to be 'upgrade only'?

I saw this with yum upgrade to an early f17. It is thus not restricted to preupgrade as the title says - but ok, yum upgrade is unsupported.

The system where I saw the problem was very old and it is very likely that it had some pre-systemd pam config files. That supports that the impact of this bug probably is limited.

It is also possible that some of the pam config files were 'clean' and had been updated when pam was updated. The new pam update would perhaps have fixed it.

Finally, regarding the systemd %post:

It checks system-auth-ac, but I assume that GDM password login (which is what most users use) actually uses password-auth-ac. The scriptlet will thus not fix the case where pam_systemd is in system-auth-ac but is missing from password-auth-ac. It would perhaps be better to check all the 5 (?) files that matter.

authconfig will replace (for example) a system-auth file with a symlink to the new system-auth-ac (and silently remove the old content). It would thus be better to check for pam_systemd in (for example) system-auth than in system-auth-ac.

(I was logging in from kdm rather than gdm, FWIW.)

I'm gonna drop this back to 'proposed blocker', given the new information on how wide the impact is likely to be. I think it's worth discussing it again. It certainly doesn't seem like it really affects all 16->17 upgrades.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #25)
> [...] It would perhaps be better to check all the 5 (?) files that
> matter.
> 
> [...] It would thus be better to check for pam_systemd in (for example)
> system-auth than in system-auth-ac.

These points are worth considering.

I am not very happy that it is the systemd's %post what updates the PAM configs.

Tomáš, wouldn't it be more appropriate to do it in authconfig's scriptlet?

Given our current testing results, I think I'm -1 blocker on this now. We +1ed it on the assumption it hit all installs. It seems pretty clear it doesn't. OOTB F14, F15 *and* F16 installs all seem to have the line already. I think this only affects systems that have been updated through a lot of releases.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Added to
https://fedoraproject.org/wiki/Common_F17_bugs#pam-config-upgrade

Discussed again at 2012-05-11 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-11/f17-final-blocker-review-meeting-5.2012-05-11-17.04.html . With our better understanding of the bug this is now rejected as a blocker, as it seems it will only likely affect some very old installs which have been continually updated, and can be documented for these cases. We should document this issue before release.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Tomáši, what do you think about comment #28?

I think we should sooner or later drop the %post script altogether as the default configuration in the pam package (>= 1.1.5-6) now includes the pam_systemd line.

So I'd say let's drop the script in rawhide.

I'm proposing the pam package update as Nice-to-have bug for the F17 Final release. The package update is trivial - there are no other changes than addition of pam_systemd to the default system PAM configuration files.

I'm somewhat +1 NTH on the basis that it should help some users who upgrade their systems and package maintainer claims the fix is trivial. However, if audio stops working for the user after upgrade, he/she will probably try to fully update his/her system as the first thing, so I have no strong opinion here, using 0-day update should be fine as well.

I might be understanding this wrong, but the pam update wouldn't have actually fixed my system due to rpm config file protection, no? Or does the config file protection compare checksums and overwrite unmodified files? Sorry if this holds up the process; and thanks for all the attention heaped on this by the way.

Was your original system-auth file a symlink to system-auth-ac? If not and the contents were the same as in the original pam package then the upgrade would replace it with the new file. Otherwise just .rpmnew file would be created.

It's currently a symlink; I don't know if it was prior to preupgrade and/or re-running authconfig.

Discussed in the 2012-05-18 blocker bug review meeting. Rejected as NTH for Fedora 17 final because the bug will likely affect only a small number of users who have been upgrading through several releases and there is some question about whether or not the proposed fix would actually fix the bug as written.

pam-1.1.5-6.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

i just did the pre-upgrade this morning.  i have tried running both authconfig-tui - i selected only "use shadow passwords" and "local authorization is sufficient", rebooted no sound.

and then tried "authconfig --updateall", rebooted, no sound.

i have also run and updated my system with latest updates today.

any ideas?

i just tried copying my old system-auth.rpmnew over the system-auth-ac, rebooted, still no sound.

i'm also logging into KDE with kdm.

If you have pam-systemd.so in the /etc/pam.d/system-auth and password-auth then it is unrelated issue.

yum erase pulseaudio, reboot, yum -y install pulseaudio fixed the issue for me.

Upgraded a system from F16 to F17 and had the same symptoms described here.  I checked the pam files and they seemed to have the systemd stuff, but I tried authconfig --updateall anyhow, and it didn't help.  Tried Marc's solution of removing and reinstalling pulseaudio, and that didn't help either.

I think what I've got is a different bug, probably the same as bug #838651.

Since this bug appears to be a thing of the past I will close this now. If it persists, please reopen.