[Solved] No sound with RT kernel patch

[dag69]

Hello
So I've followed these directions to create and use the realtime kernel patch

Hi pditty
I'm guessing maybe some permissions got messed up in  rootfs.gz.  Maybe I missed it, but I didn't see why  rootfs.gz  needed
to be changed.

Try this procedure:

... A couple of months ago I had to recompile a kernel to get some hardware on an ASUS T100 Transformer recognized and ran into
the same problem ("is already owned by kernel" error).

The error ("is already owned by kernel") is basically saying a symbol that a module is defining is already defined by the kernel. When
configuring a kernel, selecting certain options will force some drivers to be built into the kernel instead of as a module. So, assuming
you already have existing kernel modules, DRIVER_A is a module depending on DRIVER_B. You select a kernel option that requires
DRIVER_B to be built into the kernel. If you try loading DRIVER_A with the new kernel, it will attempt to load DRIVER_B (a dependency)
and you get that symbol "is already owned by kernel" error. This means DRIVER_A also needs to be recompiled so it no longer tries
to load DRIVER_B.

What I wound up doing is recompiling all modules when I changed the kernel. Here's a step by step for the whole procedure:

Code: [Select]

Compile a kernel:
tce-load -i compiletc perl5 bash ncursesw-dev bc glibc_apps elfutils-dev
wget http://tinycorelinux.net/10.x/x86_64/release/src/kernel/config-4.19.10-tinycore64
wget http://tinycorelinux.net/10.x/x86_64/release/src/kernel/linux-4.19.10-patched.txz
tar xf linux-4.19.10-patched.txz
cd  linux-4.19.10
make mrproper
# Start with the most recent config file.
cp ../config-4.19.10-tinycore64 .config
make oldconfig
make menuconfig [make your changes]
# I like to save a copy of the config file to use as a starting point for the next time.
cp .config ../config-4.19.10-tinycore64-asusT100CHIrev1
# Compile kernel
make -j 2 bzImage
# Copy the kernel where the bootloader can find it.
cp arch/x86/boot/bzImage /mnt/sdg1/Linux/vmlinuzASUS64rev1
# Compile modules
make -j 2 modules
# Place the modules somewhere for packaging.
mkdir -p /home/tc/tmp/ASUS/modules/usr/local
make INSTALL_MOD_PATH=/home/tc/tmp/ASUS/modules/usr/local modules_install
cd /home/tc/tmp/ASUS/
# I like to keep the mod.alias, mod.builtin, mod.dep, mod.order, and mod.symbols files.
mv modules/usr/local/lib/modules/4.19.10-tinycore64/modules.* .
# Remove the 2 links in modules/usr/local/lib/modules/4.19.10-tinycore64/
rm modules/usr/local/lib/modules/4.19.10-tinycore64/build
rm modules/usr/local/lib/modules/4.19.10-tinycore64/source

# Set up sorter.sh to package all the modules.
cd ..
mkdir sorter
cd sorter
tce-load -i squashfs-tools zsync
wget https://github.com/tinycorelinux/sorter/archive/master.zip
unzip master.zip
cd sorter-master/
# This creates all of the Tinycore module packages and leaves them in the current directory.
./sorter.sh 4.19.10-tinycore64 /home/tc/tmp/ASUS/modules
# Back to the tmp directory.
cd ../../
# Fetch a 32 bit root file system.
wget http://tinycorelinux.net/10.x/x86/release/distribution_files/rootfs.gz
# Copy the module archive that's part of the base system
cp sorter/sorter-master/modules64.gz modulesASUS64rev1.gz
# Make a new initrd, 64 bit modules with 32 bit root file system (32 bit apps) in this example.
cat rootfs.gz modulesASUS64rev1.gz > coreASUS64rev1.gz
# Copy the initrd where the bootloader can find it.
cp coreASUS64rev1.gz /mnt/sdg1/Linux/
The downloads only need to be done once. If you need to compile again, use the config file you saved previously as a starting point.

Created directories to archive the results of each build. This allows you to revert to a previous build and keeps matching config,
kernels, modules, and initrd files together. Append  rev1  to the config, kernel, and initrd filenames and place them in a  rev1
directory along with their matching modules.

Compile times on a Dell Dimension E310 were 52 minutes for the kernel and 3 hours 45 minutes for the modules.

Apply your patch, probably after  make mrproper.  There's a sorter script that separates and packages all of the modules. I mixed
a 64 bit kernel with a 32 bit  rootfs.gz  for my needs. Download the  rootfs.gz  that matches your requirements. The procedure is
fairly well commented as to what's going on. Ask questions if something I did seems unclear.

If you really feel the need to unpack/pack  rootfs.gz:

To unpack:

Code: [Select]

mkdir tempdir
cd tempdir
zcat /path/to/existing/rootfs.gz | sudo cpio -i
To repack:

Code: [Select]

sudo find . | sudo cpio -o -H newc | gzip > /path/to/new/initrd.gz
Found here:
http://forum.tinycorelinux.net/index.php/topic,22398.msg140327.html#msg140327

I boot into the system with the new kernel just fine. however, being that the kernel has been renamed from 5.4.3-tinycore to 5.4.3-rt1-tinycore, any tcz packages I have that contain "5.4.3-tinycore", such as the alsa-modules-5.4.3-tinycore.tcz package, need to be renamed to 5.4.3-rt1-tinycore to play nicely with the "KERNEL" part of all the .dep files. ok, so i did that, then I find out that the modules aren't being loaded because the packages are being unsquashed to /usr/local/lib/modules/5.4.3-tinycore and thus the kernel isn't loading them. so then I unsquash all the packages containing 5.4.3-rt1-tinycore in the name, rename the /usr/local/lib/modules/5.4.3-tinycore folders within each squashfs root to 5.4.3-rt1-tinycore, resquash, get the md5sums for each one and replace in each .md5.txt file, and reboot. then when i run dmesg, the last part of the boot says, for each of the altered packages, "version magic '5.4.3-tinycore SMP mod_unload 486' should be '5.4.3-rt1-tinycore SMP preempt_rt mod_unload 486'" and thus the module still does not load. It's clear I need to change some more stuff around, anyone know what that might be?

[Paul_123]

You need to

1) Replace all of the modules in the initrd
2) Make new module extensions that match your kernel.  You cannot simply rename them, you have use your modules from your kernel build and rebuild any extensions that you use.

[dag69]

I was under the impression that running

Code: [Select]

./sorter.sh 4.19.10-tinycore64 /home/tc/tmp/ASUS/moduleswould put all the modules that get loaded in the normal kernel into the new initrd. seems like that's not the case for modules that were installed via tce-load though. Should I manually copy the new .ko files that correspond to the ones that were downloaded via package manager, into the new modules folder before running sorter? or after?

[Rich]

Hi dag69
The modules for the base system get added to the rootfs to create a new initrd in this step:

Code: [Select]

# Copy the module archive that's part of the base system
cp sorter/sorter-master/modules64.gz modulesASUS64rev1.gz
# Make a new initrd, 64 bit modules with 32 bit root file system (32 bit apps) in this example.
cat rootfs.gz modulesASUS64rev1.gz > coreASUS64rev1.gz
If you look in  sorter/sorter-master/  you should see new kernel module extensions (alsa-KERNEL.tcz, i2c-KERNEL.tcz, etc.).

[dag69]

oh lord i hope i didnt miss something that simple lol. i'm having to recompile the modules as i have zero foresight and deleted them after the first time i compiled them. i'll check back later, thanks

[Rich]

Hi dag69

oh lord i hope i didnt miss something that simple lol. ...

I had to check to make sure I didn't leave out that detail. I didn't:

 ----- Snip -----

cd sorter-master/
# This creates all of the Tinycore module packages and leaves them in the current directory.
./sorter.sh 4.19.10-tinycore64 /home/tc/tmp/ASUS/modules
# Back to the tmp directory.
cd ../../

 ----- Snip -----

[Rich]

Hi dag69

... If you look in  sorter/sorter-master/  you should see new kernel module extensions (alsa-KERNEL.tcz, i2c-KERNEL.tcz, etc.).

One more thing. I recommend you copy all of the new kernel module extensions to your  tce  directory, not just the ones you think
you need now.

[dag69]

I see them now ugh I can't believe i missed them lol. everything works fine now
One more question just to not waste a whole thread: debian-based systems use /etc/security/limits.conf to set whether a user is allowed to use a program with rt scheduling, and to set the memlock. what's the equivalent of that in TCL?

[Rich]

Hi dag69
Maybe this is what you are looking for:
http://tinycorelinux.net/11.x/x86/tcz/Linux-PAM.tcz.info

Here is the list of files in that extension:
http://tinycorelinux.net/11.x/x86/tcz/Linux-PAM.tcz.list
It contains:

Code: [Select]

usr/local/etc/security/limits.conf

[dag69]

I had to unsquash and edit that limits.conf file as tinycore won't let me edit anything in the packed parts of the system even with sudo. then got md5sum to replace md5.txt and re-squashed
then I ran addgroup audio and adduser tc audio, then set .filetool.lst to save the group, gshadow, passwd, and shadow files, ran filetool.sh and saved. Not working. is pam supposed to be enabled somehow after install?

[Juanito]

Why do you want to add the “audio” group? Tinycore is intended to work with the "staff" group.

[dag69]

just added tc to staff, edited limits.conf to reflect '@staff' instead of '@audio', ran filetool to back up the /etc/group files, rebooted and verified that everything stuck. whether I'm part of staff, or audio, or whatever, tc is not allowed to manually set the ulimit for realtime priority, and it seems as if limits.conf is basically being ignored

[Juanito]

You could try symlinking /etc/security -> /usr/local/etc/security?

[dag69]

No dice I'm afraid. The only workaround I've been able to do is run the audio programs as sudo, which is not ideal but it works I guess

[Rich]

Hi dag69

I had to unsquash and edit that limits.conf file ...

No need to go through all of that. To edit configuration files in extensions, first replace the symlink with a copy of the file:

Code: [Select]

sudo busybox cp /usr/local/etc/security/limits.conf /usr/local/etc/security/Then make your changes and add the file to your backup.

... is pam supposed to be enabled somehow after install?

I would imagine you need to start it. Take a look at these 2 files:

Code: [Select]

/usr/local/etc/pam.d/other
/usr/local/etc/pam.d/system-authSee it they are scripts that take  start  and  stop  parameters.

Take a look inside the extensions startup file and see what it does:

Code: [Select]

/usr/local/tce.installed/Linux-PAM
You may need to adjust some of the other config files in  /usr/local/etc/security/