Bug 815413 - Preupgrade from F16 to F17 Beta does not regenerate pam.d/system-auth*, causing systemd-loginctl not to know about user sessions, breaking PulseAudio
Summary: Preupgrade from F16 to F17 Beta does not regenerate pam.d/system-auth*, causi...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker, RejectedNTH https://...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-23 15:01 UTC by Eike Hein
Modified: 2013-04-04 01:01 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-30 21:40:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Eike Hein 2012-04-23 15:01:56 UTC
I preupgraded to F17 beta yesterday, from Fedora 16 with updates-testing enabled, and discovered that my sound was no longer working: /proc/asound/cards listed the soundcards, but PulseAudio only made Dummy Output available.

Today with the help of PulseAudio developer Colin Guthrie I found out that the ACLs on my /dev/snd/pcm* did now allow PA access to the sound devices. Further examination lead to systemd-loginctl not listing my session, and the system-auth* files in /etc/pam.d not referencing pam_systemd to cause the right ACLs to be set up.

I then mucked around a little with authconfig-gtk and authconfig, changing a checkbox forth and back and rerunning the latter, to see my system-config* files regenerated. A subsequent tty login did show up in systemd-loginctl, and caused the ACLs to be fixed up, making PA in the existing desktop session (KDE started from kdm) automatically pick up the sound devices.

Bottom line, this seems to be an artifact of the ConsoleKit->systemd transition, and something needs to be changed to cause system-auth* regeneration during the upgrade process to fix it.

Comment 1 Adam Williamson 2012-04-23 15:09:48 UTC
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.

Comment 2 Eike Hein 2012-04-23 15:21:04 UTC
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

Comment 3 Mads Kiilerich 2012-04-23 15:59:55 UTC
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.

Comment 4 Mads Kiilerich 2012-04-23 16:16:58 UTC
Possibly related: Bug 812624 - Gnome Shell constantly using > 100% cpu load

Comment 5 Tim Flink 2012-04-26 20:18:52 UTC
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

Comment 6 Adam Williamson 2012-05-03 18:46:03 UTC
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

Comment 7 cornel panceac 2012-05-05 04:15:04 UTC
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.

Comment 8 Richard Hughes 2012-05-08 11:30:48 UTC
(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.

Comment 9 Adam Williamson 2012-05-08 21:44:17 UTC

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

Comment 10 Adam Williamson 2012-05-08 21:49:20 UTC
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

Comment 11 Adam Williamson 2012-05-08 21:54:32 UTC
hum, actually, seems like my file was already 'post'. I guess something else caused the sound problem.

Comment 12 Adam Williamson 2012-05-08 21:55:50 UTC
how old was your F16 install? I ask because, as I just noticed, mine already had the "-session    optional    pam_systemd.so" line...

Comment 13 Michal Schmidt 2012-05-08 21:56:05 UTC
(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.

Comment 14 Adam Williamson 2012-05-08 22:32:06 UTC
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

Comment 15 Adam Williamson 2012-05-08 22:32:28 UTC
anyone have a guess why systemd %post isn't fixing this up? I can't see anything wrong with its logic.

Comment 16 Michal Schmidt 2012-05-08 23:34:58 UTC
(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?

Comment 17 Michal Schmidt 2012-05-09 08:19:54 UTC
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.

Comment 18 Tomas Mraz 2012-05-09 09:02:48 UTC
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.

Comment 19 Fedora Update System 2012-05-09 09:30:22 UTC
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

Comment 20 Eike Hein 2012-05-09 13:53:14 UTC
> 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.

Comment 21 Adam Williamson 2012-05-09 14:55:48 UTC
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

Comment 22 Michal Schmidt 2012-05-09 15:40:37 UTC
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.

Comment 23 Michal Schmidt 2012-05-09 16:05:50 UTC
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.

Comment 24 Eike Hein 2012-05-09 16:15:32 UTC
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.

Comment 25 Mads Kiilerich 2012-05-09 16:26:25 UTC
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.

Comment 26 Eike Hein 2012-05-09 16:34:37 UTC
(I was logging in from kdm rather than gdm, FWIW.)

Comment 27 Adam Williamson 2012-05-09 16:45:19 UTC
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

Comment 28 Michal Schmidt 2012-05-10 08:05:38 UTC
(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?

Comment 29 Adam Williamson 2012-05-11 03:11:28 UTC
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

Comment 30 Michal Schmidt 2012-05-11 20:10:30 UTC
Added to
https://fedoraproject.org/wiki/Common_F17_bugs#pam-config-upgrade

Comment 31 Adam Williamson 2012-05-12 01:17:19 UTC
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

Comment 32 Michal Schmidt 2012-05-16 13:10:45 UTC
Tomáši, what do you think about comment #28?

Comment 33 Tomas Mraz 2012-05-16 13:37:05 UTC
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.

Comment 34 Tomas Mraz 2012-05-18 06:52:21 UTC
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.

Comment 35 Kamil Páral 2012-05-18 13:36:03 UTC
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.

Comment 36 Eike Hein 2012-05-18 17:12:18 UTC
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.

Comment 37 Tomas Mraz 2012-05-18 19:43:47 UTC
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.

Comment 38 Eike Hein 2012-05-18 20:10:39 UTC
It's currently a symlink; I don't know if it was prior to preupgrade and/or re-running authconfig.

Comment 39 Tim Flink 2012-05-18 21:29:34 UTC
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.

Comment 40 Fedora Update System 2012-05-26 07:55:54 UTC
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.

Comment 41 marc skinner 2012-05-31 20:20:01 UTC
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?

Comment 42 marc skinner 2012-05-31 20:41:21 UTC
i just tried copying my old system-auth.rpmnew over the system-auth-ac, rebooted, still no sound.

Comment 43 marc skinner 2012-05-31 20:50:54 UTC
i'm also logging into KDE with kdm.

Comment 44 Tomas Mraz 2012-05-31 21:13:40 UTC
If you have pam-systemd.so in the /etc/pam.d/system-auth and password-auth then it is unrelated issue.

Comment 45 marc skinner 2012-06-15 20:08:11 UTC
yum erase pulseaudio, reboot, yum -y install pulseaudio fixed the issue for me.

Comment 46 Eric Smith 2012-07-10 23:31:15 UTC
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.

Comment 47 Lennart Poettering 2012-10-30 21:40:06 UTC
Since this bug appears to be a thing of the past I will close this now. If it persists, please reopen.


Note You need to log in before you can comment on or make changes to this bug.