Hi pdittyI 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?
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 intoApply your patch, probably after make mrproper. There's a sorter script that separates and packages all of the modules. I mixed
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.
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
./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?
# 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.gzoh 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 -----
... 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
usr/local/etc/security/limits.conf
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:
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:
/usr/local/etc/pam.d/other
/usr/local/etc/pam.d/system-authSee it they are scripts that take start and stop parameters./usr/local/tce.installed/Linux-PAMApparently there is no "PAM daemon", it's just supposed to work. I'm at a lossGuess again:
The first thing to understand is that PAM is NOT something like tcpd (tcp wrappers) or xinetd that encloses and restricts access to some service. An application needs to be "PAM aware"; it needs to have been written and compiled specifically to use PAM. There are tremendous advantages in doing so, and most applications with any interest in security will be PAM aware.