Bug 769570

Could you run alsa-info.sh with --no-upload option, and attach the generated output?

Created attachment 497050 [details]
alsa-info.txt

Here you are.

I see no obvious problem there, so it's likely an issue in PulseAudio.

Try to remove ~/.pulse once and re-login.

No change. I still cannot play any audio.

OK, then this might be rather the device permission.
Check the permission of /dev/snd/* files.  Also, check ACL of these files via "getfacl /dev/snd/*".

ls -l /dev/snd/*
crw-rw---- 1 root audio 116,  6 Jul  2  2012 /dev/snd/controlC0
crw-rw---- 1 root audio 116,  5 Jul  2  2012 /dev/snd/hwC0D0
crw-rw---- 1 root audio 116,  4 Jul  2 09:00 /dev/snd/pcmC0D0c
crw-rw---- 1 root audio 116,  3 Jul  2 09:00 /dev/snd/pcmC0D0p
crw-rw---- 1 root audio 116,  2 Jul  2 09:00 /dev/snd/pcmC0D1p
crw-rw---- 1 root audio 116,  1 Jul  2  2012 /dev/snd/seq
crw-rw---- 1 root audio 116, 33 Jul  2  2012 /dev/snd/timer

# getfacl /dev/snd/*
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/by-path
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

# file: dev/snd/controlC0
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/hwC0D0
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D1p
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# cat /etc/group
audio:x:17:pulse
.
.

Shouldn't be user put into audio group?

No, the permissions should have been adjusted via ACL dynamically.
This worked fine for 12.1, so it must be a regression on 12.2.

Ludwig, any clue about this change?

Well, as I found out only last week acl handling changed silently once again. It's now logind which handles them which means acls likely only work with systemd. Did you boot using sysvinit maybe?

Yes, I did.

I don't want to use systemd at all.

OK, so it's another policy change (aka regression) in udev...

I confirm that ACL isn't set when booted via sysvinit on my system, too.

Unfortunately nothing we can do about anymore. desktop components are more and more reliant on systemd. sysv just cant be used to boot a desktop anymore.

let's use this bug to get an entry into release notes. Something like


sysvinit deprecated
~~~~~~~~~~~~~~~~~~~

Various desktop components depend on services provided by systemd only. So while openSUSE 12.2 still has basic support for booting a system with sysvinit as fallback it's considered deprecated and probably even broken in some regards. If you have any issues with a sysvinit booted system please try systemd before filing bug reports.

Why can't we keep udev-acl and its rule in another package?
sysvinit can take it or depend on it.

well feel free to find a volunteer to do that. Bear in mind that this is just the tip of the iceberg. Another issue I found was udisks depending on logind information. Without systemd udisks keeps asking for the root password for mounting removable media. I guess there are more such rough edges. It's an uphill battle you can't win unless you have plenty of time.

Yeah, I know.  But, when I think of SLE12, I'm not sure whether "forgetting old-and-good days and follow to the new world (dis)order" is our way to go.

Speaking of only this bug: the udev-acl stuff is a pretty easy to pick up again.  Just take udev-acl code from the old udev tarball and build it separately.  I guess an experienced packager could finish it in 10 minutes.

I created a package udev-acl in OBS home:tiwai/udev-acl repo.
This has "Supplements: sysvinit", so that it'll be dragged in when sysvinit is installed.

you may want to match for tag 'uaccess' so you don't need to do your own tagging and udev-acl should do nothing if the system was booted with systemd.

Yes, it's already found in 70-udev-acl.rules.
Actually these are just a copy from udev-173.  Only Makefile is new.

70-udev-acl.rules uses 'udev-acl' as tag

Do you mean to check the tag "uaccess" in udev-acl.rules instead of tagging "udev-acl" again?  Then this won't work if systemd isn't installed, since uaccess.rules belongs to systemd, not to udev.

OTOH, systemd is almost impossible to uninstall nowadays, unfortunately.  So, yet another dependency wouldn't be a big issue...

you cannot uninstall systemd

You still can uninstall systemd, but it'll be a pretty thin system :)

(In reply to comment #13)
> let's use this bug to get an entry into release notes. Something like

I'm all for it (they both are not compatible in any sense and pretending that you could use one or the other as a replacement, will cause trouble).

> sysvinit deprecated
> ~~~~~~~~~~~~~~~~~~~
> 
> Various desktop components depend on services provided by systemd only. So
> while openSUSE 12.2 still has basic support for booting a system with sysvinit
> as fallback it's considered deprecated and probably even broken in some
> regards. If you have any issues with a sysvinit booted system please try
> systemd before filing bug reports.

Here is my version:

  <sect3 id="sec.122.sysv">
   <!-- bnc#769570 -->
   <title>sysvinit Deprecated</title>
   <para>
    Some desktop components depend on services provided by systemd
    only. So while openSUSE 12.2 still has basic support for booting a
    system with sysvinit as fallback, sysvinit nevertheless is
    considered deprecated and probably even faulty or broken in some
    regard. If you have any issues with a sysvinit booted system, use
    systemd before filing bug reports.
   </para>
  </sect3>

There is still this old entry that we'd probably better remove now:

  <sect3 id="sec.121.systemd-sysvinit">
   <!-- bnc#727092 -->
   <title>Booting with systemd or sysvinit</title>

   <para>CHECKIT for 12.2.  Is this entry still required?</para>
   <para>By default, openSUSE now boots using
   <command>systemd</command>.  In case of trouble, you can switch back
   to the old way using <command>sysvinit</command> by pressing the F5
   key on the boot.</para>

   <para>If you want to switch to <command>sysvinit</command>
   permanently, install the <systemitem>sysvinit-init</systemitem>
   package.  To switch back to <command>systemd</command>, reinstall the
   <systemitem>systemd-sysvinit</systemitem> package.</para>
  </sect3>

FWIW, OBS home:tiwai/udev-acl contains the fixed version of udev-acl with the revised rules and some patches.  It shouldn't do harm with systemd, too.

Also, OBS home:tiwai:branches:Base:System/udisks2 contains the package with a fix for sysvinit.  This still works with systemd, too.

udev-acl looks good AFAICT

OK, I created SR to Base:System via SRID 127080.

(In reply to comment #24)
> (In reply to comment #13)

> Here is my version:

Updated version:

  <sect2 id="sec.122.sysv">
   <!-- bnc#769570 -->
   <title>sysvinit Deprecated</title>
   <para>
    Some desktop components depend on services provided by systemd
    only. So while openSUSE 12.2 still has basic support for booting a
    system with sysvinit as fallback, sysvinit nevertheless is
    considered deprecated and probably even faulty or broken in some
    regard. If you have any issues with a sysvinit booted system, use
    systemd before filing bug reports.
   </para>
  </sect2>

> There is still this old entry that we'd probably better remove now:

I shortened it as follows:

  <sect2 id="sec.121.systemd-sysvinit">
   <!-- bnc#727092 -->
   <title>Booting with Deprecated sysvinit</title>

   <para>By default, openSUSE now boots using
   <command>systemd</command>.  In case of trouble, you can try to switch back
   to the deprecated <command>sysvinit</command> way by pressing the F5
   key on the boot.  For more information about limitations when booting
   with sysvinit, see <xref linkend="sec.122.sysv"/>.</para>

  </sect2>

SR done.

Just upgraded from 12.1 (that used sysvinit) to 12.2 using zypper dup, and ran into this very problem. 

Had to manually install udev-acl from OBS home:tiwai/udev-acl repo - it was not automatically picked up by the upgrade.

Yes, the problem isn't fixed at all but just proactively ignored :)
udev-acl package itself is found already in OBS Base:System.

Also you'd need to install the fixed udisk2 package from OBS home:tiwai:branches:Base:System/udisk2.  The SR has been pending over months in a review state.  I copied the package to home:tiwai/udisk2 to be sure.

Takashi, thank you for a prompt response.

What is the URL for Base:System for 12.2? The standard one - http://download.opensuse.org/repositories/Base:/System/openSUSE_12.2/ - does not exist.

The OBS Base:System is published only for FACTORY by some unknown reason.

Base:System is not a backports project, it's staging for Factory. The udisks2 sr is in review state by Vincent, you may want to ping him. Wrt udev-acl you need to submit that package to the target project yourself, it won't happen automatically of course.

(In reply to comment #31)
> Also you'd need to install the fixed udisk2 package from OBS
> home:tiwai:branches:Base:System/udisk2.  The SR has been pending over months in
> a review state.  I copied the package to home:tiwai/udisk2 to be sure.

Sorry, it got pointed out to me today it was waiting for my review -- unfortunately, I missed that :/

Ideally, the patch should use sd_booted(), but udisks2 doesn't link with libsystemd-daemon, so I guess the patch is good enough if used for an update. For a proper fix, using sd_booted() is likely what we should do (and we can do it earlier in the function).

That being said, what I'm missing is a bug upstream. Did you file that?

Created attachment 506916 [details]
Patch for upstream

That would be the patch for upstream.

Didn't find a bug upstream, so I filed https://bugs.freedesktop.org/show_bug.cgi?id=55309.

The sr will go in now.