Adding scsi extension, and depmod, to fix issue with SAS controllers

[TexasDex]

Fix issue with SAS controllers.

[Jip-Hop]

Is there a way to automatically determine the kernel version (required for the extension name) so we don't have to manually edit the build file in the future?

[Jip-Hop]

Currently a mismatch may occur if a newer Tiny Core Linux version is released, e.g. 14.1, with a new kernel version. Then the scsi version will still be on the hard-coded version of 6.1.2 while the kernel is a newer version.

According to the release News a kernel update within the same major release of TCL doesn't happen frequently. Seems like the last time was with version 5. Therefore there are multiple scsi extension versions available from the tcz download url.

scsi-3.8.10-tinycore.tcz    2013-May-27 09:19:12    2.0M    application/octet-stream
scsi-3.8.10-tinycore.tcz.info   2013-May-27 09:19:12    0.2K    application/x-info
scsi-3.8.10-tinycore.tcz.list   2013-May-27 09:19:12    7.6K    application/octet-stream
scsi-3.8.10-tinycore.tcz.md5.txt    2013-May-27 09:19:12    0.1K    text/plain; charset=utf-8
scsi-3.8.10-tinycore.tcz.zsync  2013-May-27 09:19:12    6.3K    application/octet-stream
scsi-3.8.10-tinycore64.tcz  2013-May-27 09:19:15    2.0M    application/octet-stream
scsi-3.8.10-tinycore64.tcz.info 2013-May-27 09:19:15    0.2K    application/x-info
scsi-3.8.10-tinycore64.tcz.list 2013-May-27 09:19:15    6.6K    application/octet-stream
scsi-3.8.10-tinycore64.tcz.md5.txt  2013-May-27 09:19:15    0.1K    text/plain; charset=utf-8
scsi-3.8.10-tinycore64.tcz.zsync    2013-May-27 09:19:15    6.3K    application/octet-stream
scsi-3.8.13-tinycore.tcz    2013-Oct-18 11:49:31    2.0M    application/octet-stream
scsi-3.8.13-tinycore.tcz.info   2013-Oct-18 12:02:13    0.2K    application/x-info
scsi-3.8.13-tinycore.tcz.list   2013-Oct-18 11:49:31    7.6K    application/octet-stream
scsi-3.8.13-tinycore.tcz.md5.txt    2013-Oct-18 11:49:31    0.1K    text/plain; charset=utf-8
scsi-3.8.13-tinycore.tcz.zsync  2013-Oct-18 11:49:31    6.3K    application/octet-stream
scsi-3.8.13-tinycore64.tcz  2013-Oct-18 11:49:31    2.0M    application/octet-stream
scsi-3.8.13-tinycore64.tcz.info 2013-Oct-18 12:02:13    0.2K    application/x-info
scsi-3.8.13-tinycore64.tcz.list 2013-Oct-18 11:49:31    6.6K    application/octet-stream
scsi-3.8.13-tinycore64.tcz.md5.txt  2013-Oct-18 11:49:31    0.1K    text/plain; charset=utf-8
scsi-3.8.13-tinycore64.tcz.zsync    2013-Oct-18 11:49:31    6.3K    application/octet-stream

Perhaps it would be an idea to search for the latest available version of scsi in http://distro.ibiblio.org/tinycorelinux/14.x/x86_64/tcz/ or infer the kernel version from http://distro.ibiblio.org/tinycorelinux/14.x/x86_64/release/src/kernel/ or otherwise extract the kernel version from the extracted version of TinyCorePure64-current.iso. Or perhaps it would be sufficient to install lsscsi.tcz, if this one has the scsi-*-tinycore64.tcz extension as a dependency (I couldn't quickly check if this is the case).

I don't know what the consequence is of building the PBA with a mismatch of the kernel and scsi extension version.

What do you think?

[TexasDex]

Easiest way to find the kernel version afaict is just to ls $TMPDIR/core/lib/modules. That means we have to move the EXTENSIONS="$EXTENSIONS scsi-$TC_KERNEL_VERSION.tcz" later in the file, after the extract.

Do you have a preference for defining the EXTENSIONS variable near the top and adding to it, or just setting EXTENSIONS="bash.tcz scsi-${TC_KERNEL_VERSION}.tcz" after the kernel version is known?

[Jip-Hop]

Nice. My preference is defining the EXTENSIONS variable near the top and adding to it.

[Jip-Hop]

What is the reason we run depmod in chroot during build instead of running depmod -A --quick during boot of the PBA? For example just before the sedutil-cli --scan line. I just tried this, calling depmod without arguments, but I can't test if the SAS drives are recognized after.

[TexasDex]

I started with that approach, as I mentioned in my second commment on issue #15 . It worked just fine, but adds some time to the boot process every time you unlock, whereas doing it in build means it only has to be done once. I don't know how much time though, and didn't try the --quick option with it. We do still need the kernel version to install the package, so we'll need to auto-detect it either way.

[Jip-Hop]

Well turns out the depmod in TCL (busybox) doesn't have the --quick flag. In my qemu VM (emulation mode) I now run time depmod on boot and it adds 5s to the boot process which is obviously too much. Any idea how long it takes when not running in an emulator on ARM64?

Currently I can't build the PBA image with docker on my M1 MacBook and I have to wait for the next release of Docker Desktop for it to be fixed. The chroot depmod call causes issues in v4.25.2. This is fixed in v4.26.0 and v4.26.1 but those versions can't handle vfat...

Sorry about all the questions!

[TexasDex]

I suspect depmod is mostly disk IO bound, it needs to read all the module files, the dependency calculation itself is likely pretty quick.

The TCL Remastering page makes it sound like the depmod may not require chroot, meaning you could use the host system depmod. I ran into issues with that (keyboard stopped working in pba), but maybe I was doing it wrong?

[Jip-Hop]

I was able to successfully build this (had to disable Rosetta in Docker Desktop for now). Thanks a lot for your contribution!

[TexasDex]

Glad I could help!