Possible to get ALSA working or otherwise enable sound card access?

[Simo Kinnunen]

Hi,

I'm running a bunch of bare metal CoreOS machines. Currently, there's a pressing need to enable sound card access on these machines, and I'm not quite sure how I would go about accomplishing that. Specifically, I'd like to be able to use the `arecord` and `aplay` commands from ALSA. Now obviously I can get the commands installed in a --privileged container, but as far I understand they require a kernel module to actually work, and CoreOS doesn't ship with it. I did find [1] but I'm unsure how it would be used and if it's even relevant anymore.

Has anyone done this before? What would be a good way to approach this?

Any ideas would be most appreciated.

Thanks,

Simo

[1] https://github.com/coreos/portage-stable/tree/master/media-sound

[Michael Marineau]

CoreOS doesn't ship any audio or video drivers and while it is possible to build additional kernel modules it isn't well supported and requires manual intervention for upgrades. What sort of application are you trying to use CoreOS for?

--
You received this message because you are subscribed to the Google Groups "CoreOS User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joshua Kolden]

Recently I setup a docker container to automatically build and install Nvidia CUDA drivers in a CoreOS host.  It works reasonably well and is at least marginally tolerant to kernel upgrades buy building the kernel module based on the currently running kernel.  You might be able to use it as a template for how to do this kind of thing.

https://github.com/StudioPyxis/coreos-nvidia

It would be nice if CoreOS had some dedicated feature/process for kernel modules.  Perhaps a special lightweight container that auto builds after upgrades and then runs in privileged mode via a preconfigured systemd unit dedicated to kernel modules (ff this doesn't go against the Zen of CoreOS).

[Michael Marineau]

We do have a development container which includes the same toolchain version that was used to build CoreOS but it works under systemd-nspawn, not docker, and isn't documented. But here is a quick guide that may be a useful starting place.

# on coreos

wget http://alpha.release.core-os.net/amd64-usr/current/coreos_developer_container.bin.bz2

bunzip2 coreos_developer_container.bin.bz2

sudo systemd-nspawn -i coreos_developer_container.bin --share-system

# inside container:

emerge-gitclone

emerge -gKav coreos-sources

cd /usr/src/linux

zcat /proc/config.gz >.config

make modules_prepare

After that you should be able to build both internal and external modules, but there is a major quirk here: /lib/modules is read-only so you cannot install them there, use depmod, or use modprobe. You can still load them with insmod by path but it is up to you to load them in the right order if you are building something complicated with lots of modules like ALSA. The Nvidia case does have an advantage here, being a single module there aren't dependencies to deal with.

[Joshua Kolden]

Interesting thanks, thats handy!  I didn’t think you could start kernel modules from within systemd-nspawn or are you just suggesting to build them here then move them to the host? 

Seems like it would take more steps to automate this compared to the dockerfile approach.  Any reason I couldn’t re-stage this env as a docker container?

The docker build happens in an unprivileged container so can build anywhere that is version consistent with the target machine.  When the container is run it just runs modprobe.  This works great but for having a relatively large container just to install a kernel module, and me not knowing how to trigger the build process on a CoreOS upgrade event.

I suppose I could pre-build the module containers based on beta or alpha CoreOS versions, then just pull and run the appropriate container based on the CoreOS version on the production machines.  

Also I like the idea of public dockerfiles, so we can find pre-rolled module installers and not duplicated a lot of low level 'busy work’.

[Michael Marineau]

On Wed, Feb 18, 2015 at 11:26 AM, Joshua Kolden <jos...@crackcreative.com> wrote:

Interesting thanks, thats handy!  I didn’t think you could start kernel modules from within systemd-nspawn or are you just suggesting to build them here then move them to the host? 

Just suggesting building them, usually loading modules from inside systemd-nspawn is blocked.

 

Seems like it would take more steps to automate this compared to the dockerfile approach.  Any reason I couldn’t re-stage this env as a docker container?

No reason, it just isn't a docker container because providing that adds yet-another-step to our build process which I haven't gotten around to adding. It is a single-partition disk image so you can import it into docker with something like this:

sudo losetup --show --find --partscan coreos_developer_container.bin

sudo mount /dev/loop0p1 /mnt

sudo tar -c -C /mnt . | docker import -

(or so I guess, may be missing a tar flag or something)

[goo...@gmail.com]

Dear Maintainers,

is there anything ongoing or plans with alsa-support? - Just for interest I installed CoreOS on a baremetal and started my very first docker container with debian. My first intention was to get a Virtual Piano software running, but alas ALSA is not supported by CoreOS (beta). I wasn't aware of this when I started to test CoreOS -- were my efforts in vain? :-/

Great work, anyway!

[Brandon Philips]

Hello-

We have never added ALSA because we couldn't imagine a use case, on a server, for sound. Are you trying to use CoreOS as a desktop operating system?

Brandon

--

[goo...@gmail.com]

Am Dienstag, 25. August 2015 00:20:19 UTC+2 schrieb Brandon Philips:

Hello-

We have never added ALSA because we couldn't imagine a use case, on a server, for sound. Are you trying to use CoreOS as a desktop operating system?

Brandon

Hello,

yes, I found the idea appealing to use CoreOS + Docker as platform to run a single application like my virtual piano. There are a lot of fantastic virtual midi instruments nowadays that need not more than a  lean stable platform, alsa and usbmidi.

[Brandon Philips]

I don't think CoreOS will be a good fit for you at this point. Something we would like to do is support users who want to add additional Kernel modules to their CoreOS machine that aren't shipped by default but we don't have a solution for that today.

If you want to hack on CoreOS directly you can do that with the SDK: https://coreos.com/os/docs/latest/sdk-modifying-coreos.html. The configuration for our Kernel builds is found here: https://github.com/coreos/coreos-overlay/tree/master/sys-kernel/coreos-kernel/files

Cheers,

Brandon

[goo...@gmail.com]

Thank you,

that you answered my question and for the links! I will see if I have enough skills (and time) to experiment with it.

Cheers