Debian unattended (preseed) installation, access to audio card(s)

I'm using the preseeding feature in order to shape a custom Debian 10 x64 system. Everything is happening well, except that during the late_command step, I'm running a shell script to configure and deploy miscellaneous things and I would like to be able to access the physical audio interfaces.

Usually, I'm doing that using pacmd list-sinks and then I can easily access the different audio cards names. But in this case, using chroot /target/ sudo -u device pacmd list-sinks, the only thing I see is a dummy interface named audio_null :

I also precise that as soon as the system reboots after the installation, I can access quite normally the physical audio interface.

(For information, I need to access the physical interface name to configure the default interface within Pulseaudio default profile, since the root filesystem is set to read-only right after the installation, this is the ultimate time to do it once for all).

I suppose that it's an expected behavior since all modules are not required during an installation and then some needed services/configuration steps might be skipped.

So what I have tried so far :

• Manually (re)load some modules that sounded pertinent : chroot /target/ sudo modprobe soundcore
• Reloading PulseAudio service (which was apparently not started yet)
• Listing from and outside the target system (chroot /target/ pacmd list-sinks, pacmd list-sinks) To make the previous commands work, I needed to relaunch Pulse chroot /target/ sudo -u device pulseaudio --start without which I faced an error message No PulseAudio daemon running or not running as session daemon

None of the previous attempts succeeded and I'm running out of ideas. I probably missed/misunderstood an obvious concept and an external point of view would be welcomed.

Even if it's not my final purpose, it might be easier to resume the problem to a wider one: How to play a sound during the late_command step of a Debian installation.

PS: For what it's worth, I'm currently deploying to a Virtual Machine, using VmWare, and a physical sound card bridged to it.

Doing this would probably be much easier as a script that runs on your first boot instead of from within the installer.

That said, a quick test by manually doing "Load installer components from installation media" and then selecting "sound-modules-5.10-8-amd64-di: sound support" (in Debian 11, but likely there on Debian 10 too) correctly inserts the necessary kernel modules. Installing alsa-utils (in-target) works out of the box on VirtualBox. Running aplay works too, provided that you un-mute the card using amixer first.

The preseed line required for Debian 11 would look like:

d-i preseed/early_command string anna-install sound-modules

(...there are other ways, this one worked for me)

Then you would also need to make sure that you have alsa-utils on the target. Nothing is needed if you are using a "task" such as Desktop environment, etc. But if it's a bare system, you'd need:

d-i pkgsel/include string alsa-utils

Finally, to make some noise (pun intended):

d-i preseed/late_command string in-target /bin/sh -c \
    "amixer set Master 80% unmute; amixer set PCM 80% unmute; aplay /usr/share/sounds/alsa/Noise.wav"

With a working alsa stack, you could easily get a list of hardware audio devices by doing aplay -l or similar (in-target) and using that information in your setup script later on.

While this could work, I can imagine that it'd be really tricky to get this right with different hardware setups. Some soundcards would need additional switches or outputs to be selected, etc. Moreover, the modprobe options in the final system could be substantially different from the d-i environment and affect card indexes, etc. Happy hacking!

This stage is still running in a chroot, so no systemd instance exists, and anything depending on systemd running in the background is broken.

You are also running a kernel image that was built for the installer, and while that may be the same as the one that was installed into the target system, it often isn't as the installer will pick the most recent kernel that is available at installation time -- so modules installed on the system will likely not fit the currently running kernel.

Your best bet is to look for sound modules for the installer kernel (I believe these exist in an optional installer module for accessibility) and use ALSA tools to play the sound.