LXC compatibility issues

[Kabouik]

This is a list of the things that do not work well with LXC on the Pro1x port, and worked better on the Pro1. This could be related to limitations of LXC itself, but may more likely be caused by the differences between an armv7hl port and an aarch64 one.

I imagine the issues encountered in LXC would apply to Waydroid too, which may make them a little less corner cases:

• No sound in LXC containers.
• Trying to play sound in a LXC container breaks audio in SFOS itself (except pulley sounds, no idea why).
• They keyboard mapping has to allow printing a keycode for the Yellow modifiers in SFOS' evdev_trace and containers' xev. Can we swap them with Alt in the kernel, and give Alt another unused keycode? So far attempts with kernel 1.7.1, 1.8.1 and 1.9.1 failed (yellow characters would be printed without holding the modifier, and/or the modifiers would still not print a keycode in terminal). This may have to be discussed with #2 in mind.

[Kabouik]

I just got audio working in LXC, which solves the first two issues mentioned above.

I followed this really great guide, with just a couple corrections:

• devel-su zypper in alsa-utils (SFOS)
• aplay -L (SFOS) to show available devices
• ls -l /dev/snd (SFOS) to check the group (116 on Pro1x)
• devel-su nano /var/lib/lxc/<containername>/config (SFOS) to add the following lines (note that there is a typo in the original guide linked above):

  # Audio
  lxc.cgroup.devices.allow = c 116:* rwm 
  lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir

• sudo usermod -aG audio user (LXC), then restart the container
• aplay -L (LXC) should now show the same devices as aplay -L (SFOS)
• sudo nano /etc/pulse/default.pa (LXC) to uncomment and change the following line:

  # load-module module-alsa-sink device=<name>

  into

  load-module module-alsa-sink device=default:CARD=bengalidpsndcar

• Restart the container and try pavucontrol which should no longer complain about failing to establish the connection to pulse.

Note that the guide then says that we can check that things are going to work by running alsamixer and checking the TUI, but for me alsamixer failed to even launch so it was pretty demotivating, and I tried playing a video just in case. And boom, sound.

I will try to automate all this in the installation scripts for Debian and Arch in harbour-containers.

I also checked on the SFOS side after playing that video, while the container was still running, and ringtones were working fine. Same minor issue as on Pro1 though: LXC volume level is not influenced by the SFOS volume rocket, but you can use pavucontrol or other GUI or keybinds to control the volume on LXC's side.

That leaves us with just the keyboard part.

[Kabouik]

Better solution without mounting the sound card directly, thanks to hints from Thaodan and this guide. Just scrap all the above instructions, and add this in /var/lib/lxc/<containername>/config:

# Audio
lxc.mount.entry = /usr/share/alsa usr/share/alsa none bind,create=dir 0 0
lxc.mount.entry = /run/user/100000/pulse mnt/pulse none bind,create=dir 0 0

I updated lxc-templates-desktop so that this is done automatically for new containers.

[GoaSkin]

Neither the first, nor the second method works in my case (the second one was preconfigured in my case). There is only a dummy interface available on pulseaudio.

Using the first method, the bengal audio interface is detected well by aplay and alsamixer but not used by pulseaudio. If I start pulseaudio manually, I get an error message that module-alsa-sink failed to load.

Using the second method, aplay tries to access some files in /usr/share/alsa/alsa.conf.d but the whole alsa.conf.d directory doesn't exist on the SFOS, therefore, it also isn't mapped.

I am trying with Ubuntu inside the container.

[Kabouik]

I have been away from that for some time, but yes as mentioned in harbour-containers' description, I got similar issues with Debian containers. As far as I remember, I only managed to get sound working in Arch containers (and in my old pre-existing Debian container, not new ones).

Arch containers should be working out of the box, the above things being preconfigured with latest harbour-containers indeed. Now of course manual experimentation will be necessary (and welcome) to find out how to get sound in new Debian/Ubuntu/Kali/Mint containers.

This would be better discussed in harbour-containers' issue tracker though, this issue here being more targeted at the Pro1x SFOS port itself and the necessary improvements to fix LXC incompatibilities. Since sound works in Arch containers, it is not a port issue (although it might be specific to how sound is set in the port).

[GoaSkin]

I can proceed now that the audio output works well with Arch Linux.

Another thing: Why do does the start_desktop.sh script set the language to 'C.utf8'? For this reason, the XFCE desktop always appears in english and if a custom language is configured for the user, it is ignored by the desktop enviroment.

Is this export really necessary for any reason?