Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: andyj on December 07, 2025, 04:16:58 PM
-
The ca-certificates has a script named 'update-ca-certificates' that gets run as part of the /usr/local/tce.installed load process. However, there is no mkdir in this script; it assumes all the directories to be used exist. This is not the case for the /usr/local/etc/ssl/certs directory. It is not part of this package or its dependency openssl, so if ca-certificates is loaded before whatever does create this directory then update-ca-certificates will fail. Either the update-ca-certificates script needs to be modified to create the certs directory if it does not already exist, or the extension needs to be updated so that directory is in the squashfs structure when it is loaded.
-
Hi andyj
The first 3 lines of /usr/local/tce.installed/ca-certificates are:
if [ ! -d /usr/local/etc ]; then
mkdir -p /usr/local/etc
fi
If they were changed to this:
if [ ! -d /usr/local/etc/ssl/certs ]; then
mkdir -p /usr/local/etc/ssl/certs
fithat should solve it, right?
-
Yes, that would work.
-
..but something is creating /usr/local/etc/ssl/certs.
Is it the openssl startup script?
-
Hi Juanito
Yes, the openssl startup script is creating /usr/local/etc/ssl/certs.
Would you like me to update the ca-certificates startup script?
This way who depends on whom and load order become irrelevant.
-
Sure, please go ahead :)
-
Hi andyj
ca-certificates updated in TC16 x86 and x86_64.
Please check one of them out and make sure it works correctly.
-
For reference piCore already had
[ -d /usr/local/etc/ssl/certs ] || mkdir -p /usr/local/etc/ssl/certs
Although its a bit redundant, as it could have been fixed your way. I'll change my scripts for the next time I update piCore. Although packages like these are architecture independent.
-
Yes, the openssl startup script is creating /usr/local/etc/ssl/certs.
Dec 8 20:09:07 www-vm authpriv.notice sudo: tc : TTY=unknown ; PWD=/mnt/sr0/cde/optional ; USER=root ; COMMAND=/bin/mkdir -p /tmp/tcloop/openssl
Dec 8 20:09:07 www-vm authpriv.notice sudo: tc : TTY=unknown ; PWD=/mnt/sr0/cde/optional ; USER=root ; COMMAND=/bin/mkdir -p /tmp/tcloop/ca-certificates
Dec 8 20:09:07 www-vm authpriv.notice sudo: tc : TTY=unknown ; PWD=/mnt/sr0/cde/optional ; USER=root ; COMMAND=/bin/mkdir -p /tmp/tcloop/openssh
The load order is right, but I get an error on the console saying the directory can't be found. The directory is there this time but it's empty. I don't have the updated ca-certificates extension, I'm waiting on mirrors. Could this be a race problem? When I run update-ca-certificates from the command line after it boots it works as expected.
-
Hi andyj
... Could this be a race problem? ...
It does sound like it. Kind of like when the kernel queues a write
until it's convenient to complete it.
-
Going down yet another rabbit hole, I added -xv to the scripts and updated tce-setup to trace it. In update-ca-certificates this happens:
cleanup() {
rm -f "$TEMPBUNDLE"
rm -f "$ADDED"
rm -f "$REMOVED"
}
trap cleanup 0
+ trap cleanup 0
# Helper files. (Some of them are not simple arrays because we spawn
# subshells later on.)
TEMPBUNDLE="${ETCCERTSDIR}/${CERTBUNDLE}.new"
+ TEMPBUNDLE=/usr/local/etc/ssl/certs/ca-certificates.crt.new
ADDED="$(mktemp -p "${TMPDIR:-/tmp}" "ca-certificates.tmp.XXXXXX")"
+ mktemp -p /tmp ca-certificates.tmp.XXXXXX
+ ADDED=/tmp/ca-certificates.tmp.aaaaaa
REMOVED="$(mktemp -p "${TMPDIR:-/tmp}" "ca-certificates.tmp.XXXXXX")"
+ mktemp -p /tmp ca-certificates.tmp.XXXXXX
mktemp: File exists
+ REMOVED=
+ cleanup
+ rm -f /usr/local/etc/ssl/certs/ca-certificates.crt.new
+ rm -f /tmp/ca-certificates.tmp.aaaaaa
+ rm -f
ln -s /usr/local/etc/ssl/certs/ca-certificates.crt /usr/local/etc/ssl/cacert.pem
+ ln -s /usr/local/etc/ssl/certs/ca-certificates.crt /usr/local/etc/ssl/cacert.pem
ln -s /usr/local/etc/ssl/certs/ca-certificates.crt /usr/local/etc/ssl/ca-bundle.crt
+ ln -s /usr/local/etc/ssl/certs/ca-certificates.crt /usr/local/etc/ssl/ca-bundle.crt
I see the last two links from the tce.installed/ca-certificates script, but they are red and broken. The script exits because mktemp throws a "file exists" error. Why does this not work from tce-setup, but it does from the CLI?
-
Hi andyj
+ mktemp -p /tmp ca-certificates.tmp.XXXXXX
+ ADDED=/tmp/ca-certificates.tmp.aaaaaaIsn't .XXXXXX supposed to be replaced with a random sequence?
It looks like it's being replaced with .aaaaaa which doesn't look random.
I'm guessing the second time its being called it's returning .aaaaaa again.
No entropy?
-
Apparently my system doesn't have entropy when it starts which is why the script fails, but it does later which is why it works. This brings up a lot of questions, like why isn't there any entropy initially, and why does it have some later.
-
Hi andyj
I noticed something. The 32 bit version of haveged does not have
a tce.installed file. That means it's not started until called after all
extensions have completed loading (bootsync, bootlocal?).
Meanwhile, ca-certificates and openssl do have tce.installed files,
which get executed in the order they were loaded after extensions
have finished loading. So update-ca-certificates gets run before
haveged has even been started.
The 64 bit version of haveged has this for tce.installed:
#!/bin/sh
haveged 1>/dev/null 2>&1 &
-
Apparently my system doesn't have entropy when it starts which is why the script fails, but it does later which is why it works. This brings up a lot of questions, like why isn't there any entropy initially, and why does it have some later.
Hi andyj. Since version 5.4 the linux kernel has a haveged-like mechanism for generating entropy, but it does so only after the kernel's random number generator (CRNG) is fully initialized. Maybe your setup needs entropy before the CRNG is initialized?
Take a look here: https://github.com/jirka-h/haveged/blob/master/README.md
-
... Maybe your setup needs entropy before the CRNG is initialized?
Take a look here: https://github.com/jirka-h/haveged/blob/master/README.md
I download and compiled haveged. I added it to my initrd and start it in /etc/init.d/rcS. Problem solved. It's about 130K so I wouldn't suggest it as a candidate for inclusion in vanilla TC. I don't know how this could be done as an extension unless it's loaded first and you hope it does it's thing before something needs it.
-
Most things that need random and entropy have wait mechanisms to make sure the kernel is ready. Obviously mktemp does not.
Do you see this line in dmesg?
[ 0.000000] random: crng init done
-
Hi andyj
You beat me to it. I was going to suggest something similar. I was
going to suggest making a separate initrd containing:
/usr/sbin/haveged
/usr/lib/libhavege.so
# A modified rcS to start haveged
/etc/init.d/rcSThat way, instead of modifying initrd files, append this initrd to include
haveged and overwrite /etc/init.d/rcS with the modified version.
This way, you can add it to different Tinycore releases without modifying
multiple initrd files.
-
Each of my VM's is set to PXE boot, and has it's own initrd that gets loaded after the stock rootfs. On the dhcp/bootp server I just update what I need and have a script to package them. The extension list is in that initrd as well so I only need generic CD images for 32 and 64 bit from an rsync of the distro. I add my extensions to the CD and test them before I submit them, which is the phase I'm in now. We went down this rabbit hole because apache wasn't starting as it was supposed to in bootlocal.sh because mod_ssl was failing.
I compiled haveged and it's library to be in /usr/local though, this is the way.
I do see this in boot.log without haveged:
[ 1.269467] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 1.293151] /dev/sr0: Can't open blockdev
[ 1.294042] /dev/sr0: Can't open blockdev
[ 1.294748] /dev/sr0: Can't open blockdev
[ 1.295841] /dev/sr0: Can't open blockdev
[ 1.296532] /dev/sr0: Can't open blockdev
[ 1.296875] ISO 9660 Extensions: Microsoft Joliet Level 3
[ 1.296998] ISO 9660 Extensions: RRIP_1991A
[ 3.724888] NET: Registered PF_VSOCK protocol family
[ 5.104902] random: crng init done
[ 5.311824] EXT4-fs (sda1): mounted filesystem ce42a570-e54e-4010-9b14-e02b129a550d r/w with ordered data mode. Quota mode: disabled.
[ 5.312316] EXT4-fs (sda1): unmounting filesystem ce42a570-e54e-4010-9b14-e02b129a550d.
[ 5.316685] EXT4-fs (sda1): mounted filesystem ce42a570-e54e-4010-9b14-e02b129a550d r/w with ordered data mode. Quota mode: disabled.
[ 5.375203] NET: Registered PF_INET6 protocol family
[ 5.402950] Segment Routing with IPv6
[ 5.402958] RPL Segment Routing with IPv6
[ 5.402982] In-situ OAM (IOAM) with IPv6
[ 5.465971] xt_geoip: loading out-of-tree module taints kernel.
The crng init seems really late in the process, is this normal?
With haveged started in rcS, it happens sooner:
[ 1.474509] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 1.504421] /dev/sr0: Can't open blockdev
[ 1.506310] /dev/sr0: Can't open blockdev
[ 1.507957] /dev/sr0: Can't open blockdev
[ 1.509737] /dev/sr0: Can't open blockdev
[ 1.511318] /dev/sr0: Can't open blockdev
[ 1.512446] ISO 9660 Extensions: Microsoft Joliet Level 3
[ 1.512642] ISO 9660 Extensions: RRIP_1991A
[ 1.876732] random: crng init done
[ 3.913323] NET: Registered PF_VSOCK protocol family
[ 4.798729] EXT4-fs (sda1): mounted filesystem ce42a570-e54e-4010-9b14-e02b129a550d r/w with ordered data mode. Quota mode: disabled.
[ 4.799448] EXT4-fs (sda1): unmounting filesystem ce42a570-e54e-4010-9b14-e02b129a550d.
[ 4.805703] EXT4-fs (sda1): mounted filesystem ce42a570-e54e-4010-9b14-e02b129a550d r/w with ordered data mode. Quota mode: disabled.
[ 4.871693] NET: Registered PF_INET6 protocol family
[ 4.894712] Segment Routing with IPv6
[ 4.894719] RPL Segment Routing with IPv6
[ 4.894740] In-situ OAM (IOAM) with IPv6
[ 4.964447] xt_geoip: loading out-of-tree module taints kernel.
This three-ish seconds seems to be enough to make a difference.
-
Without getting into the haveged entropy discussion, VM's are quite common in the server world, it seems odd that VM's would not pass hardware entropy to the Guest OS.
Would rngd find and use a hardware entropy device?
-
There are some kernel command line args, that can run this in some modes.
https://github.com/torvalds/linux/blob/master/drivers/char/random.c#L823 (https://github.com/torvalds/linux/blob/master/drivers/char/random.c#L823)
https://github.com/torvalds/linux/blob/master/drivers/char/random.c#L824 (https://github.com/torvalds/linux/blob/master/drivers/char/random.c#L824)
-
... VM's are quite common in the server world, it seems odd that VM's would not pass hardware entropy to the Guest OS.
Would rngd find and use a hardware entropy device?
As of ESXi 8 it can. But I'm using ESXi 6.7 on an AMD Steamroller which does not have a hardware generator, and is not supported under ESXi 8 anyway so it's just not going to happen anytime soon. If I had to guess I would say I'm probably not alone in this regard.