oem-config created users are not in audio or video group

Bug #669219 reported by Matt Sealey
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Genesi EfikaMX Support Project
Incomplete
Undecided
Matt Sealey
oem-config
Invalid
Undecided
Unassigned
ubiquity (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Users created by oem-config are created but are not added to the same users as the installer creates users.

Process: installing an oem-config enabled system with the "oem" user works fine, but when oem-config-gtk runs on "first boot", a new user is created. This user is not in the audio, video or printing groups. Thus, no webcam, audio playback or printing can be done by the only user on the system without manual configuration with

sudo gpasswd -a myusername {video,audio,lpadmin}

or using the Users and Groups editor (Advanced Settings, authenticate gksudo, User Privileges tab...)

Matt Sealey (mwsealey)
Changed in efikamx:
assignee: nobody → Matt Sealey (mwsealey)
status: New → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote : Re: [Bug 669219] [NEW] oem-config created users are not in audio or video group

(Please note that the oem-config upstream project is not used for bug
reporting, and that oem-config has been merged into ubiquity. I've
moved your bug to the ubiquity package on Ubuntu.)

They aren't supposed to be in the audio or video groups any more, and
the installer does not do this by default. Your audio and video
problems are not related to the installer.

user-setup (1.20ubuntu3) intrepid; urgency=low

  * debian/user-setup-udeb.templates: Drop the initial user from some groups
    which have better dynamic replacements, in an effort to reduce the misuse
    of groups for assigning privileges:
    - audio, video, floppy: Hal assigns ACLs for local foreground console
      users; remote users should not have these. 'cdrom' has to stay for
      apt-cdrom (Debian #464899), 'plugdev' has to stay for static mountpoints
      created by the installer.
    - dip: Not used anywhere in Ubuntu.
    See intrepid-device-permissions spec.

 -- Martin Pitt <email address hidden> Mon, 21 Jul 2008 16:10:17 +0200

Note that, since that changelog entry was written, the responsibility
for assigning ACLs has been moved to udev. See e.g.
/lib/udev/rules.d/70-acl.rules. You'll need to have ConsoleKit working
as well.

Users created by oem-config should still be in the lpadmin group. If
this isn't happening, please provide debugging logs.

Changed in oem-config:
status: New → Invalid
Revision history for this message
Matt Sealey (mwsealey) wrote :

Okay it is true that users are in lpadmin. My mistake.

As for audio and video groups, udev must not be working on ARM picking up "local foreground console users" since webcam and audio simply do not work without adding users to those groups. The previous explanation for the bug was that "pulseaudio handles this now", which is patently untrue.

What exactly are we supposed to be looking at to fix, here, that is the question...

Revision history for this message
Oliver Grawert (ogra) wrote :

audio and console kit works fine in the supported boards we have in ubuntu.
it is usually a matter of having the alsa/ASoC drivers set up properly to make pulse see them. in any case "pulseaudio handles this now" is true in the way that "if your alsa is properly working" it will handle it fine.

make sure your kernel names devices properly for video and audio and sends the proper uevents so udev can pick them up (often devices dont send uevents because the drivers are not properly integrated in the kernel but just added blindly as platform devices in a side tree)

Revision history for this message
Matt Sealey (mwsealey) wrote :

hrw just had a problem with this on his custom built kernel and solved it by loading the module.

I assume then, that udev has to see a plug event from the kernel audio module being loaded or it will not set the ACLs on it?

This does not explain the video not working: the Smartbook has a USB UVC webcam, that said it is always turned on and plugged in as a built-in device.

Is this because these modules are either loaded before udev runs or basically present before udev runs? Do we need USB as a module to make this work and push it all down to automagic probing of devices?

Revision history for this message
Matt Sealey (mwsealey) wrote :

Should also say in our kernel and the last Lucid Ubuntu kernel audio was built-in so it would have suffered the same effect.

Revision history for this message
Oliver Grawert (ogra) wrote :

wrt hrw's prob, the module should auto load if the hardware is present i would take a look why thats not happening (or was it deliberately blacklisted ?)

the kernel should send uevents no matter if the driver is builtin or not, these events go into a queue so it wont matter when udev is started, if that doesnt happen something is definitely wrong, you can check in /var/log/udev what gets through

Revision history for this message
Matt Sealey (mwsealey) wrote :

Oliver, quick question. We've just found that making sound a module (which fixes a lot) breaks on the Smartbook for some reason. This is going to cause a problem re audio group/acls as above.

I am curious how I would check that the devices send the correct uevents and if they don't, if there is some example of how to make it fire a uevent in any case.. that way we can keep it built-in and make sure it fires for udev even if it's built-in (coldplug-like).

Revision history for this message
Simon Quigley (tsimonq2) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. If you test it and it is still an issue, kindly upload the updated logs by running only once:
apport-collect 669219

and any other logs that are relevant for this particular issue.

Changed in efikamx:
status: Confirmed → Incomplete
Simon Quigley (tsimonq2)
Changed in ubiquity (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]

Changed in ubiquity (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.