Can't unlock drives on SAS controller

[TexasDex]

I have a server with LSI SAS2 and SAS3 HBAs, and I can successfully boot the sedunlocksrv PBA from them both, but when I enter the password I get the error "Could not detect TCG Opal 2-compliant disks." The same drive with the sedunlocksrv PBA unlocks itself successfully when attached to a SATA controller on another computer, and I'm able to use the original sedutil PBA to unlock it when it's attached to the SAS controllers, so I'm reasonably certain that it's an issue specific to this PBA when used with SAS HBAs.

The HBAs in question appear to use the 'mpt2sas' and 'mpt3sas' kernel modules.

I tried adding 'scsi-6.1.4-tinycore64.tcz' to the extensions list, which afaict is supposed to include the mpt3sas module, but that doesn't seem to have helped. Is there something more needed to enable SAS support in TinyCore?

Is there some kind of way to access a shell for further troubleshooting in the sedunlocksrv pba? Or maybe even just view dmesg output? Or even a way to build a debug version of the pba with that capability? I know in the original sedutil-pba you just use 'debug' as the password and it'll drop you to a root shell in the pba, but that doesn't seem to work for this pba.

I can test new PBA versions relatively easily. I could also provide hardware if desired.

I'm building the PBA on Ubuntu 22.04, and I'm using the chubbyant sedutil fork since the Drivetrust Alliance website links to that instead of their own.

P.S.: While building on Ubuntu 22.04 I had to install a few packages not mentioned in the documentation: xorriso and libarchive-tools. I also installed go from Apt using 'apt install golang-go' because I don't like snaps.

Thank you so much for building this utility by the way, it's exactly what I needed!

[Jip-Hop]

Glad to hear you find this project useful. Too bad it currently doesn't work with SAS controllers.

I think you can use the recently community contributed SSH functionality to access a shell for debugging purposes. See the example authorized_keys file. It currently restricts the example keys to running sudo /home/tc/ssh_sed_unlock.sh but for debugging you don't want to do that.

However I'd personally try to boot the latest, unmodified, version of Tiny Core Linux first, download the sedutil binary and experiment there until unlocking SAS drives works in that environment.

I hope you figure it out! :)

[kapitainsky]

To get SSH access to command line modify https://github.com/Jip-Hop/sedunlocksrv-pba/blob/main/ssh/ssh_sed_unlock.sh script before you build seduclocksrv with SSH access enabled - should be enough to add exit at the beginning as otherwise this script can not be terminated (or rather can but only by reboot or shutdown).

[TexasDex]

The scsi-6.1.2-tinycore64 extension worked when I installed it with tce-load -iw scsi-... but didn't work in an image built from your scripts when I included the scsi-... in the EXTENSIONS variable--at least until I ran depmod. I realized build.sh doesn't install it using tce-load, it just extracts it into the image, which fails to trigger the depmod that adds mpt3sas to modules.dep.

I tried putting depmod -b "${TMPDIR}/core/ 6.1.2-tinycore64" into build.sh, but that broke keyboard input, so instead I just stuck it near the top of tc-config and that allowed me to see the disks right after logging into the tclinux cli.

I'll be testing a bit more to make sure that works with the sedunlocksrv, and to see if I can get depmod working in build.sh to avoid making the pba boot slower.

If I manage that, adding the scsi extension adds about 3MB to the PBA, so I'd say it's not a terrible idea to include it by default--the original sedutils pba has that support built in already, and I'm sure I'm not the only one using this on a server.

[TexasDex]

Ok, I was being dumb and didn't chroot the depmod. Did that, and made the extensions logic a little less duplicative since we have a longer list now. The simplest possible fix is basiclly:

diff --git a/build.sh b/build.sh
index 197fa89..8c62c7f 100755
--- a/build.sh
+++ b/build.sh
@@ -32,10 +32,9 @@ INPUTISO="TinyCorePure64-current.iso"
 OUTPUTIMG="sedunlocksrv-pba.img"
 BOOTARGS="quiet libata.allow_tpm=1"
 SEDUTILBINFILENAME="sedutil-cli"
+EXTENSIONS="scsi-6.1.2-tinycore64.tcz bash.tcz"
 if [ $SSHBUILD == "TRUE" ]; then
-    EXTENSIONS="bash.tcz dropbear.tcz"
-else
-    EXTENSIONS="bash.tcz"
+    EXTENSIONS="$EXTENSIONS dropbear.tcz"
 fi
 case "$(echo ${SEDUTIL_FORK-} | tr '[:upper:]' '[:lower:]')" in
     "chubbyant")
@@ -140,6 +139,9 @@ if [ $SSHBUILD == "TRUE" ]; then
     cp ./ssh/ssh_sed_unlock.sh "${TMPDIR}/core/home/tc/"
 fi

+# Since we installed the scsi extension by extracting it rather than using tce-load, depmod wasn't triggered.  Do that now:
+chroot "${TMPDIR}/core" /sbin/depmod 6.1.2-tinycore64
+
 # Repackage the initrd
 (cd "${TMPDIR}/core" && find | cpio -o -H newc | gzip -9 >"${TMPDIR}/fs/boot/corepure64.gz")

Using the tinycore depmod won't work on cross-architecture builds, not sure how much we care about that. Using the build host system depmod gave me bad results (keyboard drivers broke). If we're okay with using chroot I think we could just refactor the package install to run tce-load -iwc <packagename> in chroot instead, that would simplify the build script quite a bit but would lose the tcz file caching.

I can put whichever variation of that in a PR if needed. Or if you'd rather not break crossbuilds we can just document the scsi issue in the readme, add the chroot depmod as a comment, and close this issue. I would also suggest a few other minor things: adding 'sedutil-cli --scan' to tc-config right before sedunlocksrv starts, so the user can see on the console what drives were detected. We could also add a mention of the debugging technique using ssh without command= to the readme since I found that most helpful, plus the few extra build deps I mentioned earlier. Also, given that the link right on the front of sedutil.com now points to the ChubbyAnt fork, might we want to set that as the default? (I can open separate issues or PRs for any of that)

[Jip-Hop]

Glad to hear you figured it out! And thanks for offering to contribute improvements. 👍

I don't want to make the ChubbyAnt fork the default, as it's doesn't work with my drives which I encrypted using the original SEDutil. The ChubbyAnt fork has this incompatible difference:

SHA512 password hashing vs SHA1 on original SEDutil [...] Note: This version of SEDutil is not compatible with SHA-1 versions of SEDutil

I just updated the readme regarding building on Ubuntu 22.04 and the packages required to install. Could you please verify if it's correct/complete now?

I also just confirmed that I can build the PBA image on my M1 MacBook (arm architecture) using Rosetta for Linux in Docker Desktop v4.25.2. This means the build runs as an amd64 process. This is good enough for me, so let's not worry about cross-architecture builds.

Please go ahead and create a PR for the sedutil-cli --scan addition and another one for the inclusion of the scsi extensions by default. I'd also appreciate documentation for debugging (via SSH)! And I suppose installing via tce-load is the more official way, so if you take that approach I won't be bothered by losing the tcz file caching.

Thanks again! 😄

[TexasDex]

The sedutil-cli --scan and documentation update are in pull request #16. I'll see how well the tce-load method works, then submit that PR once I have something I'm happy with.

[TexasDex]

tce-load does not work; it refuses to run as root among other issues. The TinyCore documentation suggests a few ways to remaster with extensions, some of which don't apply because we're not making an ISO, one of which involves simply concatenating the tcz files together, but the one that seems like it'll work for us is the standard extract and repack like you were already doing, with the chroot depmod and possibly a chroot ldconfig if you're installing shared libraries (we're not, or at least I didn't run into any issues related to that).

So it sounds like the best solution is the diff above, with one slight change to move the kernel version to a separate env var. I've submitted PR#17 for your approval.